entyrix-mcp

Filter companies (portfolio / market sizing)

advanced_search

Read-onlyIdempotent

Structured company search for portfolio building and market sizing — NOT for finding one known company (use search_companies). Filters: country, NACE prefix, status, region, turnover range (EUR), employee range, founding date range, VAT payer, tax debt, sanctions. Results are paged (limit + offset); the response says how many matched. Only the listed arguments exist — anything else is rejected, never silently ignored.

Input Schema

Name	Required	Description
`nace`	No	NACE code prefix, dotted or not: division '62' (IT services, same across all markets), group '62.0' / '620', class '62.01' / '6201'. Classes are national: SK, AT, SE, SI, BE, GR and LT store NACE Rev. 2.1 since 2025, so a class filter also matches the other revision's equivalent class (62.01 also finds Rev. 2.1 62.10). An invalid code is rejected with an error, never ignored.
`limit`	No	Page size (default 50).
`order`	No	Sort order (default turnover_desc).
`offset`	No	Rows to skip for the next page.
`region`	No	Region name exactly as the register spells it.
`status`	No	Company lifecycle status.
`country`	No	ISO 3166-1 alpha-2 country of the register (e.g. SK, CZ, AT, PL). Strongly recommended: registry numbers are NOT unique across countries (an SK and a CZ company can share the same 8-digit IČO), and without it the server picks one by tie-break.
`tax_debt`	No	Only companies on (true) / off (false) the tax-debtor list.
`vat_payer`	No	Only VAT-registered (true) or only non-registered (false).
`founded_to`	No	Founded on or before (YYYY-MM-DD).
`sanctioned`	No	Only companies with (true) / without (false) a sanctions hit.
`founded_from`	No	Founded on or after (YYYY-MM-DD).
`employees_max`	No	Maximum number of employees.
`employees_min`	No	Minimum number of employees.
`turnover_max_eur`	No	Maximum latest annual turnover in EUR.
`turnover_min_eur`	No	Minimum latest annual turnover in EUR.

Output Schema

Name	Required	Description	Default
`data`	No	Matching companies for this page, plus total count and any unknownFilters.
`meta`	No	Request metadata: request_id (quote it in support requests), duration_ms, cached.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 13, 2026

changedInput schema / properties / nace / description

Previous value: -"NACE code prefix, e.g. '62' (IT services) or '6201'."New value: +"NACE code prefix, dotted or not: division '62' (IT services, same across all markets), group '62.0' / '620', class '62.01' / '6201'. Classes are national: SK, AT, SE, SI, BE, GR and LT store NACE Rev. 2.1 since 2025, so a class filter also matches the other revision's equivalent class (62.01 also finds Rev. 2.1 62.10). An invalid code is rejected with an error, never ignored."

changedInput schema / properties / nace / pattern

Previous value: -"^[0-9]{1,8}$"New value: +"^[0-9]{2}(\\.?[0-9]{1,4})?$"

First observedOct 8, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds genuinely new behavior: results are paged via limit+offset, the response reports the match count, and unknown arguments are hard-rejected rather than silently ignored (consistent with additionalProperties=false). It stops short of noting result caps or what happens past the offset maximum, so it is not fully exhaustive.

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?

Front-loads the routing decision and the negative case in the first sentence, then compresses paging and error behavior into two short clauses. The middle filter enumeration is partly redundant with the schema but is cheap to scan and aids quick capability matching.

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?

An output schema exists, so return-value structure need not be described; the description still usefully notes paging mechanics and that a match count comes back. For a 16-parameter, all-optional filter tool with full schema coverage and annotations, nothing an agent needs to call it correctly is missing.

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 every one of the 16 parameters is already documented with format, ranges, and constraints in the schema. The description's filter enumeration (country, NACE prefix, status, turnover/employee ranges, etc.) largely restates what the schema already provides, adding no syntax or default detail beyond it. Baseline 3 applies 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Structured company search') plus the intended job ('portfolio building and market sizing'), and explicitly names the sibling it is not for ('use search_companies' for one known company). An agent can route between advanced_search and search_companies without opening either schema.

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?

Gives both a when-to-use condition (bulk filtering for portfolio/market sizing) and an explicit when-not with the alternative tool named (finding one known company -> search_companies). The filter list also signals the intended query shape.

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

All entyrix-mcp tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.