ares-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.2
Disambiguation5/5
Each tool has a clearly distinct purpose: searching, looking up, validating, checking status, retrieving registrations, standardizing addresses, cross-referencing persons, and exporting. The two search tools (by address vs. structured filters) are well-differentiated, and full_due_diligence is explicitly a composite.
Naming Consistency5/5
All tools follow the ares_ prefix with a verb_noun pattern (search_by_address, validate_ico, get_statutory_bodies, check_vat_payer, etc.). Even the slightly different 'full_due_diligence' is understandable and consistent with the overall style.
Tool Count5/5
14 tools is well within the ideal range for a domain-specific server. Each tool covers a distinct operation or data requirement, and the count feels appropriately comprehensive without being overwhelming.
Completeness5/5
The tool set covers the full lifecycle of querying Czech company data: search, lookup, validation, regulatory checks (insolvency, VAT), register-specific details (statutory bodies, trade licenses, RES classification), cross-company analysis, and output transformation. No critical gaps for typical ARES use cases.
Average 4.1/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden. The verb 'look up' implies a read-only operation, and the description clarifies that it returns aggregated data from multiple registries. However, it does not disclose potential error behaviors, rate limits, or any contingencies if a registry is unavailable, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the core action and resource. It lists the returned data categories without unnecessary elaboration, making it easy to scan and parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and lack of output schema, the description adequately conveys the tool's purpose and the type of data returned. It does not specify output formatting or error cases, but for a lookup tool with one parameter, the description is sufficiently complete for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides high coverage (100%) for the sole parameter, including normalization and Mod-11 checking. The description adds no additional meaning beyond restating that the lookup is by IČO, which is already explicit in the schema and tool name. Thus it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Look up') and a clear resource ('a Czech company by IČO'). It explicitly lists the types of data returned, which distinguishes it from sibling tools like ares_check_vat_payer or ares_get_trade_licenses that focus on narrower aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It states what the tool does but lacks any 'use this when' or 'for X use Y' direction, and does not mention exclusions or prerequisites beyond the IČO parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key outputs (canonical text, code, confidence score, up to N suggestions) and the external register, but does not mention potential failure modes, rate limits, or behavior on non-Czech addresses. It provides moderate transparency but not deep behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the action and purpose, then succinctly lists key outputs. No filler or redundancy—every clause contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, 1 required) and has no output schema. The description adequately covers the return values and purpose, but lacks note on RÚIAN coverage limitations or error conditions. For the complexity level, it is mostly complete, with only minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('adresa' and 'limit') well-described. The tool description adds only that suggestions are 'up to N', which is redundant with the 'limit' parameter. Since the schema already carries the parameter semantics, the description adds no significant extra value beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Standardize'), a clear resource ('free-form Czech address against the RÚIAN register'), and the output ('canonical address text, RÚIAN address-point code, and confidence score'). This distinguishes it from sibling tools like ares_search_by_address, which presumably searches rather than standardizes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for standardizing free-form addresses against RÚIAN, giving a clear usage context. However, it does not explicitly compare with sibling tools like ares_search_by_address or state when to choose this over alternatives, so guidance on usage vs alternatives is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the core behavior (filtering to active roles, cross-referencing two or more) and the output (structured cross-reference plus optional Mermaid graph). However, it doesn't mention validation of IČOs, potential errors, rate limits, or that it queries the Public Register (only implied in schema). This is a moderate disclosure for a read-only lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, with the primary purpose front-loaded and no redundant information. Every word contributes to understanding what the tool does and when to use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no output schema, and no annotations, the description adequately covers its complexity. It states what is returned (cross-reference and Mermaid graph) and provides context (due diligence scenarios). It could specify the structure of the cross-reference in more detail, but the current description is sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (icos, emitMermaid, includeHistorical) have detailed descriptions. The tool description adds minimal parameter-specific detail beyond the schema, but it does clarify the purpose of the cross-reference and the optional visualization. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's function: given a list of Czech IČOs, find natural persons/legal entities holding active statutory roles in two or more of them. It uses a specific verb ('find') and resource, and clearly distinguishes from sibling tools like ares_get_statutory_bodies by emphasizing cross-company overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases ('due diligence, holding-group mapping, undisclosed beneficial connections, nominee director detection') and implies it's for a 'small known set', offering practical guidance on when to apply this tool. It doesn't explicitly name alternative tools or state when not to use it, but the use-case framing is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Get' implies a read operation, and the output fields are listed, but there is no explicit statement about read-only behavior, error handling, rate limits, or authorization requirements. It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, then details the output fields and use cases. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, the description covers the return fields and intended use cases, providing a good overall picture. However, it does not mention edge cases like invalid ICO or missing data, which would complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the single parameter 'ico' with a description ('Czech IČO of the company'), achieving 100% coverage. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'gets statistical classification of a Czech company from RES' and enumerates specific data points (headcount, sector, CZ-NACE, FÚ, NUTS), distinguishing it from sibling tools like ares_get_statutory_bodies or ares_lookup_cz_nace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear use contexts ('B2B segmentation, reporting and policy-style analysis') but does not explicitly name alternatives or exclusionary criteria. This gives context without explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It specifies the query semantics (code or partial name) and implies read-only lookup, but it does not reveal result structure, match behavior, pagination, or any edge cases. Basic but minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action and resource, with no redundant phrasing. Every word contributes to understanding purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple lookup tool with two well-documented parameters and no output schema. The description conveys purpose and usage context, but since there is no output schema, a slightly richer note about the expected return shape (e.g., list of matching NACE entries) would make it fully complete. Overall it is nearly complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both query and limit documented in detail including examples. The tool description adds no additional parameter meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Look up' and clearly identifies the resource 'CZ-NACE (Czech industry classification) entries' with scope 'by code or partial name'. It also distinguishes itself from siblings by mentioning its role in filtering ares_search_companies by industry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: 'Useful when filtering ares_search_companies by industry', naming the related sibling tool. It does not explicitly state when not to use or contrast with ares_get_res_classification, but the guidance is unambiguous enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It does mention the output (IČOs, names, canonical address) and implies a read/search operation. However, it does not disclose matching behavior (e.g., exact vs. fuzzy), potential empty results, or pagination behavior beyond what the schema already provides. This is adequate but has gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: what it does, a practical use case, and the return format. It is front-loaded with the primary function and contains no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, but the description compensates by listing the key return fields. It explains the purpose, use case, and output enough for an agent to decide and invoke it. Minor gaps exist around matching behavior and edge cases, but overall it is sufficiently complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional parameter semantics beyond the schema; it mentions 'given address' but the schema already thoroughly describes adresa with examples. Limit and offset are fully described in the schema, so the description contributes nothing extra.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find all Czech companies') and clearly identifies the resource (companies by registered seat) and the matching criterion (a given address). It distinguishes itself from siblings like ares_search_companies and ares_lookup_company by focusing on address-based bulk search and explicitly mentions the returned fields (IČOs, names, canonical address).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case for shell-company or virtual-office detection, which implies when to use this tool. However, it does not explicitly contrast with alternatives or state when not to use it, leaving some ambiguity relative to sibling tools like ares_standardize_address.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the data sources read (seznamRegistraci for IR and CEÚ), the return format (isInsolvent plus state codes), and implies read-only behavior through 'check' and 'reads'. It does not mention edge cases (e.g., missing ICO) or rate limits, but covers the core behavioral expectations for a simple lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four short sentences, each serving a purpose: purpose, data source, output, and use case. It is front-loaded with the 'fast red-flag check' phrase, making the tool's essence immediately clear. Slightly verbose but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the essential aspects: what it does, how it works (reads specific registers), what it returns, and when to use it. It lacks mention of error conditions or limitations, but for a single-purpose check, it is substantially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the `ico` parameter is fully described as 'Czech IČO of the entity to check'). The description does not add additional meaning beyond the schema; it merely reinforces that the entity is Czech. Per the rubric, high schema coverage yields a baseline of 3, and no extra value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: a fast red-flag check for Czech entity insolvency/bankruptcy. It specifies the exact data source (ARES seznamRegistraci for IR and CEÚ) and output (isInsolvent boolean + state codes), distinguishing it from sibling tools that perform broader lookups like ares_lookup_company or ares_full_due_diligence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('pre-contract sanity check') and positions the tool as 'fast' versus more comprehensive alternatives. However, it does not explicitly name alternatives or state when not to use it, leaving some ambiguity about placement relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return fields and data source, which is helpful. However, it does not explicitly state read-only nature, authentication requirements, or error behavior. 'List' implies a read operation, but more explicit behavioral context would be useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action and followed by useful return details. No redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list operation with no output schema, the description sufficiently explains what data will be returned and from which source. It is complete enough for an agent to invoke the tool correctly and understand the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the only parameter 'ico' as 'Czech IČO of the entity' with 100% coverage. The description adds no additional parameter-specific detail, so it meets the baseline for schema-covered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists trade licenses (živnostenská oprávnění) of a Czech entity from the Trade Register (RŽP), and specifies the returned data (subject, type, validity period, fields of activity). This specific verb+resource+scope distinguishes it from sibling tools like ares_get_statutory_bodies or ares_lookup_company.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: for Czech entities needing trade license data from RŽP. It does not explicitly mention alternatives or exclusions, but the context is sufficiently evident. Unlike a 5, it lacks an explicit reference to sibling tools or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple 'checks status' by explaining the return convention ('if active'), the ARES delay (up to 24h), and pointing to an authoritative alternative. However, it does not state what happens when the entity is not a VAT payer (e.g., returns null/false) or any error conditions, leaving minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using two sentences to convey the core functionality, return value, and a critical caveat. It is front-loaded with the action and resource, with no redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the purpose, return value, a caveat, and an authoritative alternative. It is almost complete, but lacks explicit handling for non-registered entities and error scenarios. Given the low complexity, this is strong but not perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains both `ico` (Czech IČO) and `expectedDic` (optional DIČ for cross-check). The tool description adds no additional meaning to these parameters beyond the schema, so it meets the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and a clear resource ('whether a Czech entity is registered as a VAT payer based on ARES'), distinguishing it from sibling tools that focus on company lookup, validation, or due diligence. It also specifies the return value ('Returns the IČ DPH (= DIČ) if active'), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to check VAT payer status via ARES) and provides a clear alternative: the authoritative source is MFČR (adisspr.mfcr.cz) because ARES may be delayed up to 24h. This effectively tells users not to rely on this tool for real-time legally authoritative status, though it does not explicitly state 'use this when...'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool performs a pure data transformation, makes no external calls, and returns a paste-ready/post-ready object with only identification and address fields. This is valuable behavioral context that goes beyond the tool name, though it does not discuss error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and every sentence adds unique information: the target formats, the no-calls caveat, and the output scope. There is zero waste or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters and no output schema, the description adequately explains the output shape and field coverage. It names the target-specific formats and the caller's responsibility. It could mention error cases (e.g., ICO not found) but is sufficient for a simple transformation tool with clear schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the target format and the overall purpose but adds no extra per-parameter syntax or constraints beyond what the schema already states. The schema's target enum descriptions are already detailed, and the description does not need to repeat them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Transform') and resource ('ARES company profile into a payload'), names three concrete target systems (Fakturoid, iDoklad, Pohoda), and clearly distinguishes this from all sibling ARES search/validation tools. It leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is a pure data transformation with no calls to the target system, and the output fills identification + address fields while the caller supplies the rest. It does not explicitly name alternatives or say 'use when X, not when Y', but the unique purpose makes that unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses the output format (structured report, risk flag, Markdown summary) and the specific data sources consulted. It does not discuss error handling, speed, or risk flag logic, but for a read-only aggregate tool, this is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that front-load the purpose and then detail the output and integration benefit. No redundant information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description adequately explains the return value (structured report, risk flag, Markdown summary). It also lists the data sources aggregated. Some specifics like the report structure or risk determination criteria are missing, but for an agent to invoke the tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter (ico) with a clear description 'Czech IČO of the company,' so the baseline is 3. The tool description adds no additional parameter-specific meaning, which is acceptable given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetches' and 'returns' to describe a composite due-diligence report, listing the data sources (ARES profile, Public Register, Trade Register, insolvency status, dissolution date). It clearly differentiates from sibling individual lookup tools by explicitly stating it replaces 4–5 individual lookups with a single call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states 'Replaces 4–5 individual lookups with a single call,' indicating use for comprehensive due diligence instead of making multiple individual requests. It does not explicitly name sibling alternatives or when not to use (e.g., if only one data point is needed), but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key behavior: 'By default returns currently-active members only.' It also mentions the source (Public Register VR) and implies a read-only operation via 'List'. No side effects or contradictions are present, but it omits details about return format and error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core function, the second adds default behavior and use cases. It is concise, front-loaded, and every sentence contributes. No filler or repetition exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters and no output schema, the description covers the essential aspects: what it lists, default filtering, and common use cases. However, it does not describe the output structure or error behavior, which would be helpful given the lack of an output schema. Overall, it is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (ico and includeHistorical), and the description does not add further parameter-level semantics beyond restating the default active-only behavior in the tool description. With 100% schema coverage, the baseline is 3, and no additional value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List statutory bodies (jednatelé, představenstvo, dozorčí rada) of a Czech company from the Public Register (VR).' It uses a specific verb (List) and a specific resource (statutory bodies), and distinguishes from sibling tools by naming the exact types of entities covered.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Useful for due diligence, KYC, and verifying who is authorised to sign contracts.' It implies when to use this tool but does not explicitly contrast it with alternatives or state when not to use it. This fits the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the pure, side-effect-free nature, the lack of ARES calls, and the return value (normalized IČO and validity). Minor edge cases like error behavior for malformed input are not described, but this is acceptable for a pure validation function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb and resource, with zero filler or redundancy. Every clause contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with one parameter fully covered by the schema. The description states the return fields explicitly, making it complete despite the lack of an output schema. Any missing error-behavior details are non-critical for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, fully documenting the `ico` parameter with examples. The description adds no additional parameter semantics beyond referring to the normalized output, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a Czech IČO using the ČSÚ Mod-11 checksum and identifies it as a pure function. It explicitly contrasts with the ARES lookup siblings by saying 'does not call ARES,' making its scope unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Pure function — does not call ARES' signals this is for quick local validation rather than authoritative ARES lookups, giving clear context. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses a critical behavioral requirement (at least one filter) and output characteristics (paginated results with totals), which go beyond the schema. However, it doesn't describe error handling, query combination semantics (e.g., AND/OR), or potential rate limits, so some behavioral gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal yet informative: three sentences cover the core action and filter list, the usage constraint, and the output format. No filler words or redundant details, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (7 parameters, no output schema), the description provides a solid summary of purpose, usage constraint, and output. It mentions pagination and totals, which is helpful without an output schema. However, it could more explicitly contrast with sibling tools to prevent mistaken selection, so it's not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 7 parameters, setting a baseline of 3. The tool description adds value by summarizing the key filter groups and introducing the 'at least one filter' constraint, which is not represented in the schema (no required fields). This elevates the semantic guidance beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search Czech companies by structured filters' and enumerates the specific filter types (name, postal code, municipality, legal form, CZ-NACE). This distinguishes it from sibling tools like ares_search_by_address (address-based) and ares_lookup_company (exact company lookup).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear operational guideline: 'At least one filter is required to avoid full-registry scans,' indicating when the tool should be used and warning against parameter-less calls. It implies structured filter searches are the intended use but doesn't explicitly mention alternatives or exclusions relative to sibling tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ares-mcp MCP server](https://glama.ai/mcp/servers/milos106/ares-mcp/badges/card.svg)](https://glama.ai/mcp/servers/milos106/ares-mcp)

Score Badge

Copy to your README.md:

[![ares-mcp MCP server](https://glama.ai/mcp/servers/milos106/ares-mcp/badges/score.svg)](https://glama.ai/mcp/servers/milos106/ares-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/milos106/ares-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server