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

Annotations provide readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds significant context beyond these: it creates a Kindwise identification and counts against per-IP trial quota (default 10 calls per rolling 24 hours), no client API key is required or accepted, and treatment fields are informational and not a substitute for professional advice. It also discloses that the server cannot see chat attachments. This is valuable, but it doesn't explicitly describe the response format or how the quota reset works in detail, which would have made it a 5.

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 long but every sentence earns its place. It is front-loaded with the core function, then scope, then operational details, then quota and safety caveats, and finally feedback routing. No redundancy with the schema or annotations. The structure is logical and scannable.

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 complexity (6 parameters, external service, quota, image format constraints) and richly documented schema, the description completes all critical context: scope, image requirements, quota, safety disclaimer, feedback routing, and geographic optimization. With no output schema, the description's statement of returning 'crop and disease/pest suggestions with the requested detail fields' is adequate. Nothing an agent needs to call it correctly is missing.

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%, with each parameter having detailed descriptions, examples, and constraints. The description adds complementary meaning beyond the schema: it explains the need for close-ups and canopy shots, the purpose of lat/long for regional ranking, and notes that unknown details tokens are ignored. This is a strong synergy where the description adds real value without repeating schema text.

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 verb (diagnose), resource (crop diseases, disorders, pests from field photographs using Kindwise Crop.health), and scope (agricultural crops, not ornamental houseplants). It names output types (pathogens, pests, symptoms, severity, treatment notes) and distinguishes from sibling tools by naming the feedback tool. This is clear and unambiguous.

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 explicit when-to-use guidance (agricultural crops, not houseplants) and names an alternative (submit_feedback for feedback). It gives concrete operational instructions: pass 1–8 images as URLs or base64, include close-ups and canopy shot, optional lat/long for ranking, and notes quota limits. It also warns against localhost/file:// URLs and mentions Wikimedia 424 failures, which is actionable and specific.

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