yop-mcp

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 discloses that the output is in markdown format and may contain links, which is useful behavioral context. However, it doesn't mention other traits like whether this is a read-only operation, potential rate limits, authentication needs, or error handling. For a tool with zero annotation coverage, this leaves gaps in behavioral understanding.

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 highly concise and well-structured. It uses two sentences: one states the purpose and usage guideline, and the other specifies the return type and format. Every sentence adds value without redundancy, making it efficient and front-loaded with key information.

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 the tool's low complexity (0 parameters, output schema exists), the description is mostly complete. It explains the purpose, output format (markdown), and a usage tip about links. However, with no annotations and an output schema (though not detailed here), it could benefit from more behavioral context like read-only status or error cases, but the essentials are covered for this simple 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?

The tool has 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to add parameter semantics since there are none. It appropriately focuses on output and usage. A baseline of 4 is given for zero-parameter tools when the description is adequate in other aspects.

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: '获取易宝支付开放平台(YOP)的产品能力概览' (get an overview of YeePay Open Platform's product capabilities). It specifies the verb ('获取' - get/retrieve) and resource ('产品能力概览' - product capability overview). However, it doesn't explicitly distinguish this from its sibling 'yeepay_yop_overview', which might have overlapping functionality, preventing a perfect score.

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 clear usage context: it mentions that when links are present in the output, the tool 'yeepay_yop_link_detail' can be used to get detailed content. This gives a specific follow-up action. However, it doesn't explain when to use this tool versus alternatives like 'yeepay_yop_overview' or 'yeepay_yop_product_detail_and_associated_apis', which could be relevant for product-related queries.

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