get_testing_policyHow mother plants and incoming genetics are tested (RT-qPCR), which pathogens, how often, the incoming HLVd positive rate, and whether results are available to buyers.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description is consistent with those. It adds useful context by indicating that this tool reports policy facts rather than performing tests or mutations, so an agent can predict the tool's 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?
A single tightly packed sentence where every phrase adds a distinct facet: method, pathogens, frequency, positive rate, and buyer visibility. It is front-loaded with the core topic and contains no filler or repetition.
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?
With zero parameters and no output schema, the description is complete: it tells the agent exactly what data the tool exposes and what to expect. There are no inputs to validate, no side effects to warn about, and no missing prerequisites.
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 the baseline is 4. The description has no parameter burden and naturally conveys that the tool takes no input and returns a single policy overview.
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 defines what the tool provides: a testing-policy overview covering RT-qPCR method, pathogens, frequency, HLVd positive rate, and buyer availability. This is specific and distinguishes it from sibling getters like get_article or get_inventory, even though it does not literally use the word 'retrieves'.
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 clear context for when to use this tool: when information about the pathogen-testing program is needed. It does not explicitly name alternatives or exclusions, but no sibling tool covers this domain, so the contextual guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.