meta-agent-tools

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It only says an 'index' exists; nothing about side effects, return values, or whether this is a read-only operation. The tool's behavior is completely opaque.

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 extremely short, which is concise, but it is under-specification rather than purposeful structure. The single phrase adds no actionable information beyond the tool name and is not effectively front-loaded with value.

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?

Despite having zero parameters and no output schema, the tool's core purpose remains unclear. With no annotations and no behavioral disclosure, the description is the only source of context, and it fails to explain what the tool returns or when to invoke it.

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?

The tool has zero parameters, so there is no parameter documentation burden. The baseline of 4 applies because the description is not required to add meaning beyond an empty schema.

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 'Index of the Mural API' is a noun phrase that identifies a resource but lacks an explicit action. It essentially restates the tool name and does not tell an agent what operation to perform. The sibling tools suggest it could be a directory or reference, but that is left entirely to inference.

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?

There is no guidance on when to use this tool versus any of its siblings. No mention of context, prerequisites, or alternatives is present.

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 the full burden of behavioral disclosure. It does not state whether this is a read-only query, whether it can create charges, whether external network calls are involved, or what the output represents. This is a significant transparency gap.

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?

It is concise at only five words, but conciseness alone is not a virtue when it sacrifices substance. The structure offers no front-loaded key information beyond a vague topic. It is under-specified rather than efficiently written.

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 tool with no annotations, no output schema, and no parameters, the description is the only source of meaning. 'x402 prices and network' does not tell an agent what action is performed, what it returns, or when to call it. It is inadequate for correct invocation.

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?

The input schema has zero parameters, so parameter semantics are trivially complete. Baseline for 0 params is 4, and there is no additional parameter description needed. The single phrase 'prices and network' weakly hints at the output domain but no parameters exist to document.

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 'x402 prices and network' is extremely vague. It names a domain (x402 prices and network) but does not state a specific verb or action the tool performs. Sibling tools like get_listing and list_listings use clearer verb+resource patterns, so this description fails to distinguish billing from them.

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?

There is no guidance about when to use this tool versus alternatives. The description does not specify a use case, prerequisites, or mention of any sibling tools as alternatives. An agent would have to guess when billing should be invoked.

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 the behavioral disclosure burden. It does add useful information: the call costs $0.10 and triggers a 429 with Retry-After requiring backoff. However, it does not state whether this is a mutating action, what side effects occur, or what authorization is needed.

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 text is very short and free of fluff, but the structure is cryptic and jarring. 'Agent contact $0.10 x402' is unclear, and the rate-limit note is jammed into a fragment. It is concise at the expense of communicative clarity.

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?

This is a fairly simple contact tool with no output schema, so the description must explain the expected result or success behavior. It only warns about cost and rate limiting, leaving the agent to guess what a successful call returns and what exactly happens after sending the message.

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?

The input schema documents all four parameters with descriptions, giving 100% schema description coverage. The description adds no additional parameter semantics, so the baseline of 3 is appropriate. The unusual form_ts field is already explained in the schema.

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 never states a clear verb and resource action. 'Agent contact' reads as a label, while '$0.10 x402' is cryptic and the 429/Retry-After note describes rate-limit behavior rather than the tool's actual function. It does not distinguish how this tool differs from its siblings.

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?

There is no guidance on when to use this tool versus alternatives, no prerequisite context, and no explanation of what kind of request this is for. The only hint is that calls are rate limited after the first message, which is a behavioral constraint rather than usage direction.

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, the description carries the full burden of explaining side effects. It only says a guest is created; it does not disclose whether creation is idempotent, what 'guest' means, what the 'mr_…' prefix represents, whether authentication is needed, or what the response contains.

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 text is short, but 'Creates a guest mr_…' is not a well-formed phrase and the unexplained 'mr_…' fragment reads as a truncation or placeholder. This is under-specification rather than disciplined conciseness.

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?

The tool is simple with zero parameters and no output schema, but the description still leaves important context missing: what a guest is, what the caller receives, and what consequences follow from calling this tool. An agent could invoke it, but cannot confidently predict the result.

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?

The input schema has no parameters, so there are no parameter semantics for the description to clarify. The zero-parameter baseline of 4 applies; the strange 'mr_…' fragment appears to refer to an output or identifier rather than an input.

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 names a specific action ('Creates') and resource ('guest'), which differentiates it from sibling tools like create_listing. However, the dangling token 'mr_…' is unexplained and likely truncated, so it only partially clarifies what kind of guest is created.

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?

There is no guidance about when to invoke create_guest, what scenario it belongs to, or why it should be preferred over sibling tools. The name alone implies the resource, but the description offers no usage context, prerequisites, or exclusions.

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, the description carries the disclosure burden. It does add important behavioral context: human sessions are free, and an agent without a session gets a 402 error and a $0.10 charge. However, it does not disclose what happens on success, whether the operation is idempotent, or what side effects registration produces.

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 a single sentence that front-loads the action and resource types, then appends the essential billing/error detail in parentheses. There is no filler or 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?

