doc_source

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 behavioral disclosure. It states the tool retrieves document _source without metadata, which implies a read-only operation, but doesn't clarify permissions, error handling, rate limits, or response format. For a tool with zero annotation coverage, this is a significant gap in describing behavioral traits beyond basic functionality.

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 appropriately sized and front-loaded, with the main purpose stated first followed by a parameter list. It uses minimal words to convey key information, though the parameter explanations are brief and could be more structured. There's no wasted text, making it efficient but slightly under-specified.

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 complexity (3 parameters, no annotations, no output schema), the description is incomplete. It covers the basic purpose and parameters but lacks details on behavioral aspects like permissions, error cases, and return values. For a retrieval tool in a context with many siblings, more context is needed to ensure proper usage without relying on external knowledge.

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 description lists parameters ('index', 'id', 'source') with brief explanations, adding some meaning beyond the input schema, which has 0% description coverage. However, it doesn't detail parameter formats, constraints, or examples (e.g., what 'source' array should contain). With low schema coverage, the description partially compensates but doesn't fully document all three parameters, resulting in a baseline score.

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: '仅获取文档 _source（不含元数据）' translates to 'Only get document _source (excluding metadata).' This specifies the verb ('get'), resource ('document _source'), and scope ('excluding metadata'), making it clear what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'doc_get' or 'doc_mget', which likely retrieve full documents including metadata, so it misses full sibling distinction.

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 alternatives. It doesn't mention sibling tools such as 'doc_get' (which probably retrieves full documents with metadata) or 'doc_mget' (for multiple documents), nor does it specify prerequisites or exclusions. Usage is implied by the purpose but lacks explicit context for selection.

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