# Two Approaches to Helping AI Agents Use Your API (And Why You Need Both) AI coding agents fail in predictable ways when working with APIs. Two recent approaches from Mintlify and Armin Ronacher attack different failure modes. Understanding both reveals something useful about how agents should interact with developer tools. ## Two Failure Modes When an agent writes code against your API, it can fail because: 1. **It doesn't know what it doesn't know.** The agent uses a deprecated method, misconfigures a parameter, or violates a constraint that isn't obvious from type signatures. This is the "known unknowns" problem: things the API maintainer knows but the agent doesn't. 2. **It can't discover what exists.** The agent doesn't know what collections exist, what the payload schema looks like, or what data is actually in the system. This is the "unknown unknowns" problem: things specific to the user's environment that no amount of documentation covers. Most agent failures trace back to one of these. Mintlify's SKILL.md approach addresses the first. Armin Ronacher's REPL-first MCP addresses the second. ## What SKILL.md Gives You [SKILL.md](https://github.com/AgenticSkills/skills) is an emerging open standard for shipping knowledge to agents before they write code. The idea has roots in the [Cloudflare RFC](https://blog.cloudflare.com/ai-agents-open-standard), the [agentskills proposal](https://agentskills.org), and Vercel's skills CLI. [Mintlify's blog post](https://mintlify.com/blog/skill-md) by [Michael Ryaboy](https://www.linkedin.com/in/michael-ryaboy-software-engineer) showed how to apply it in practice. Decision tables for component selection, explicit gotchas sections, and auto-generating skill files from existing docs. A SKILL.md isn't documentation. It's a briefing. Decision tables, not tutorials. Gotchas, not explanations. For Qdrant, a SKILL.md might include:
Decision Table
Want to... Do
Search client.query_points(col, query=vec, limit=10)
Filter Add query_filter=Filter(must=[...])
Hybrid prefetch dense+sparse, FusionQuery(Fusion.RRF)
Multi-tenant create_payload_index(field, is_tenant=True)
Gotchas
✖ query_points not search - all search variants deprecated
✖ Never one collection per user - use is_tenant=True index
✖ BM25 requires Modifier.IDF - sparse search needs it
This prevents the agent from using `client.search()` (deprecated), creating a collection per user (anti-pattern), or misconfiguring sparse vectors (common mistake). The guidance for all of these exists across Qdrant's tutorials, docs, and community discussions. However, finding it requires existing Qdrant context because you need to already know enough to ask the right questions. Skills package has accumulated product intuition so agents don't need to build it from scratch. ## What REPL-First MCP Gives You [Armin Ronacher](https://lucumr.pocoo.org/), creator of Flask and now building [Earendil](https://earendil.dev/), proposed a [different approach](https://lucumr.pocoo.org/2025/1/22/what-i-want-for-ai-tools/). Instead of 30 narrow MCP tools, give the agent a Python shell with the SDK pre-configured: ```python # Agent can just run this collections = client.get_collections() print([c.name for c in collections.collections]) # Then inspect the actual schema info = client.get_collection("products") print(info.config.params.vectors) ``` The agent discovers what exists by asking the system directly. No tool for "list collections." No tool for "get schema." Just Python. The REPL handles the unknown unknowns: what's actually in your Qdrant instance right now. ## Why Neither Alone Works **SKILL.md without REPL:** The agent knows *how* to use `query_points` but not *what* to query. It guesses collection names. It assumes payload fields. It writes syntactically correct code that fails at runtime. **REPL without SKILL.md:** The agent can discover what exists but still uses deprecated methods. It creates collections with wrong configurations. It makes the same mistakes it would have made without the REPL, just with more information about the data. Together, the agent workflow looks like this:
Agent Workflow
1. Read SKILL.md
"Use query_points, not search"
"Never one collection per user"
"BM25 needs Modifier.IDF"
2. Use REPL
client.get_collections()
client.scroll("products", limit=1)
# Now knows: collection exists, payload has "category" field
3. Write code
Correct method + correct collection + correct filter fields
The SKILL.md prevents known mistakes. The REPL handles environment-specific discovery. Both failure modes are addressed. ## Implementation The SKILL.md is just a file you drop into your project. The REPL is an MCP tool. A minimal implementation: ```python @server.call_tool() async def handle_tool_call(name: str, arguments: dict): if name == "qdrant-repl": code = arguments["code"] # client, models pre-configured in repl_globals try: result = eval(compile(code, "", "eval"), repl_globals) return repr(result) if result else "(ok)" except SyntaxError: exec(compile(code, "", "exec"), repl_globals) return "(executed)" ``` State persists between calls. The agent builds up context incrementally. ## The Broader Pattern This isn't specific to Qdrant. Any API with: - Deprecated methods or migration paths → needs SKILL.md - User-specific state (databases, collections, schemas) → needs REPL The two approaches complement because they address orthogonal problems. Static knowledge for static mistakes. Dynamic access for dynamic discovery. Most developer tools need both. ## This Doesn't Make It Easy Adding SKILL.md and a REPL doesn't mean agents suddenly work flawlessly. They still hallucinate. They still misunderstand requirements. They still write code that technically runs but doesn't do what you wanted. What these tools do is eliminate *unnecessary* failures. The agent won't fail because it used a deprecated method. That's a solved problem with SKILL.md. It won't fail because it guessed a collection name. The REPL lets it check. But it can still fail because it misunderstood what you meant by "similar products" or because the embedding model you're using doesn't capture the semantics you care about. You might ask: why not just pull context from docs automatically? Tools like [mcp-code-snippets](https://github.com/qdrant/mcp-code-snippets), Qdrant's MCP server for searching documentation and code examples, solve a real problem, but they solve a different one. Auto-generated context gives you API surface area. A SKILL.md gives you judgment. "Don't create one collection per user" isn't obvious from any API reference. "BM25 needs Modifier.IDF" is documented, but you have to know to look for it. Skills distill that intuition into a format agents can use immediately. The two approaches aren't in competition. Use both. The goal isn't perfect agents. The goal is agents that fail for interesting reasons instead of boring ones. Deprecated API calls are boring failures. Wrong collection names are boring failures. Skill.md and REPL handle the boring stuff so you can focus on the hard problems. ## Try It The [Qdrant Python skill](https://github.com/qdrant/skills/tree/main/skills/qdrant-python) is just 94 lines, and there's also a [Rust skill](https://github.com/qdrant/skills/tree/main/skills/qdrant-rust) for the gRPC client. Both are minimal, adaptable examples for your own setup. The repo also includes the `AGENTS.md` format alongside `SKILL.md` for flexible configuration. Drop it into your project: ```bash mkdir -p .claude/skills/qdrant curl -o .claude/skills/qdrant/SKILL.md \ https://raw.githubusercontent.com/qdrant/skills/main/skills/qdrant-python/SKILL.md ``` For the REPL side, configure the [Qdrant MCP server with REPL](https://github.com/thierrypdamiba/mcp-server-qdrant-repl). It's a fork of the official [Qdrant MCP server](https://github.com/qdrant/mcp-server-qdrant) that adds a `qdrant-repl` tool giving agents a stateful Python shell with a pre-configured `QdrantClient`. For docs lookup, [mcp-code-snippets](https://github.com/qdrant/mcp-code-snippets) gives agents semantic search over Qdrant documentation and code examples. The REPL fork layers exploratory access on top. The agent gets the briefing, the docs, and the toolkit. Your agents will stop using deprecated methods. They'll stop guessing collection names. They'll write correct queries on the first attempt. Not because they got smarter, but because they got the right information at the right time. We'd love to hear how you're using Qdrant with AI agents. What's working, what's breaking, what patterns you've found. If you want to stay ahead of the curve on this stuff, [sign up for our newsletter](https://qdrant.tech/subscribe/). And thanks to you, our readers, for pushing us to make the developer experience better for everyone.