grc_tax_obligation_scan

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

The description mentions scope constraints but does not disclose any side effects, permissions required, or whether the action is read-only or destructive. The annotations indicate destructiveHint: true, yet this is not reflected in the description. There is no statement about data modifications, external calls, or potential impacts, leaving the user uninformed about behavioral implications.

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 succinct and well-structured, with clear labeling of arguments. It avoids unnecessary fluff and presents the routing information in a compact manner. The inclusion of default values for parameters is also clear. The overall length is appropriate for the tool's simplicity.

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?

The description provides adequate context for understanding the tool's basic function and routing. However, it lacks information about the expected output or return value, despite the presence of an output schema (which is not described). It also does not explain what 'tax_obligation_scan' actually does in terms of business logic, leaving some ambiguity for the agent.

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 parameters 'message' and 'inputs' have brief descriptions: 'Free-text objective' and 'Optional JSON string of structured inputs'. This provides basic semantic meaning, but it doesn't specify expected JSON structure, allowed keys, or how the message correlates with the inputs. The descriptions are minimal and lack detail on how to construct valid inputs.

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 it runs the 'tax_obligation_scan' domain agent action, which is a specific verb-resource pairing. The action name itself conveys the purpose of scanning tax obligations, and the routing context is mentioned. However, it doesn't elaborate on what the scan entails or what results it produces, but the core purpose is evident.

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 does not provide guidance on when to use this tool versus alternatives. It only describes the internal routing mechanism (JWT, tenant, company scope) but omits any conditions under which the tool should be invoked or when another tool might be more appropriate. No explicit 'use this when' or 'instead of' guidance is present.

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