Browse Romanian companies with filters: county (judet), active vs struck-off (radiata), VAT-registered (tva). Paginated. 10 credits/page.
| Name | Required | Description | Default |
|---|---|---|---|
| tva | No | true = VAT-registered only (optional) | |
| page | No | ||
| judet | No | County, e.g. CLUJ (optional) | |
| api_key | Yes | Your DACIX API key (dacix_sk_...). Get one with store_register. | |
| radiata | No | false = active only (optional) | |
| per_page | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It mentions pagination and credit cost but does not disclose default behavior when no filters are applied (e.g., returns all companies?), error conditions, rate limits, or authentication requirements beyond the schema. The description is too sparse for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence, front-loaded with 'Browse Romanian companies with filters'. It efficiently lists the key features. However, it might be too short to be fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with multiple filters, pagination, and a required API key, the description is incomplete. It lacks details on default behavior, pagination semantics (how page/per_page work), credit cost per page without clarifying cumulative costs, and expected response format. No output schema exists, so additional context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps filter names to parameters (judet, radiata, tva), adding minimal clarification beyond the schema descriptions. Schema coverage is 67% (page and per_page lack descriptions), and the description mentions pagination but does not explain the page/per_page parameters. It adds some value but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Browse Romanian companies with filters' and lists specific filters (judet, radiata, tva). It distinguishes from sibling tools like ro_company_lookup (single lookup) and ro_company_search (search by name) by focusing on browsing with filters and pagination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that for a single company lookup one should use ro_company_lookup or for name-based search use ro_company_search. The description lacks context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.