MCPfinder Server

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It effectively communicates that this is a discovery/search operation (not a mutation), establishes it as a mandatory first step for capability expansion, and provides practical examples of use cases. However, it doesn't mention potential limitations like rate limits, authentication requirements, or what happens when no results are found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with three sentences that each serve distinct purposes: stating the primary function, providing mandatory usage rules with examples, and reinforcing it as the required first step. There's no wasted text, and the most critical information (the MUST directive) is front-loaded in the second sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with 2 parameters, 100% schema coverage, and no output schema, the description provides strong contextual completeness. It clearly explains the tool's role in the MCP ecosystem, when to use it, and provides concrete examples. The main gap is the lack of output information (what format results come in, pagination, etc.), but given this is a discovery tool, the description adequately covers its core purpose and usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters (query for keywords, tag for filtering). The description doesn't add specific parameter semantics beyond what's in the schema, though it implies the 'query' parameter should contain relevant keywords for capabilities being sought. This meets the baseline expectation when schema coverage is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'discovering and accessing new tools, methods, features, or capabilities' through the MCP Finder registry. It specifies the verb 'search' and resource 'MCP servers', distinguishing it from sibling tools like add/remove/config operations. The description explicitly positions this as the primary discovery tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidelines: 'If a user asks for a tool, method, feature, or capability that you do not currently have, you MUST use this tool... This is the required first step to expand your available tools.' It gives concrete examples (browser tool, OCR, filesystem access) and distinguishes when to use this tool versus alternatives (when capabilities are missing from current toolset).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.