getapi_kvk_detail_branch

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

No annotations are provided, so the description carries the full behavioral burden. It reveals only that this is a GET (read) operation via the endpoint path; it says nothing about authentication requirements, rate limits, error behavior when a companyNumber has no branches, or how the branch data relates to the parent company. This is far short of what a no-annotation tool needs.

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 definition is extremely short and front-loaded, but that brevity reflects under-specification rather than efficient communication. Nothing is padded, yet almost every sentence that would earn its place (purpose detail, parameter meaning) is absent.

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?

With no annotations, no output schema, and 0% parameter description coverage across two parameters, the description is the only information source and is inadequate. An agent cannot confidently invoke this tool correctly or interpret its branch-level scope from the single phrase provided.

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 both parameters are undocumented in structured form. The description's path template hints that companyNumber is the required identifier, but it never explains what it is (KVK number format) and does not mention the optional 'vestigingsnummer' at all, leaving a documented parameter entirely unexplained.

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 phrase 'KVK vestigingsprofiel' identifies the resource (a branch/location profile from the KVK registry) and the tmp endpoint path implies a retrieval, so the agent can infer roughly what the tool returns. However, it is a bare noun phrase with no verb, and it never distinguishes itself from the sibling 'getapi_kvk_detail' (company-level detail) or explains what a 'vestigingsprofiel' contains versus that sibling.

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?

There is no when-to-use guidance, no stated prerequisites (e.g., needing a valid companyNumber or vestigingsnummer), and no reference to alternative tools such as getapi_kvk_detail or getapi_kvk_search. The agent must guess when this branch endpoint is preferred over the company detail endpoint.

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