9 posts tagged with "tool design"

The average MCP tool description is bad. Two recent arXiv papers measured exactly how bad. 97.1% of analyzed tools carry at least one description smell. 73% of servers reuse the same display_name across multiple tools. In head-to-head selection between five functionally equivalent servers, the one with a clearer description gets picked 72% of the time vs a 20% baseline.

A 260% selection lift from prose alone is the headline. Descriptions aren't documentation; they're part of the agent-facing prompt, and a bad one quietly costs you every selection round your server is in. So we built a scorer.

MCPBundles now runs an LLM-as-judge rubric over every published server, covering tool descriptions, server-level skill content, and the structured MCP annotations that the runtime actually reads. The verdict shows up on the public listing page.

Figma is where product teams live — design files, component libraries, design tokens, comments, dev resources, webhook events, activity logs. But AI agents can't see inside Figma unless you give them structured access to the right surface at the right granularity.

MCP (Model Context Protocol) solves this by letting agents call Figma as a set of typed tools. Instead of pasting screenshots into ChatGPT or describing your component hierarchy by hand, the AI reads your files, inspects components, mutates variables in transactional batches, posts comments, attaches dev resources, and debugs webhook delivery — programmatically.

The MCPBundles Figma bundle exposes Figma's REST API as 30 MCP tools built around how design teams actually work. This post walks through what's there.

Anthropic's recent blog post about code execution with MCP got everyone excited about converting tool calls into code. But I think we're optimizing the wrong thing.

We just added Ahrefs to MCPBundles. All 53 SEO MCP tools, organized into 7 bundles that actually make sense.

Here's the thing about Ahrefs—it's got everything. Keyword research, backlink analysis, rank tracking, competitor spying, technical audits. But when you've got 53 MCP tools staring at you, where do you even start?

That's where bundles come in. Instead of dumping everything into one massive pile, we split it up by what you're actually trying to do. Planning content? There's a bundle for that. Building backlinks? Yep, that too. Tracking rankings? Got it covered.

Each bundle has the MCP tools you need for that specific job. Nothing more, nothing less.

We just integrated PostgreSQL—the powerful open-source relational database—into MCPBundles. But here's the challenge: PostgreSQL exposes 38 different database tools covering everything from SQL queries to schema inspection to performance optimization. How do you make 38 tools discoverable and useful without overwhelming users?

The answer: use-case driven bundles. Instead of dumping 38 tools into one massive bundle, we organized them into 6 focused bundles based on what database professionals actually do. Every tool appears in the main "PostgreSQL" bundle, plus at least one specialized bundle aligned to specific workflows.

When you're building MCP tools, there's a moment where you realize something counterintuitive: the description field isn't just documentation—it's instruction. Every parameter description you write is a teaching moment where the AI learns not just what a parameter is, but when to use it, why it matters, and how it impacts the operation.

This shift in thinking—from documenting to teaching—changes how you design tools. Let me show you what that looks like in practice.

Here's a problem I kept running into: when you're building an MCP server, you face this weird tension between giving AI agents enough control and not drowning them in options. Build 20 different tools and you're burning context window on redundant functionality. Build 3 tools with no parameters and the AI can't do anything useful.

After shipping dozens of MCP integrations, I found something that actually works: six core tools that balance OpenAI's single-string requirements with rich, parameter-driven operations. It's not arbitrary—there's a reason this number keeps working.

Weaviate is an open-source vector database that powers AI-native applications—RAG systems, semantic search, recommendation engines, and more. But how do you make a vector database accessible to AI agents? You can't just expose raw API endpoints and expect good results.

The answer: 6 focused tools organized around what developers actually do with vector databases. Not 20 tools covering every edge case. Not 3 tools that force you into awkward patterns. Just 6 tools that handle search, storage, browsing, and management—the core workflows every vector database application needs.

Following our prior post on wiring up an MCP server for our Django app — see How We Integrated Model Context Protocol (MCP) into Our Django App — we went back and revisited the architecture. "Too many tools" is still a huge problem for LLM productivity, which has continued into GPT5 and the latest Claude models so probably won't be solved toon. Cursor and Claude both work better when they have fewer tools to choose from, and our original setup exposed too many single-purpose GET tools. So we consolidated everything into a single, strongly-typed batch tool.

The result: one get tool, clearer schema, faster concurrent fetches, and less model confusion.