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 each entry includes an effective-from date and authoritative source URL, and advises agents to confirm rates against the source before quoting. It does not explicitly state that the tool is read-only, but the term 'list' implies a non-mutating operation. It adds useful context about data provenance and reliability, which goes beyond a minimal description, though it could have explicitly stated that it does not compute or assign taxes.

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 dense paragraph that is front-loaded with the core purpose, followed by the jurisdiction breakdown, filter explanations, and usage guidance. While lengthy, every sentence provides necessary information given the tool's complexity—eight jurisdictions, multiple tax types, and schemes. It is structured with clear punctuation and clauses, making it readable. It could be broken into sections for easier scanning, but it is not wasteful or redundant.

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 output schema, the description adequately describes the return structure ('Every entry carries an effective-from date and an authoritative source URL'). It covers all major use cases, provides filter options, and mentions the authoritative sources by name. It also distinguishes itself from related tools. Given the tool's breadth, this description is exceptionally complete, leaving little ambiguity about what the agent will receive 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?

Schema description coverage is 100%, but the description adds substantial meaning beyond the schema. It lists all supported countries with their ISO codes, enumerates the tax types with examples, and explains the scheme values (standard, reduced, zero, exempt, etc.) in context. For instance, it clarifies that 'composition' applies to India and 'input-taxed' to Australia, giving the agent concrete expectations for each filter value. This greatly enhances parameter understanding beyond the schema's basic descriptions.

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 opens with a clear verb+resource: 'List statutory tax-rate slabs by jurisdiction', and immediately enumerates all supported jurisdictions with their specific rates, distinguishing it from sibling list tools (list_articles, list_features, etc.) and the lookup_tax_rate tool by explicitly stating it is the public statutory reference. The detailed enumeration makes the tool's exact scope 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 explicitly states when to use: 'Use this when a user asks "what is the GST rate on X?", "what VAT band does Y fall into?", or "what are the composition slabs in India?"' and when not to use: 'for an org-specific tax assignment use the authenticated books_classify_event tool.' This provides clear guidance and an alternative, fully satisfying the usage guideline criterion.

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