Despite high schema coverage, the description is thin for a 7-parameter creation tool with no output schema and no annotations. It omits what the response looks like, whether registration is immediate or moderated, how duplicate URLs are handled, and what permissions or prerequisites are needed.

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 86%, so the baseline is 3. The description adds value by explaining the session_token parameter's cost and error behavior ('human session free; agent without session = 402 $0.10'), which is not present in the schema. This is meaningful extra semantic context.

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 uses a specific verb ('Registers') and names the exact resource types ('MCP server, skill or plugin'), making the purpose clear. It also distinguishes itself from sibling tools like get_listing, like_listing, and create_guest by the registration action and resource scope.

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 implies the tool should be used when registering an MCP server, skill, or plugin, but it does not explicitly discuss when not to use it or which sibling alternative might be preferred. The billing note hints at session-related requirements but does not provide explicit usage context versus alternatives.

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, the description carries full responsibility for disclosing behavior. It only states 'One listing's page.' and does not mention read-only behavior, return format, error cases, or any side effects. This adds little beyond what the tool name implies.

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 very short and front-loaded, but brevity crosses into under-specification. 'One listing's page.' does not earn its place as a complete definition because it omits necessary behavioral and usage context.

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 simple one-parameter tool this is partially adequate, but with no annotations and no output schema the description should at least indicate what the page contains or how the result is returned. It does not, leaving an agent with only the bare resource name.

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%, and the schema clearly documents 'id' as the Listing ID from 'Anuncio.id'. The tool description itself adds no parameter meaning, but the schema already carries the full burden, so a baseline 3 is appropriate.

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 'One listing's page.' identifies the resource (a single listing) and implies retrieval, but uses no explicit verb and is nearly a paraphrase of the tool name. It does not distinguish get_listing from siblings like go_listing or list_listings beyond the singular scope.

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 guidance is given about when to use this tool versus create_listing, list_listings, go_listing, or like_listing. Usage is only implied by the name and the required 'id' parameter, with no exclusions or alternative routing.

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, the description carries the burden of behavioral disclosure. It openly states a 404 is returned when no README was stored, which is useful, but it does not mention whether the operation is read-only, any authentication requirements, or what the response payload looks like.

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 short and front-loads the core resource before stating the not-found behavior. It contains no fluff, though the unexplained parenthetical 'R2' is slightly cryptic and could be clearer.

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 low-complexity single-parameter tool, the description covers what is retrieved and one key error condition. However, because there is no output schema, it would benefit from stating the response format or content type, and it could more explicitly connect to listing IDs and sibling tools.

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 100%, and the id parameter is already documented as the listing ID from Anuncio.id. The description adds no additional parameter-level meaning, so the baseline of 3 applies.

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 name and description together make clear this tool returns the README associated with a listing. The resource is specific (listing README) and the 404 behavior adds helpful scoping, though the sentence is a noun phrase rather than an explicit action verb and does not contrast with sibling 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?

The description gives no guidance on when to use this tool versus alternatives such as get_listing or list_listings. It implies the README retrieval use case but does not state prerequisites, exclusions, or a preferred sibling when listing details are needed.

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, the description carries the full burden. It mentions a side effect ('counts a visit') and implies a redirect, but it does not disclose what the tool returns, whether it follows the redirect, or any authentication or error implications. This is minimal transparency.

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 a single, concise sentence with no wasted words. It front-loads the core action and side effect. However, the terseness contributes to ambiguity, so it is not a perfect score.

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 tool with a single parameter and no output schema, the description should clarify what happens after the hop and what the caller receives. It does not. The cryptic '302 hop' plus lack of return value or side-effect detail leaves the agent under-informed for correct invocation.

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?

