Karpata – company data from public registers

Ask about companies

ask

Ask a question in Slovak, Czech, Romanian or English about companies in Karpata's AI index (a prototype sample of firms in Slovakia, Czechia, Poland and Romania). The answer uses only register data, cites the companies as [n] with links and provenance, or says it did not find it. Questions about natural persons are refused. A question about today's VAT status or risk runs check_vat or get_risk live (charged and recorded as those). Costs credits.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "question": "<question>"
    },
    "name": "ask"
  }
}

Input Schema

Name	Required	Description	Default
`lang`	No	Optional language of the answer; default: the question's.
`question`	Yes	The question, at most 500 characters.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 1, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: answers are grounded only in register data, cite companies as [n] with links and provenance, may return a not-found result, refuse person queries, and that live checks are charged and recorded as those tools. The credit-cost disclosure explains the readOnlyHint=false / idempotentHint=false profile rather than contradicting it.

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?

Four sentences, all front-loaded and free of filler; the routing and cost information are packed densely but every clause carries load. Slightly overstuffed sentences keep it from 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?

With no output schema, the description carries the burden of describing return behavior, and it does: citations with links and provenance, a possible not-found answer, and refusal behavior. Combined with the routing and cost notes, an agent has everything needed to call it correctly.

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%, so both parameters are already documented, including the lang enum and its default behavior. The description restates the language set but adds no format constraints (e.g., the 500-character limit or phrasing guidance) beyond the schema, so baseline 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?

States a specific verb and resource: answer a natural-language question about companies in Karpata's AI index, with an explicit geographic scope (SK, CZ, PL, RO) and supported languages. An agent can distinguish it from record-fetching siblings like get_company or 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 Guidelines4/5

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

Gives an explicit routing rule: questions about today's VAT status or risk should go to check_vat or get_risk instead. It also names an exclusion (questions about natural persons are refused). It does not address when to prefer ask over search_companies or get_company, so it falls short of full alternative coverage.

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

All Karpata – company data from public registers 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.

Resources

Need Help?