Lead Strategist: Danish CVR company data

Recommend B2B leads

recommend_leads

Read-onlyIdempotent

Ranked lead shortlist from CVR filters (read-only). Scores the 500 highest-revenue matches (revenue, employees, email, phone) and returns them best first; page with limit and offset. Includes GDPR contact warnings.

Input Schema

Name	Required	Description
`city`	No	Postal town (postdistrikt) as a prefix match, or a 4-digit postal code, e.g. 'Aarhus' (matches 'Aarhus C' and 'Aarhus N') or '8000'.
`limit`	No	Number of leads to return (1 to 25), e.g. 10. Default 10.
`offset`	No	Number of ranked leads to skip, for paging, e.g. 10 for page 2 with limit 10. Default 0. Ranking covers the 500 highest-revenue matches, so offset is at most 499.
`region`	No	Danish region, e.g. 'Midtjylland'. One of Hovedstaden, Sjælland, Syddanmark, Midtjylland, Nordjylland ('Region ' prefix optional).
`max_revenue`	No	Maximum revenue in DKK from the latest annual report, e.g. 50000000 for 50 million DKK.
`min_revenue`	No	Minimum revenue (omsætning) in DKK from the latest annual report, e.g. 10000000 for 10 million DKK.
`municipality`	No	Municipality (kommune) of the current CVR address, by name or code, e.g. 'Aarhus', 'Københavns Kommune' or '751'.
`industry_code`	No	Exact Danish industry code (DB25/NACE, up to 6 digits), e.g. "621000" (computer programming).
`max_employees`	No	Maximum average number of employees from the latest annual report, e.g. 50.
`min_employees`	No	Minimum average number of employees from the latest annual report, e.g. 10.
`status_contains`	No	Case-insensitive part of the CVR status (Danish), e.g. "normal" or "aktiv" for active companies, "konkurs" for bankruptcy.
`industry_contains`	No	Case-insensitive text match on the industry name and secondary industries (Danish), e.g. "tømrer", "software" or "restaurant".
`company_name_contains`	No	Case-insensitive part of the company name, e.g. "Novo" or "Carlsberg".
`exclude_reklamebeskyttelse`	No	Leave out companies with reklamebeskyttelse (marketing protection, may not be contacted for marketing). Default true; set false only for research, not outreach.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 6, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotent/non-destructive, and the description is consistent with that ('read-only'). It adds real behavioral context beyond the annotations: ranking covers only the 500 highest-revenue matches, results come back best-first, paging via limit/offset, and GDPR contact warnings are attached.

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 tight sentences, each earning its place: ranking/scope first, then scoring and ordering, then paging and the GDPR caveat. No filler or redundancy.

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, zero-required, no-output-schema tool with full annotation coverage, the description supplies the key extras an agent needs: result fields, ordering, paging limits, and GDPR warnings. It stops short of describing pagination exhaustion or result cardinality behavior, but nothing essential 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 the schema already documents all 14 filters, including the offset cap and prefix-match rules. The description restates paging and the 500-match ranking ceiling but adds no filter syntax or semantics beyond the schema; baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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

States a specific verb+resource ('ranked lead shortlist from CVR filters') and the ranking behavior, which meaningfully separates it from search_companies. It never names a sibling explicitly, so the differentiation is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied: reach for this when you want a ranked lead shortlist rather than raw search results. There is no explicit when-to-use/when-not guidance and no mention of search_companies as the unranked alternative, leaving the routing choice to inference.

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

All Lead Strategist: Danish CVR company data 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?