fiken_validate_posting_proposal

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

Beyond the read-only and idempotent annotations, the description discloses that Fiken GET checks may be performed, that local-only validation is possible, and that the tool never books or confirms tax correctness. This adds meaningful behavioral context without contradicting annotations.

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 purpose, followed by operational caveats. Every sentence adds useful information, though it could be slightly more structured around parameters and outcomes.

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 tool has a complex nested input and no output schema, but the description never explains what validation results are returned or how failures are surfaced. It covers important behavioral boundaries well, but leaves a key completeness gap for an agent invoking 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 reported as 0%, so the description must carry the parameter burden. It explains check_fiken and the supplier_id requirement for duplicate search, but ignores max_pages and does not otherwise clarify the large nested proposal structure.

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 uses a specific verb and resource: 'Kontroller et FULLSTENDIG konteringsforslag' and explains that it validates Claude-created proposals from attachments. It clearly distinguishes validation from booking by stating 'Bekrefter aldri ... bokfører noe', though it does not name a specific sibling alternative.

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?

It gives useful conditions such as 'supplier_id kreves for duplikatsøk' and 'check_fiken=false gir bare lokal kontroll'. However, it does not explicitly say when to use this tool versus related tools like duplicate-finding or purchase-reading siblings.

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