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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely useful non-obvious behavior: results are gated by the bank's licence scope, values are read under the bank's own key into its own workspace, and each row carries a source_url plus a read timestamp for provenance.

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?

Reasonably short overall, but the first sentence is a single sprawling clause chain ('values a data provider the caller's bank licenses stated... looked up under the bank's own key into its own workspace, with the name, legal form...') that is hard to parse and buries the key license-scope constraint mid-paragraph rather than front-loading it.

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?

There is no output schema, so the description carries the return-shape burden and it does list the returned fields and provenance metadata. Combined with the licence-scope caveat and filter/paging guidance, an agent has nearly everything needed, with only the sibling boundary left implicit.

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 coverage is 100%, so baseline would be 3, but the description earns an extra point by giving the register format example ('HRB 12345 Hamburg') that shows the court must be included, and by restating the node_id binding and paging semantics in context, adding meaning beyond the terse schema 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 states the resource (company data from the North Data provider) and the returned fields (name, legal form, register, LEI, graph node, source_url), and the licensing constraint ('only values read under a licence scope that covers the bank's own systems') implicitly draws a boundary against sibling tools like company_records. However, it never names an alternative, so the agent must infer the boundary itself, and the opening clause is grammatically tangled.

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 explains how to drive the tool (filter by node_id or by German register with court, e.g. 'HRB 12345 Hamburg'; page with limit/offset) and notes lookup happens in the dashboard, but gives no when-to-use vs siblings such as company_records or company_profile, and no exclusions or prerequisites for the licence-scope rule.

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