Sk Rpo

Rpo Search Entity

rpo_search_entity

Read-onlyIdempotent

Search the Slovak Register of Legal Entities (RPO) for companies, sole traders and public bodies. Matches are a diacritics-insensitive SUBSTRING search (e.g. "s" matches "š"), not relevance-ranked, so a short or common query can return hundreds of unrelated hits — use the fullest name you have, or the IČO, for a specific match. Legal-form suffixes (s.r.o., a.s., k.s., etc.) are part of the stored name and can be included or omitted. At least one filter is required. Returns each match's internal id (pass to rpo_entity_detail for the full record), current/historical names, IČO, addresses and establishment/termination dates. The upstream caps results at 500; narrow the query if you hit that.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "fullName": "ESET, spol",
      "onlyActive": true
    },
    "name": "rpo_search_entity"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Max results to return (default 20, max 100). The upstream itself may have already matched more — see `total_returned_by_api`.
`fullName`	No	Company/entity name, full or partial, e.g. "ESET" or "Slovak Telekom". Diacritics-insensitive substring match.
`legalForm`	No	Legal form, e.g. "Akciová spoločnosť" (joint-stock), "Spoločnosť s ručením obmedzeným" (s.r.o.).
`identifier`	No	IČO — the 8-digit Slovak business identifier, e.g. "31333532". Exact match when 3+ digits.
`onlyActive`	No	true to exclude terminated/wound-up entities.
`addressStreet`	No	Street of the registered address.
`terminationAfter`	No	Only entities terminated/wound up on/after this date, YYYY-MM-DD.
`terminationBefore`	No	Only entities terminated/wound up on/before this date, YYYY-MM-DD.
`establishmentAfter`	No	Only entities established on/after this date, YYYY-MM-DD.
`addressMunicipality`	No	Municipality of the registered address, e.g. "Bratislava".
`establishmentBefore`	No	Only entities established on/before this date, YYYY-MM-DD.
`stakeholderCompanyName`	No	Find entities where a stakeholder (owner/partner) is a company matching this name.
`statutoryBodyFamilyName`	No	Find entities where a statutory-body member (director/executive) has this family name.
`stakeholderPersonFamilyName`	No	Find entities where a stakeholder (owner/partner) is a person with this family name.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only cover the read-only/idempotent/open-world safety profile; the description adds the substantive behavior an agent actually needs — diacritics-insensitive SUBSTRING matching, no relevance ranking, legal-form suffixes being part of the stored name, the mandatory-filter rule, and the 500-result upstream ceiling. It also discloses what is returned, including the internal id used to chain to the detail tool.

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-loaded with purpose, then matching semantics, then the calling caveat, then return contract — the ordering matches how an agent needs the information. It is dense and nearly every clause carries operational content, though the legal-suffix detail could arguably be folded into the fullName hint.

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 14-parameter search with no output schema and only safety annotations, the description covers matching behavior, query strategy, the result cap, and the shape of the response — enough to call it correctly. The only real gap is that the individual filter semantics are delegated entirely to the (fully documented) schema, which is a reasonable trade.

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, but the description goes beyond the field docs by explaining how fullName and identifier actually behave in practice (short queries over-match; prefer the fullest name or the exact IČO) and by flagging that the returned total can exceed the requested limit. The remaining eleven filters are left entirely to 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?

Names a specific verb and resource (search the Slovak Register of Legal Entities) plus the entity scope (companies, sole traders, public bodies), and explicitly routes the follow-up to rpo_entity_detail. An agent can distinguish it from the detail lookup 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete query-construction guidance (use the fullest name or the IČO for a specific match, at least one filter required, narrow the query when the 500 cap is hit) and names the sibling to use for full records. It does not address the other entity-ish siblings such as company_register_search or resolve_entity, so routing across the broader catalogue is still left to inference.

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

All Sk Rpo 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.