Meyhem — MCP Server Discovery & Agent Search

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

With no annotations provided, the description carries full behavioral disclosure burden. It mentions finding the 'best' tool (implying ranking/relevance scoring) and the search scope, but fails to disclose return format (single tool vs list), error handling when no match exists, latency characteristics, or whether results are cached.

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 consists of two efficient sentences with zero redundancy. The primary purpose is front-loaded in the first sentence, while the second sentence provides actionable parameter guidance. Every word earns its place.

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?

Given 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is insufficient. It covers the core purpose and one parameter's enum values but leaves the critical 'query' parameter and return structure completely undocumented for a discovery tool.

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 0%, requiring the description to compensate. It partially documents the 'ecosystem' parameter by listing valid values ('mcp' or 'openclaw'), but provides no semantics for the required 'query' parameter (expected format: keywords, natural language, tool name?) or 'max_results' (behavior at limits, pagination).

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 finds 'the best tool for your task' (specific verb+resource) and defines the scope as 'across MCP servers and OpenClaw skills'. It implicitly distinguishes from sibling 'find_server' by focusing on tools/capabilities rather than servers, though explicit differentiation from 'search' or 'select' siblings is absent.

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 mentions the optional ecosystem filter ('mcp' or 'openclaw') but provides no explicit guidance on when to use this tool versus siblings like 'find_server', 'search', or 'select'. No prerequisites, error conditions, or alternative selection criteria are documented.

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

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

No annotations provided, yet description omits critical behavioral details: whether this queries a remote registry or local index, what data structure is returned, rate limiting, or authentication requirements. Only behavioral hint is that query accepts natural language.

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?

Extremely concise at two sentences with no redundancy. However, given zero annotations and schema coverage, this brevity becomes under-specification rather than efficient design.

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?

Inadequate for a discovery tool lacking both annotations and output schema. Missing: return value structure, result ranking logic, server metadata included, and error conditions (e.g., no matches found).

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 coverage is 0%, requiring description compensation. It successfully clarifies that 'query' expects natural language input rather than keywords, but completely ignores 'max_results', leaving its semantics (hard limit? pagination?) undefined.

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?

States specific action (Find) and resource (MCP servers), but fails to distinguish from sibling tools 'search' and 'find_capability'. An agent cannot determine when to use find_server versus the generic search or capability-specific finder.

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?

Provides no explicit guidance on when to use this tool versus alternatives. The phrase 'Describe what you need in natural language' hints at input format but does not address selection criteria or prerequisites.

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

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

No annotations provided, so description carries full burden. It discloses that feedback affects 'Meyhem rankings' (behavioral side effect), but lacks details on data persistence, privacy, or failure modes.

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?

Two sentences totaling 38 words. First sentence establishes purpose and usage pattern; second provides motivation. No redundant or filler content.

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?

Adequately covers the core feedback workflow but incomplete given five undocumented schema parameters (0% coverage) and lack of output schema. The nested metadata parameter particularly needs explanation.

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 has 0% description coverage, requiring description to compensate. While 'success' is documented explicitly and 'search_id' is implied by context, three parameters (metadata, signal_type, selection_id) remain completely undocumented, including the flexible metadata object.

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?

Description uses specific verb 'Report' with clear resource 'search result' and explicitly distinguishes from sibling search tools by focusing on feedback rather than retrieval.

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?

Explicitly states when to use ('after every search'), provides clear boolean semantics ('success=true if results were useful, or success=false if not'), and explains the value proposition (rankings improvement).

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

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

With no annotations provided, the description carries full burden and discloses the feedback-driven scoring mechanism and the improvement loop. However, it omits safety profile (read-only vs destructive), rate limits, or failure modes.

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?

Two well-structured sentences front-loaded with purpose and critical workflow instruction. Every word earns its place with zero redundancy.

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?

Adequate for the feedback workflow but incomplete given 6 undocumented parameters and no output schema. The mention of 'search_id' hints at return values, but param semantics gap is significant.

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 has 0% description coverage and the description fails to compensate, providing no guidance on freshness, agent_id, session_id, or include_content semantics. Only the query parameter is implicitly obvious from 'search the web'.

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?

Clearly states the tool searches the web and returns ranked results with feedback-driven scoring. While it distinguishes functionally from siblings (find_capability, find_server, select), it does not explicitly contrast when to use this versus the find_* tools.

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?

Excellent guidance explicitly naming the sibling 'outcome' tool and specifying exact parameters (search_id, success=true/false) to call after using results, creating a clear workflow.

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

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

With no annotations provided, the description carries full disclosure burden. It mentions 'get its full content' indicating retrieval behavior, but lacks critical details about side effects, caching behavior, rate limits, or what 'full content' entails (e.g., full page text vs metadata).

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 single sentence is efficiently worded without redundancy, but it is inappropriately brief given the complexity (6 undocumented parameters). It front-loads the core action but provides insufficient information density for the tool's requirements.

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 6-parameter tool with zero schema documentation, no annotations, and no output schema, a 7-word description is inadequate. Missing: parameter documentation, expected input formats, relationship to search workflow, and return value structure. Significant gaps remain unfilled.

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 0% for all 6 parameters, and the description completely fails to compensate. No explanation of what search_id, position, url, or provider represent (likely result identifiers), or what is_terminal and token_count control. The agent has zero semantic guidance for parameter usage.

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 selects a search result and retrieves its full content, distinguishing it from the 'search' sibling tool which likely only returns result listings. Specific verb ('Select') and resource ('search result') are present.

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?

No explicit when/when-not guidance or alternative tools are mentioned. While 'select a search result' implies this is a secondary step after searching, it fails to explicitly state the workflow relationship with the 'search' sibling or prerequisites like having valid search results.

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