The input schema provides 100% coverage with a description for 'id' ('ID of the listing to visit'). The tool description adds 'to the listing's origin' which clarifies the destination, but it does not explain what 'origin' means or how it differs from a plain listing visit. The baseline of 3 is appropriate as the schema already documents the parameter.

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 states a specific action ('302 hop') and a resource ('listing's origin'), and notes it counts a visit. It is not a tautology and hints at a distinct purpose, but the technical jargon ('302 hop') is unclear to an agent without web knowledge, and it does not explicitly differentiate from sibling listing tools like get_listing or like_listing.

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 guidance is given on when to use this tool versus its siblings. The agent is left to infer that 'hopping' is different from 'getting' or 'liking', but no explicit conditions or alternatives are provided.

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 the full burden of behavioral disclosure. 'Liveness.' does not state whether this is a read-only check, what it returns, whether it performs any side effects, or what conditions could affect its behavior.

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 extremely short, but this is under-specification rather than effective conciseness. 'Liveness.' conveys almost no actionable information, so the single word does not earn its place in helping an agent use the tool.

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 there are no parameters, no output schema, and no annotations, the description should at least clarify what liveness means (e.g., returns OK, checks server status, etc.). The current description is incomplete for an agent to correctly interpret the tool's purpose or result.

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?

The schema has zero parameters, so the schema provides no information to compensate. However, the tool requires no input at all, meaning parameter semantics are trivially minimal; a 4 is reasonable because nothing meaningful could be added for a no-parameter tool.

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 'Liveness.' is a tautology that essentially restates the tool name 'health' without specifying what action it performs or what resource it operates on. It gives an agent no concrete indication of what invoking this tool will do or return.

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?

There is no guidance on when to use this tool versus any alternative. The context signals show zero parameters and no annotations, and the description does not explain what 'Liveness' means in practice or when an agent should call it.

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?

The word 'reversible' is the only behavioral disclosure and does add some value by hinting that the like can be undone or toggled. However, with no annotations provided, the description carries the full burden and fails to clarify whether calling it again unlikes the listing, what side effects occur, or what authentication/error behavior applies.

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?

Being short is not the same as being well-structured. Two words convey too little information to be considered appropriately concise; the description is under-specified rather than efficiently complete.

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 tool with no annotations, no output schema, and an undocumented required parameter, 'Reversible like' is drastically incomplete. An agent cannot determine the exact effect, the expected response, or the meaning of guest_token, making correct invocation uncertain.

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 only 50%: the 'id' parameter is documented but 'guest_token' has no schema description. The description adds no parameter-level meaning and does nothing to compensate for the undocumented guest_token, so an agent must guess what that token is or where it comes from.

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 phrase 'Reversible like' is a fragment that closely restates the tool name rather than stating the operation explicitly. It implies liking a listing, but it never says 'like or unlike a listing' or names the resource, leaving the exact purpose to inference.

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 no guidance on when to use this tool versus any sibling tool, nor does it mention prerequisites, alternatives, or conditions. An agent has no contextual basis for choosing like_listing over list_listings, get_listing, or create_listing.

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 the full burden of behavioral disclosure. It only states that the subject is comments on a live listing, and does not disclose ordering, pagination, handling of non-live listings, error behavior, or whether the operation is read-only.

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 very concise and front-loads the core subject without filler. It is slightly under-specified as a fragment rather than a complete instruction, but it is not bloated or poorly structured.

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 simple one-parameter fetch, the phrase 'comments' and the schema-provided id are minimally sufficient for an agent to make a plausible call. However, with no output schema and no annotations, the description omits return-format details and behavioral edge cases, leaving clear gaps.

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?

The input schema fully describes the single required 'id' parameter as the ID of the listing, so the description does not need to repeat it. The phrase 'live listing' adds a slight contextual constraint but does not explain how that affects the accepted id values.

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 names the resource ('comments on a live listing') but is a noun phrase rather than an explicit action, so it does not clearly say 'retrieve comments for a listing'. It is understandable from the tool name, but the description itself is vague about the operation and does not differentiate it from sibling tools like get_listing or list_listings.

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?

There is no guidance about when to use this tool versus alternatives, no prerequisites, and no mention of what makes a listing 'live'. An agent has to infer the intended use almost entirely from the tool name and the single id parameter.

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, the description carries the full burden of behavioral disclosure. It hints that results are 'public' and 'live,' but does not explain result format, pagination, filtering behavior, or any side effects. This is insufficient for a listing tool with five optional parameters.

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 short, but brevity here is under-specification rather than conciseness. The metaphorical 'mosaic' wastes the single sentence on vague imagery instead of a clear operational statement, so the sentence does not fully earn 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?

For a tool with five optional parameters, no output schema, and no annotations, this description is not complete enough. It fails to explain what a result looks like, how parameters interact, or when an agent should choose this over sibling tools.

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 parameters are already well-documented. The description adds little beyond the schema, only loosely echoing the kinds in the 'kind' enum and the public nature of the data. Baseline 3 is appropriate.

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 is a noun phrase—'Public mosaic of live MCP servers, skills and plugins'—with no explicit verb like 'list' or 'search.' It vaguely suggests a collection of resources but fails to clearly state the tool's action or how it differs from siblings like list_mcp_servers or get_listing.

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?

There is no guidance on when to use this tool versus alternatives such as list_mcp_servers or get_listing. The description gives no context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.

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 are provided, so the description carries the full burden. It reveals the HTTP method and a filtering behavior, but omits details like pagination mechanics, error cases, or authorization needs. Minimal but not misleading.

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?

A single compact sentence that packs the endpoint and a key constraint. No wasted words; efficient and front-loaded.

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 simple paginated list operation with fully documented parameters and no output schema, the description covers the essential purpose and filter. It could mention pagination behavior or return structure, but the schema provides cursor semantics. Overall sufficient for a low-complexity 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 100%, so the schema already documents all three parameters (limit, cursor, search). The description adds no extra semantic value beyond the schema, so baseline 3 is appropriate.

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 lists MCP servers via a specific endpoint and includes a filter ('Only live kind=mcp'). It distinguishes from siblings like list_listings by resource, though it doesn't name alternatives explicitly.

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 implies usage for listing MCP servers but gives no explicit guidance on when to prefer this over sibling listing tools like list_listings or list_comments. It lacks exclusions or conditions.

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