beel_get_verifactu_configuration

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds behavioral context by noting that the configuration belongs to the NIF and that the NIF in the path is authoritative, which is not inferable from annotations. The guardrails reference and docs pointer provide additional operational context.

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 compact and front-loaded with the primary purpose. The endpoint, guardrails warning, and docs reference are each purposeful and non-redundant. Slightly longer than necessary due to the guardrails section, but each part serves a function, so it earns a 4 rather than a 5.

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 simple getter with one parameter and no output schema, the description covers the essential aspects: what it retrieves, the NIF selection mechanism, and references to guardrails and docs. Missing is a hint at what the returned configuration contains, but given the tool's simplicity and the annotations, the description is nearly complete.

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%, and the schema's parameter description for company_id is exceptionally detailed (explains NIF derivation, header irrelevance, and 403 behavior). The tool description adds no additional parameter information, so a baseline of 3 is appropriate since the schema carries the burden.

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 the verb 'Retrieves' and the resource 'VeriFactu configuration of this company (NIF)' clearly. It further clarifies that the NIF in the path determines which configuration is returned, and provides the exact endpoint. This distinguishes it from sibling tools like beel_get_tax_configuration and beel_update_verifactu_configuration by the explicit resource.

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 implies when to use this tool (when needing the VeriFactu configuration) and points to beel_docs_search for exhaustive rules, but it does not explicitly state when not to use it or contrast it with alternative tools like beel_get_tax_configuration. The fiscal guardrails note gives contextual guidance but not selection criteria.

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