Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@boligmcp Fetch property info for Skindergade 7, 1159 København K."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that takes a Danish address and gathers public property data from official registers.
It does not use DAWA (dawa.aws.dk closes 1 October 2026). Address search goes through Adressevælgeren; register lookups go through Datafordeleren GraphQL.
Protected owner names of private individuals are never requested.
npx boligmcpOr clone and run locally:
pnpm install
pnpm build
node dist/index.js{
"mcpServers": {
"boligmcp": {
"command": "npx",
"args": ["-y", "boligmcp"],
"env": {
"DATAFORDELER_API_KEY": "your-key"
}
}
}
}Local checkout:
{
"mcpServers": {
"boligmcp": {
"command": "node",
"args": ["/absolute/path/to/boligmcp/dist/index.js"],
"env": {
"DATAFORDELER_API_KEY": "your-key"
}
}
}
}Copy .env.example to .env when running from a checkout. Missing keys never crash the server; the matching source returns unavailable.
Related MCP server: mcp-dawa
Tool | When to use |
| Free-text Danish address → DAR ids |
| Address id → BFE, cadastral ids, coordinate |
| BBR buildings and units |
| Matrikel parcels for a BFE |
| Official VUR values and history |
| Non-protected EJF trades / ownership type |
| Municipality, region, parish, districts |
| Local plans, municipal frameworks, zone |
| Soil, §3 nature, conservation, coastal/forest lines |
| Energimærke (needs EMOData) |
| Municipality statistics from DST |
| Parallel combined report (~4k tokens) |
| Which sources are configured |
Every tool returns a SourceResult: either { status: "ok", source, fetchedAt, data } or { status: "unavailable", source, reason, detail }.
Tier | Meaning | Examples |
T0 | Open | Adressevælgeren, Plandata, Miljøportal, DST |
T1 | Free key | Datafordeleren GraphQL, Dataforsyningen |
T2 | Agreement | EMOData energy labels |
T3 / X | Not built | Tingbog; private owner names |
See docs/credentials.md for how to get each key.
Variable | Required for |
| BFE chain, BBR, VUR, EJF, DAGI |
| Optional; defaults to |
| Energy labels |
| Optional imagery (not in core tools) |
| SQLite cache file (default |
pnpm install
pnpm test
pnpm devAfter you have a Datafordeleren key:
pnpm exec tsx scripts/introspect-datafordeler.tsMIT
Get municipality, region, parish, court and police districts for an address.
| Name | Required | Description | Default |
|---|---|---|---|
| addressId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and resource, but does not disclose any potential side effects, authentication requirements, or return format details. It is a simple getter, but the lack of any behavioral context beyond the action is a gap.
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 a single, front-loaded sentence with no wasted words. It efficiently lists the resources and the scope, making it easy to scan.
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 simple one-parameter tool, the description lists the expected output types, which provides some completeness. However, it does not mention whether all areas are always returned, or any error conditions. Given the absence of an output schema, a bit more detail on the result structure would improve completeness, but it is adequate for a basic getter.
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 schema has 0% description coverage, so the description must compensate for the undocumented parameter. It only says 'for an address' which implies addressId is an address identifier, but it does not specify its format, required type beyond a string, or any constraints. This adds minimal meaning over the schema's bare property definition.
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 the verb 'Get' and the specific resources: municipality, region, parish, court, and police districts for an address. This distinguishes it from sibling tools like get_buildings or get_parcel, which target different data types.
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?
The description implies when to use it (when you need administrative areas for an address), but it does not explicitly mention alternatives or exclusions. There is no guidance on when not to use it, though the sibling list makes the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get municipality-level population, income and dwelling statistics from Danmarks Statistik.
| Name | Required | Description | Default |
|---|---|---|---|
| addressId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It only says 'Get...', implying a read operation, but it does not disclose output format, how the address is resolved to a municipality, or any other behavioral characteristics. This is minimal transparency for a tool with no annotations.
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 a single, front-loaded sentence with no filler or redundant wording. Every part adds meaning, identifying both the data type and source.
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 tool with no output schema, no annotations, and an undocumented addressId parameter, the description is incomplete. It states what statistics are returned but not how to properly identify the municipality or what the result structure looks like, making it difficult for an agent to invoke correctly without additional context.
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 input schema provides only the type and name 'addressId' with 0% description coverage, and the description never explains what addressId means or how it relates to municipality-level statistics. The agent must guess whether the ID comes from search_address, what format is expected, and how the municipality is derived.
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 names a specific verb, resource, and granularity: 'Get municipality-level population, income and dwelling statistics from Danmarks Statistik.' This clearly distinguishes it from sibling tools that return buildings, parcels, valuations, or admin areas.
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?
The description implies when to use the tool: when municipality-level demographic, income, or dwelling statistics are needed. However, it gives no explicit guidance or exclusions relative to sibling tools like get_admin_areas or search_address, leaving the agent to infer the proper selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get BBR buildings and units for a BFE or address-id.
| Name | Required | Description | Default |
|---|---|---|---|
| bfe | No | ||
| addressId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it does signal a read operation and identify the lookup keys. However, it does not state whether BFE and address-id are mutually exclusive, what building/unit data is returned, whether pagination exists, or whether any permissions are needed.
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 one short sentence with no filler, and the verb and resource are front-loaded. It is appropriately terse for a simple lookup, although its brevity contributes to the gaps in usage and parameter guidance.
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?
Given no annotations, no output schema, and a schema with only two unconstrained strings, the description is a minimal but usable selection aid. It is not complete enough to guarantee correct invocation because the required/alternative parameter behavior and return expectations are left unspecified.
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 schema provides only bare string names with no descriptions, so the description's mention of 'BFE or address-id' is the only semantic signal. It suggests either identifier can select the data, but it does not explain the format of either parameter or what happens when both or neither are supplied.
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 uses a specific verb and resource: 'Get BBR buildings and units', and adds the key scoping identifiers BFE/address-id. It is clear about the core action, though it does not explicitly differentiate the tool from property-related siblings such as get_parcel or resolve_property.
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 like get_parcel or resolve_property, and no explicit instruction on choosing between BFE and address-id. The word 'or' implies alternatives, but no usage conditions or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the official energy label (energimærke) when EMOData credentials are configured.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| addressId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read operation but does not state authentication requirements beyond the credential hint, potential error conditions, rate limits, or the response format. Significant gaps for a tool with no structured safety annotations.
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 a single concise sentence with no filler. It front-loads the purpose immediately. However, its brevity is more under-specification than effective conciseness, though it remains efficient.
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 tool with two optional parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain what the tool returns, how the parameters relate to the energy label lookup, or what the credential configuration implies. An agent cannot reliably invoke this tool correctly.
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 input schema has no descriptions (0% coverage) and the description does not mention the parameters 'query' and 'addressId' at all. The agent receives zero guidance on how to fill these fields or what they represent, making correct invocation very difficult.
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 states a clear verb and resource: 'Get the official energy label'. It also includes the Danish term for disambiguation. However, it does not explicitly differentiate from siblings like get_buildings or get_valuation, though the unique purpose is evident.
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?
The description only mentions a prerequisite condition ('when EMOData credentials are configured') but gives no guidance on when to use this tool versus alternatives like search_address or resolve_property. It lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get soil contamination, §3 nature, conservation and coastal/forest protection overlays at the address.
| Name | Required | Description | Default |
|---|---|---|---|
| addressId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only summarizes what is retrieved and adds no context about data coverage, return format, or edge cases. 'Get' implies a read operation, but nothing beyond that is communicated.
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 a single focused sentence with no filler. It front-loads the action and enumerates the relevant overlay categories efficiently.
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 simple one-parameter lookup tool, the description identifies the key data categories, which is adequate for basic invocation. However, without an output schema or annotations, it leaves the response structure and any jurisdiction-specific behavior unexplained.
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 schema description coverage is 0%, and the description only says 'at the address,' which adds minimal meaning to the addressId parameter. It does not explain how the address should be supplied, what formats are valid, or how it maps to address resolution.
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 uses a specific verb ('Get') and names a concrete resource: soil contamination, §3 nature, conservation, and coastal/forest protection overlays. This clearly distinguishes it from related sibling tools like get_parcel or get_buildings.
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?
The description implies when to use the tool—when environment-related overlays for an address are needed—but it does not state exclusions or route to alternatives. There is enough context to make a reasonable choice, but no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cadastral parcels (matrikel) for a BFE number.
| Name | Required | Description | Default |
|---|---|---|---|
| bfe | Yes | BFE number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clearly indicates a read operation ('Get') and the object being retrieved, but it does not mention response shape, whether multiple parcels can be returned, or what happens when no parcels are found.
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 a single, front-loaded sentence with no filler. It communicates the action, resource, and required input efficiently.
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 simple one-parameter lookup, the description covers the operation and input. However, it lacks any usage context or guidance relative to sibling tools, and it does not describe the expected result shape or edge cases, leaving it minimally complete.
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 input schema already documents the single 'bfe' parameter at 100% coverage. The description only restates that the tool works 'for a BFE number', adding no format details, examples, or validation constraints beyond the schema.
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 states a specific verb ('Get'), a specific resource ('cadastral parcels (matrikel)'), and the required input ('BFE number'). This clearly distinguishes it from sibling getters like get_buildings or get_valuation.
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?
No guidance is provided on when to use this tool versus alternatives such as resolve_property or get_buildings. There are no exclusions, prerequisites, or conditions indicating the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get local plans, municipal plan frameworks and zone status from Plandata.dk at the address coordinate.
| Name | Required | Description | Default |
|---|---|---|---|
| addressId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It does convey a read-only retrieval from an external source, but it does not disclose input provenance, error behavior, or the fact that the schema expects an addressId rather than a raw coordinate.
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?
One focused sentence with no filler. Key components — action, resource, source, and query context — are front-loaded and every word earns its place.
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 simple one-parameter tool this is near-minimal, but the addressId semantics are not clarified and there is no indication of how to obtain the value (e.g., via search_address). The description tells the agent what the tool returns but not enough about how to invoke it correctly.
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?
Schema coverage is 0%, so the description needed to explain what addressId means and where it comes from. The phrase 'at the address coordinate' is ambiguous and does not clearly map to the addressId parameter, leaving the agent without enough semantic grounding.
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 identifies the action ('Get'), the specific resources ('local plans, municipal plan frameworks and zone status'), and the data source ('Plandata.dk'). It is distinct enough from siblings like get_buildings or get_parcel, though it does not explicitly contrast with them.
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?
No guidance is given on when to use this tool instead of a sibling such as search_address, resolve_property, or get_parcel. The sentence implies location-based usage but provides no explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get non-protected ownership type and recorded trade prices (EJF). Never returns private owner names.
| Name | Required | Description | Default |
|---|---|---|---|
| bfe | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral context. It discloses one meaningful behavior: private owner names are never returned, indicating a privacy/redaction guarantee. It does not state auth requirements, error behavior, or whether data is read-only, but for a getter this is a useful disclosure.
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?
Two short sentences; the primary action is first and the caveat second. No filler.
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 one-parameter tool with no output schema, the description is incomplete: it fails to define bfe or describe the response shape, and 'EJF' is left unexplained. The privacy note is helpful but does not overcome the missing invocation semantics.
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?
Schema description coverage is 0% and the description never explains the required bfe parameter. An agent is left to guess what bfe means and how to format it. This is a critical gap for a single-parameter tool.
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?
States a specific operation ('Get') on a specific resource: non-protected ownership type and recorded trade prices (EJF). The caveat 'Never returns private owner names' sharpens the scope. However, it does not compare against siblings like get_valuation or get_parcel, so differentiation relies on domain-specific terms.
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 'use when' or 'use instead' guidance, and none of the 13 siblings are mentioned. The privacy caveat hints at a limitation but not at selection criteria versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get official property and land valuation (VUR) for a BFE, including history.
| Name | Required | Description | Default |
|---|---|---|---|
| bfe | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does convey that the operation returns official valuation data and includes history, which is useful. However, it does not disclose potential errors, authentication requirements, rate limits, or pagination, so behavioral transparency is only moderately addressed.
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 a single, front-loaded sentence with no wasted words. Every part adds meaning: the action, the resource type, the 'official' nature, the BFE scope, and the history inclusion.
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?
The tool has no annotations, no output schema, and zero parameter documentation, so the description needs to carry substantial context. It provides a clear high-level purpose but omits what BFE means, how to format it, what the response structure looks like, and any operational constraints. This is not complete enough for an agent to reliably call the tool without further inference.
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?
Schema description coverage is 0%, so the description must compensate. It mentions 'for a BFE,' which indicates that the 'bfe' parameter is a property identifier, but it never defines what a BFE is or what format is expected. This is minimal semantic help and does not fully compensate for the undocumented parameter.
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 the exact action ('Get') and resource ('official property and land valuation (VUR) for a BFE'), with a useful additional note about history. It is specific and informative, but it does not explicitly distinguish this tool from siblings like get_parcel or get_trades, so it falls short of a 5.
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 instead of alternatives. The description does not mention exclusions, preferred contexts, or relationships to sibling tools like get_trades or property_report, leaving the agent to infer when get_valuation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List official Danish property data sources, their access tier, and whether credentials are configured.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral transparency burden. It discloses the output content but nothing about side effects, authentication needs, rate limits, or the meaning of 'access tier'. This is acceptable for a parameterless read-only list, but it adds minimal behavioral context beyond the basic action.
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?
A single sentence front-loads the action and resource, then concisely adds the two output dimensions. No filler or redundant wording; every element earns its place.
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 zero-parameter tool with no output schema, the description is complete. It tells the agent exactly what will be returned: a list of official sources, access tiers, and credential configuration status. Nothing needed to invoke the tool correctly is missing.
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 tool has zero parameters, so the schema is fully covered by definition. The description adds worthwhile context about what the result contains, exceeding the baseline expected for a parameterless tool.
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 uses the specific verb 'List', names the resource ('official Danish property data sources'), and specifies output details ('access tier', 'whether credentials are configured'). This clearly distinguishes it from sibling tools that retrieve property data, such as get_buildings or get_trades.
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?
The description makes the tool's purpose and context unmistakable, but it does not explicitly state when to choose this over siblings or how to act on the credential status. The unique subject matter makes the usage situation clear enough without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a compact combined report for a Danish address. Calls all sources in parallel and marks missing ones.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| addressId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior, and it does: it calls all sources in parallel and marks missing ones. This gives the agent insight into potential performance and handling of incomplete data, which is useful beyond what the schema shows.
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 concise and front-loads the main purpose. It includes extra behavioral details efficiently. It could be slightly more structured (e.g., separating usage from behavior), but it is compact and 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?
Given the tool aggregates many sources, the description is fairly complete for basic understanding. It lacks details on parameter formats, examples, or how results are structured, but since there is no output schema, some return format context might be needed. The parallel call behavior is a plus.
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?
Schema description coverage is 0%, so the description must compensate, but it only mentions 'a Danish address' and offers no specifics about how 'query' or 'addressId' are used. It does not clarify whether both are required, alternative, or how they relate, leaving ambiguity for parameter selection.
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 it builds a compact combined report for a Danish address, which is specific and distinct from siblings that fetch individual data types. It also mentions that it calls all sources in parallel and marks missing ones, adding valuable detail that sets it apart.
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?
The description implies the tool is used when a combined report is needed, contrasting with siblings that may be used for specific data types. However, it does not explicitly state when not to use it or name alternatives, but the context from the sibling list makes the purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a Danish address to DAR IDs, coordinates, cadastral IDs and BFE. Requires Datafordeleren for BFE.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Free-text address if addressId is unknown | |
| addressId | No | DAR address UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a dependency on Datafordeleren for BFE, which is useful, but it doesn't mention that this is a read-only operation, potential rate limits, error behavior, or that it may require external credentials. The disclosure is minimal.
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 a single, efficient sentence that front-loads the core purpose and includes the key dependency. It is concise without wasted words, though it lacks any structured breakdown of inputs/outputs.
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?
Given there is no output schema, the description lists the types of data returned (DAR IDs, coordinates, etc.), which is helpful. However, it omits behavior on failure, how query and addressId interact, and whether both can be provided. For a resolve tool with 2 optional parameters, it is adequate but not thorough.
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?
Schema description coverage is 100% and both parameters are described ('Free-text address if addressId is unknown' and 'DAR address UUID'). The description adds no additional parameter meaning, such as how the two parameters interact or whether they are mutually exclusive. Baseline 3 is appropriate since the schema carries the detail.
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 states a clear verb ('resolve') and resource ('Danish address') with specific outputs (DAR IDs, coordinates, cadastral IDs, BFE). It is distinct from siblings like search_address which likely just finds an address, but it doesn't explicitly name the sibling it differentiates from.
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?
No guidance is given on when to use this tool versus search_address, property_report, or get_parcel. The only mention is a prerequisite ('Requires Datafordeleren for BFE'), not a usage condition or exclusion. An agent would have to infer intent from the outputs listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Danish addresses by free text using Adressevælgeren (DAWA replacement). Use before any property lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Free-text Danish address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It only states the service (Adressevælgeren/DAWA replacement) and the search action; it does not say whether the operation is read-only, how many results are returned, how errors are handled, or whether any state changes occur.
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?
Two short sentences, with the core action first and the usage context second. No filler or redundancy; every phrase earns its place.
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 simple 2-parameter search tool, the description plus schema provide the basic invocation path (query required, limit optional with min/max). However, with no annotations and no output schema, the absence of any return-format or behavioral note leaves some ambiguity about what the tool actually produces and whether it is safe/read-only.
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?
Schema coverage is 50%: only 'query' has a description, and it already says 'Free-text Danish address.' The description's 'free text' phrasing restates that schema info and adds nothing about the 'limit' parameter, which remains unexplained in both schema and description.
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?
Description states a specific action (search) on a specific resource (Danish addresses) with a clear method (free text). It also places the tool in the workflow ('Use before any property lookup'), which distinguishes it from downstream lookup tools among the siblings, though it doesn't explicitly contrast with a named sibling like resolve_property.
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?
The phrase 'Use before any property lookup' gives a clear when-to-use rule and establishes this as a prerequisite for downstream tools. It doesn't mention when not to use it or name alternative tools (e.g., resolve_property), so it falls short of explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_admin_areasget_area_statsget_buildingsget_energy_labelget_environmentget_parcelget_plansget_tradesget_valuationlist_sourcesproperty_reportresolve_propertysearch_addressScored across 13 tools
Each tool targets a distinct data source or action: search_address finds addresses, resolve_property converts them to IDs, and get_* tools each pull a specific type of property data (buildings, parcels, valuation, trades, etc.). property_report aggregates them without overlapping. No two tools have ambiguous boundaries.
All tool names follow a consistent verb_noun pattern using snake_case, e.g., list_sources, search_address, get_buildings, property_report. The verbs vary appropriately (list, search, resolve, get, build) but the structure is uniform and highly predictable.
With 13 tools, the set is well-scoped for a Danish property data server. Each tool covers a distinct aspect of property information, from address lookup to energy labels and area statistics, without unnecessary redundancy or overwhelming breadth.
The tool surface covers the complete lifecycle of property data queries: address search, ID resolution, buildings, parcels, valuation, trades, administrative areas, plans, environment, energy, and statistics. The property_report tool even aggregates all sources, ensuring no dead ends or missing operations for the stated purpose.
Danish address & property lookup: BBR, Matriklen, DAR, CVR. A DAWA/Datafordeler-compatible source.
Property Records MCP — address-level US property records (sales history,
Données immobilières officielles françaises (DVF+, cadastre, DPE, risques, urbanisme) via MCP.
Nordic company intelligence: look up companies, AI summaries, scores and signals via MCP.
