entyrix-mcp

Server Quality Checklist

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

Latest release: v0.1.4
Disambiguation5/5
Each tool has a clearly distinct purpose: fuzzy name search vs structured multi-filter search, identity-only lookup vs full-profile fetch, officer-based network vs full relationship graph with UBO and M&A layers. Even overlapping tools like get_financials and get_company_details are explicitly differentiated as multi-year financial statements vs full company envelope, leaving no ambiguity.
Naming Consistency4/5
All tool names are snake_case and most follow the verb_noun pattern (search_, lookup_, get_, check_, find_, list_). The only deviation is 'advanced_search', which uses an adjective+noun form without a verb prefix, slightly breaking the otherwise consistent convention.
Tool Count5/5
With 10 tools, the server is well-scoped for a company data intelligence platform. Each tool covers a distinct feature—discovery, identity, details, financials, relationships, compliance, supplier contracts, and rankings—without redundancy or bloat.
Completeness4/5
The tool surface covers the core domain comprehensively: search, lookup, details, financials, network/relations, compliance, supplier data, and rankings. Minor gaps exist for non-SK compliance and broader EU procurement, but these are explicitly noted as roadmap items, and the main workflows are fully supported.
Average 4.5/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 26 commits in the last 12 weeks
- Last stable release on August 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals the public route, authentication via MCP client, and geographical limitation. It also lists the exact registries checked, providing useful operational context beyond the schema.
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?
Three sentences: first states the core purpose, second explains auth behavior, third gives market scope. Everything earns its place with no redundancy or fluff.
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 description provides a thorough list of check types, geographical scope, and authentication behavior. Despite lacking an output schema, it gives a strong sense of what the tool returns. Minor gaps include error handling and return format, but for a single-param tool this is quite 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% for the single 'ico' parameter, which already includes detailed constraints (6-8 digits, pattern, market limitation). The description adds no param-specific details, 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 it performs a compliance check for a Slovak company and enumerates specific data sources (AML/sanctions, debtor lists, insolvency, RPVS, regulatory flags). This distinguishes it from sibling tools like search_companies or get_financials, which serve different purposes.
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 explicit usage context: SK-only, public route with no server-side API key but routed through authenticated client, and notes CZ/AT are not yet available. It doesn't explicitly name alternatives, but the domain (compliance vs. search/details) makes the when-to-use clear.
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 behavioral transparency burden. It discloses the data source (SK CRZ), return fields, and a data quality caveat ('CPV code where available'). It also honestly limits scope to SK. It does not mention pagination or error behavior, but these are covered by the schema, and the tool is clearly a read-only listing.
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 moderately long but front-loaded with the core action and resource. The additional sentences about data source, scope, and use case are valuable and not redundant. It could be slightly tighter, but each 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?
There is no output schema, so the description enumerates returned fields (contract value, buyer, signing date, subject, CPV) and provides business context. It also mentions the data source and geographic limitation, giving an agent enough context to invoke correctly. A minor gap is that it does not explicitly state the input ICO is the supplier, though that is strongly implied.
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% with detailed parameter descriptions (e.g., ICO format, limit cap, years example). The description adds no parameter-specific meaning beyond output expectations, so the baseline of 3 is appropriate. It does not need to repeat what the schema already documents.
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 the specific verb 'List' with a clear resource ('public-sector contracts') and relationship ('where the given company is the supplier'). It distinguishes itself from siblings by explicitly stating it is SK-only and referencing the planned TED-search tool for broader EU coverage, making its purpose unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: for B2G exposure analysis and supplier due diligence. It also gives an explicit exclusion: for broader EU procurement signal, use the planned TED-search tool (not yet exposed), and notes the SK-only limitation, which helps an agent decide when not to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, and it does so well. It warns that totals are capped at 5000 and that `pagination.isCapped` indicates truncation, and it explains that keys in `data.unknownFilters` were dropped, making results broader than requested. These are non-obvious behaviors that materially affect correct interpretation of results.
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 and front-loaded: the first clause states the purpose, then each subsequent sentence adds a critical operational caveat (cap, unknown filters, usage example). There is no redundant or filler content; 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 high complexity (58 parameters, no annotations, no output schema), the description provides a strong broad overview and the most critical runtime caveats. It doesn't spell out every pagination mechanism or filter-combination rule, but the schema fills many gaps, making this sufficiently complete for a complex 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?
The description adds only high-level parameter context, such as the `tech=` example and the analyst-style query pattern. With 58 parameters and 67% schema description coverage, the schema carries most of the parameter semantics; the description does not systematically compensate for the undocumented remainder, so this is adequate but not exceptional.
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 and resource: 'Structured multi-filter company search' across a detailed list of dimensions (registry, geography, sector, size, financials, credit/distress, sanctions, NIS2, cyber, digital footprint, public money). It also states the return shape (paginated list, per-country breakdown) and gives a concrete example query, making it unmistakable what this tool does and how it differs from simpler sibling search tools.
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 an explicit use case: 'Use for analyst-style queries like...' and provides a concrete multi-filter example. However, it does not explicitly say when NOT to use this tool or mention alternative sibling tools such as search_companies, so it lacks the when-not/alternatives element needed for 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, the description carries the burden of behavioral disclosure. It reveals typo-tolerance via autocomplete index, p95 latency, return fields, and market coverage. It does not explicitly state read-only status, but the tool name and 'search' semantics imply it.
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 four sentences, each providing distinct value: action, performance, return fields, use case, and coverage. It is front-loaded and free of filler, making it effectively concise.
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 no output schema and no annotations, the description adequately covers the tool's scope and return fields. It could mention result structure or pagination, but it is otherwise 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 coverage is 100% with each parameter described. The description adds slight context by mapping q to name/partial/address, but does not provide additional semantic detail for limit, country, or active_only beyond what the schema already offers.
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 searches European companies by name, partial name, or address. It distinguishes itself from sibling tools by targeting fuzzy queries and returning ranked hits with specific fields, while explicitly mentioning lookup_company and get_company_details for follow-up.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use this for fuzzy find a company called… queries before drilling into details with lookup_company or get_company_details.' This gives both when to use and names alternatives, making the usage context very clear.
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 source per jurisdiction, that amounts are in EUR with a `unit` field, that ROA/ROE are ratios, and that it is an extractor over get_company_details. It does not discuss error handling or missing data scenarios, but the core behavioral context is well covered.
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, followed by units/source and the implementation note. Every sentence earns its place and there is no redundant or verbose language.
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?
Despite lacking an output schema, the description fully explains what is returned (list of annual statements, specific financial metrics, units, ratios). Combined with the detailed parameter schema and clear sibling differentiation, the tool context is complete for effective selection and invocation.
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 per the rubric, the baseline is 3. The description adds no parameter-specific semantics beyond what the schema already provides; it only mentions jurisdiction in the context of the data source, not the parameter meaning.
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 ('Return') and resource ('most-recent annual financial statements') and enumerates the exact fields (turnover, total assets, equity, profit, EBITDA, ROA, ROE). It also distinguishes itself from siblings by branding itself as a 'thin extractor over get_company_details', which clearly separates it from the broader lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'saves the LLM from parsing the full company envelope when only financials are needed.' It also names the alternative (get_company_details) and provides jurisdictional source guidance, making the use cases clear.
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?
No annotations are provided, so the description carries the transparency burden. It discloses that responses are cached for 15 minutes and are millisecond-fast, indicating potential staleness and performance characteristics. It does not explicitly state read-only nature, but 'fetch' and 'pre-computed' imply no side effects, and the enum constrains inputs. One minor gap is the lack of info on response format, but that is not critical given the tool's simplicity.
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 action, then enumerates the slugs, and closes with a practical usage tip. Every sentence adds value with no fluff or redundancy.
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 single-parameter tool with no output schema, the description fully covers purpose, usage, cache behavior, and even provides a rationale for its existence. It is complete enough for an agent to select and invoke this tool correctly without further clarification.
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%, with the 'key' parameter description already explaining each enum value fully. The tool description adds no additional parameter-level semantics beyond restating the same four slugs and adding context about the top-100 nature. This 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 fetches a pre-computed company leaderboard by slug, enumerating exactly four specific rankings. This distinguishes it from sibling search/lookup tools by highlighting that it serves pre-assembled top-N lists rather than arbitrary queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: for 'top 100 …' style queries the LLM would otherwise assemble from many advanced_search calls. It also lists the exact four valid slugs, providing clear alternatives with advanced_search and implicitly excluding other use cases.
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 behavioral disclosure burden and does so well: it reveals country-aware routing, support for multiple national ID formats, and a defined return type ('single company object with core identity, address, legal form, status flags'). It doesn't cover error/edge behavior, but the core behavior is transparent.
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 main purpose, and every clause adds functional value—alternatives, shapes handled, and return contents. No filler or redundancy.
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?
Despite no output schema, the description specifies what the returned object contains and covers the main complexity (different national ID shapes and country disambiguation). For a lookup tool, this is complete enough for an agent to confidently 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?
Schema description coverage is 100%, so the schema already fully documents both parameters including format examples and the SK↔CZ collision issue. The description adds context about 'all our shapes' but largely repeats schema content. The baseline of 3 applies because the description doesn't significantly augment the schema.
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 opens with a specific action—'Resolve a single company by its national registry identifier'—and explicitly scopes the tool to country-disambiguated lookups by national ID. It also differentiates from sibling tools by contrasting with search_companies for name-based discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Use this when you already know the registry number'. It also gives an alternative: 'use search_companies for name-based discovery', which clearly directs the agent to the right sibling.
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 disclosure burden. It reveals a specific behavioral quirk: 'For SK↔CZ 8-digit collisions the API picks the active SK match first' – useful non-obvious information. It does not mention error handling, rate limits, or explicitly state read-only, but the 'Fetch' verb and output list imply a safe read operation. The disclosed collision behavior goes beyond typical descriptions.
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, tightly packed with essential information. The first sentence front-loads the main action and output scope; the second addresses an important caveat. No filler or redundant wording.
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?
Despite no output schema, the description comprehensively lists the categories of data returned (identity, address, NACE, finances, tech signals, security, NIS2, sanctions, credit), giving the agent a clear picture of what to expect. It also covers the disambiguation context. For a read operation with good parameter schema, this is complete enough for effective invocation.
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 detailed parameter descriptions, so the baseline is 3. The description adds value by explaining the purpose of 'country' in disambiguating 8-digit IČO collisions and noting it is required for non-SK/CZ identifiers, complementing the schema's field-level descriptions.
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 + resource: 'Fetch the full company profile by IČO' and enumerates exactly what is returned (identity, registered address, NACE, legal form, status, latest financials, tech stock/website/SSL signals, security findings, NIS2 scope, sanctions hits, credit score). It explicitly contrasts with sibling 'lookup_company (which is identity-only)', clearly distinguishing its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance by stating it is 'Richer than lookup_company' and directly advises using 'lookup_company with explicit country for deterministic disambiguation' when SK↔CZ collisions occur. This tells the agent exactly when to prefer which tool, including an alternative for a specific edge case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral burden. It discloses auth requirements (Bearer-auth + FO-gated), the refusal for sole traders without FO addendum, the minimization of UBO data (birth year only), the legacy IČO keying limitation, and the public-official flag. This goes well beyond what annotations would typically provide.
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 a single dense paragraph, but every sentence contributes (content list, sibling differentiation, auth/limitation notes). It is longer than ideal but appropriately packed for a tool with this complexity. Slightly better structure (e.g., bullets) would make it a 5.
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?
Despite no output schema, the description enumerates all return components (officers, UBO with validity windows, related companies, corporate shareholders with IČO resolution, M&A events). It also covers limitations, auth context, and parameter usage. This is complete for an agent to invoke correctly.
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%, so the baseline is 3. The description adds meaningful context: purpose is 'only needed for full-tier keys when the subject is a natural person', 'ignored for legal entities', and the IČO limitation is reiterated. This adds practical usage nuance beyond the schema definitions.
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 opens with 'Full relationship graph for one company' and enumerates exactly what is included (directors, shareholders, UBO, related companies, corporate shareholders, M&A events). It also explicitly contrasts with get_company_network, making the specific scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use get_company_network to walk company→company hops, use this to enumerate a single company's owners and officers.' It also states when the endpoint is not reachable (non-IČO markets) and the FO-gated auth conditions, clearly indicating appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the empty-result semantics (not isolated), the FO gate requirement for sole traders, bearer-auth requirement, and the walkable graph structure. This gives agents a realistic behavioral model.
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 detailed yet each sentence serves a purpose: functionality, usage, edge-case semantics, alternative guidance, and auth. Front-loaded with the core purpose and progressively adds nuance. No fluff.
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 complex graph-traversal tool with no output schema, the description covers return value structure, pagination-walkability, edge cases, and auth constraints. It is self-contained enough for an agent to use it correctly and know when to switch to another tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though the schema covers 100% of parameters, the description adds context beyond the schema for the 'purpose' parameter (only needed for natural-person sole traders, ignored for legal entities, marketing/prospection invalid). It also reinforces the 'ico' constraint about markets keyed on legacy IČO.
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: it builds a company-to-company network via shared officers/shareholders. It differentiates from siblings by explicitly positioning it as the 'primary network-walk primitive' and references get_company_relations for alternative edge types (UBO/M&A).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and alternatives: 'feed a returned IČO back into get_company_network to traverse another hop' and 'try get_company_relations for UBO / M&A edges'. Also clarifies the empty-result case with guidance to try another tool.
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:

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

Score Badge

Copy to your README.md:

[![entyrix-mcp MCP server](https://glama.ai/mcp/servers/juliusgerman/entyrix-mcp/badges/score.svg)](https://glama.ai/mcp/servers/juliusgerman/entyrix-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/juliusgerman/entyrix-mcp'

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