Read-only Belgian company search, KBO data, financials, employees and company relationships.
Scored across 8 tools
Most tools target clearly distinct resources (company, employees, financials, shareholders, participations). The pair get_held_mandates and get_mandates could be confused, though the descriptions clarify the direction of the relationship.
Names follow a predictable verb_noun snake_case pattern, with get_ as the dominant prefix. search_companies is the only deviation, but its verb is appropriate for the action.
Eight tools is well-scoped for a read-only company data server. Each tool corresponds to a distinct data need, and none appear redundant.
The surface covers core company lookup, search, employment, financials, mandates in both directions, participations, and shareholders. Minor gaps like establishment/location details or historical multi-year queries exist but are workable.
Look up KBO company information, including address, legal form and NACE codes.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Response language; defaults to nl. | |
| company_number | Yes | Belgian company number; digits, dots, spaces and optional BE prefix are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds which data categories come back, which is genuinely useful, but it says nothing about not-found behavior or error handling for an invalid number.
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?
A single front-loaded sentence with no filler; the resource and the returned field categories are stated up front and nothing is restated from the schema or annotations.
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 two-parameter read-only lookup with full schema coverage and rich annotations, the description covers what the tool returns well enough to call it correctly. Only the routing versus search_companies and not-found behavior are 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 description coverage is 100%, so both parameters (company_number with accepted formats, locale with its enum and nl default) are already documented in the schema. The description adds only the loose hint that the number is Belgian/KBO, so it meets the baseline without more.
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?
States a specific verb and resource ("look up KBO company information") plus the fields returned (address, legal form, NACE codes), which separates it from the sibling lookups on financials, employees, mandates and shareholders. It does not explicitly distinguish itself from search_companies, which is the closest ambiguity.
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 lookup framing implies usage — call it with a company number to retrieve profile data — but there is no explicit when-to-use statement, no note that a company number is required rather than a name, and no pointer to search_companies for name-based discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get employment averages, closing headcounts, FTE, entries, exits, hours and personnel costs for one accounting year.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Closing year; defaults to the latest available filing. | |
| company_number | Yes | Belgian company number; digits, dots, spaces and optional BE prefix are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description contributes the scope of returned data and the one-year framing, but says nothing about what happens when no filing exists for the requested year or how the data is structured.
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?
A single front-loaded sentence with no filler. The field enumeration is dense but each item earns its place by telling the agent what data comes back.
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 output schema, the description usefully summarizes the returned data categories, and the year parameter covers the temporal scope. What's missing is any indication of the return shape (flat vs. per-period breakdown) and behavior when the requested year has no filing.
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% and both parameters are documented there, including the year default and the company-number format. The description only reinforces the one-accounting-year scope, which is baseline-level added value.
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?
Specific verb (get) plus a precise resource (employment averages, headcounts, FTE, entries/exits, hours, personnel costs) scoped to one accounting year. The data set is clearly distinct from siblings like get_financials or get_shareholders, though the description never explicitly states that separation.
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 enumerated data fields imply the tool is the one to call when employment/personnel statistics are needed, but there is no explicit when-to-use statement, no prerequisites, and no pointer to a sibling tool for related data. Usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the financial summary for one accounting year.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Closing year; defaults to the latest available filing. | |
| company_number | Yes | Belgian company number; digits, dots, spaces and optional BE prefix are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds nothing beyond the annotations — no mention of what happens when no financials exist for the requested year, whether partial data is returned, or what the summary contains.
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?
A single efficient sentence with the scope qualifier placed last; nothing is wasted. It is slightly under-specified rather than verbose, but the structure is clean and easy to scan.
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 two-parameter read tool with rich annotations and a fully documented schema, most of what an agent needs is present. However, with no output schema, the description gives no indication of what a 'financial summary' returns or how missing-year cases behave, leaving a real gap.
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%: the year parameter documents the closing-year format and the latest-filing default, and company_number documents accepted Belgian formats. The description's 'one accounting year' phrasing only echoes the year parameter, so baseline 3 is appropriate.
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?
States a specific verb ('Get') and resource ('financial summary') with a scope qualifier ('one accounting year'). The resource is clearly distinct from siblings like get_company, get_employees, and get_shareholders, though the description does not explicitly name or contrast with any of them.
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 guidance on when to use this tool versus alternatives, nor any prerequisites such as whether the company must exist or whether filings must be available. The only selection logic (year defaults to the latest filing) lives in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current mandates held by a company in other companies.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Response language; defaults to nl. | |
| company_number | Yes | Belgian company number; digits, dots, spaces and optional BE prefix are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful 'current' and 'held in other companies' scope, but does not discuss return shape, permissions, or limits.
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?
It is a single front-loaded sentence with no filler or repetition. The key scope distinction is placed immediately in the description.
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 read-only tool with a complete input schema and no output schema, the description gives enough to understand the conceptual result. However, it does not clarify the returned mandate structure or explicitly contrast with get_mandates, leaving some selection ambiguity.
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%, so the company_number and locale parameters are fully documented in the schema. The description adds no parameter-specific meaning beyond what the schema already provides, which is acceptable at baseline 3.
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 a specific verb and resource: get current mandates held by a company in other companies. It distinguishes this from a generic mandates lookup by clarifying the outward-held scope, though it does not explicitly name the sibling get_mandates as the 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?
The phrase 'held by a company in other companies' implies when this tool applies versus a company's own mandates, but there is no explicit when-to-use/when-not-to-use guidance or named alternative such as get_mandates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current mandates in a company.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Response language; defaults to nl. | |
| company_number | Yes | Belgian company number; digits, dots, spaces and optional BE prefix are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering safety and idempotency. The description adds the useful qualifier 'current,' implying a point-in-time snapshot rather than historical data. It does not disclose return shape, pagination, or authorization needs, so it adds only modest value beyond 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 a single, front-loaded sentence with no filler. Every word contributes to stating the operation and its temporal scope. Brevity is appropriate for a simple two-parameter read tool.
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 read operation with full schema coverage and comprehensive annotations, the definition is minimally sufficient. However, it omits the key contextual distinction from get_held_mandates and does not clarify what a 'mandate' represents in this domain. An agent could still call it correctly but might choose the wrong sibling.
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%, so both the locale enum and company_number format are fully documented in the schema. The description adds no further parameter meaning beyond saying mandates are retrieved 'in a company,' which only restates that company_number identifies the target. Baseline 3 is appropriate when the schema does the heavy lifting.
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 a specific verb and resource: 'Get current mandates in a company.' An agent can understand the basic operation. However, it does not distinguish this from the sibling get_held_mandates, leaving ambiguity about which mandate set this returns.
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 explicit guidance on when to use this tool versus alternatives such as get_held_mandates or get_company. The phrase 'current mandates' implies a temporal scope but does not state exclusions or selection criteria. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get latest-known participations owned by a company.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Response language; defaults to nl. | |
| company_number | Yes | Belgian company number; digits, dots, spaces and optional BE prefix are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds one genuinely new behavioral fact — 'latest-known' signals a point-in-time snapshot rather than live data — but says nothing about pagination, completeness, or what happens when no participations exist.
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?
A single front-loaded sentence with no wasted clauses; the scope constraint arrives immediately. It is efficient but borders on under-specification given the unexplained domain term.
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 only two well-documented parameters and rich annotations, the description is minimally sufficient to invoke the tool correctly. However, with no output schema, a brief note on what a 'participation' record contains or how results are bounded would materially help, and that is absent.
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%, with company_number format (Belgian digits, optional BE prefix) and the locale enum fully documented in the schema. The description adds no additional semantics for either parameter, so baseline 3 applies.
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?
States a specific verb and resource ('get latest-known participations') scoped to a company, which separates it from siblings like get_shareholders and get_mandates. The term 'participations' is domain jargon left undefined, so an agent must infer what entity is returned, keeping it below 5.
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 explicit when-to-use guidance, no mention of prerequisites (e.g., needing a valid company number first), and no naming of alternative tools for related ownership data. Usage is only implied by the scope phrase 'owned by a company'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Belgian companies by exact name, then fuzzy name match.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| locale | No | Response language; defaults to nl. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, idempotent, closed-world operation, so the safety profile is fully covered. The description adds genuinely new behavioral detail about match ordering (exact then fuzzy), but says nothing about result caps, pagination, or ranking beyond that — useful but thin for a search tool.
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?
A single sentence with zero waste, and the most decision-relevant fact (exact-then-fuzzy matching on Belgian companies) is front-loaded.
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 output schema, the description carries the burden of explaining what comes back — a candidate list with identifiers that the agent can feed into get_company. That return-shape information is missing, leaving a gap for a search tool whose results drive downstream calls.
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 50%: locale is documented in the schema, while name has no schema description and must be inferred. The description partially compensates by implying name is matched exactly first and then fuzzily, which clarifies input semantics, but adds no format or normalization guidance.
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?
States a specific verb (search) and resource (Belgian companies) and even names the matching strategy: exact name first, then fuzzy. This clearly separates it from the get_* siblings, which are lookups rather than searches, though the description never explicitly draws that contrast.
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?
Usage is implied: supply a name to locate companies, as opposed to the sibling tools that presumably take an identifier. No explicit when-to-use/when-not guidance and no named alternative, so the agent must infer that search_companies is the entry point before get_company.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_companyget_employeesget_financialsget_held_mandatesget_mandatesget_participationsget_shareholderssearch_companiesBelgian company data: the CBE register, NBB annual accounts and the Belgian Gazette.
Company search and enrichment from official business registers in 200+ countries.
Search company records, officers, ownership, group structures and financials with provenance.
Danish company data (CVR) and annual-report financials for B2B lead research. Read-only.
Add one secure layer between your agents and this server.