simulate

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

With no annotations provided, the description carries the full behavioral burden. It discloses that parameters are explicit (no automatic PDF injection), that it returns both the payload sent (audit) and a non-binding estimate, and that it uses the official ESTV calculator. These are meaningful traits beyond the schema. It does not mention network dependencies or side effects, but for a simulation tool the read-only nature is implied. The disclosure is solid and goes beyond a minimal statement.

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 concise and well-structured: it leads with the purpose, then states the explicit-parameter caveat, highlights the two key parameters, and closes with return behavior. Every sentence earns its place, and there is no fluff. It is appropriately sized for the tool's complexity and front-loaded with the most critical information.

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 16 parameters, the description covers the essentials but not all. It explains location and deductions, mentions the audit and non-binding estimate, and points to a sibling for deduction IDs. The output schema exists, so return details are covered elsewhere. However, it does not explain how parameters like relationship, income_type, or children_ages affect the calculation, nor does it clarify required vs. optional fields beyond the schema. The description is adequate for a basic call but leaves some nuance to 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?

Schema description coverage is 0%, so the description must compensate. It explains the two most complex parameters: location (with examples of postal codes and municipality names) and deductions (as IDs from the ESTV sheet, referencing list_deductions_estv, with an example). The other 14 parameters are left to their titles and enums, which are mostly self-explanatory. While the key parameters are clarified, the description does not address relationships like income1/income2 or children_ages, leaving some ambiguity for an agent.

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, specific statement: 'Simulate the tax of a household with the official ESTV calculator.' It names the action (simulate), the resource (tax of a household), and the mechanism (official ESTV calculator). It also distinguishes from sibling tools like get_tax_return or compare_tax_returns, which deal with returns rather than simulation, making the purpose unmistakable.

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 implicit usage guidance via 'EXPLICIT parameters (no data is injected automatically from the PDFs)', which hints that this tool is for when you have manual data rather than PDF-derived data. It also references list_deductions_estv for deduction IDs, suggesting a workflow. However, it does not explicitly state when to use this over alternatives or when not to use it, leaving the agent to infer the decision boundary.

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