Click on "Install 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., "@DataPrem MCP Server Look up the cadastral data for Calle Gran Vía 28, Madrid"
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.
A Model Context Protocol (MCP) server that exposes Spanish public-data sources to AI agents (Claude Desktop, Cursor, ChatGPT, …).
It is a thin client of the DataPrem REST API: each MCP tool maps to an HTTPS call against api.dataprem.com using your API key.
Requires the MCP Python SDK 2.x (mcp>=2.0.0,<3).
Tool | Status | Source |
| Live | Sede Electrónica del Catastro |
| Live | Boletín Oficial del Registro Mercantil |
| Live | Plataforma de Contratación del Sector Público |
| Live | Base de Datos Nacional de Subvenciones |
Every tool answers with real data. The subsidies one carries its attribution in meta.source: its terms of reuse ask for the origin to be named wherever the data is shown.
Related MCP server: eRegulations MCP Server
Every tool requires a Bearer token from api.dataprem.com:
Request access by email to info@dataprem.com, describing your use case.
You will receive a token prefixed dpa_… along with the API URL.
Configure it in your MCP client (next section).
Requires Python 3.11+.
# Via PyPI (recommended for MCP clients)
uvx dataprem-mcp
# Or local install for development
pip install -e ".[dev]"Edit claude_desktop_config.json (Mac: ~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"dataprem": {
"command": "uvx",
"args": ["dataprem-mcp"],
"env": {
"DATAPREM_API_KEY": "dpa_YOUR_TOKEN_HERE",
"DATAPREM_API_URL": "https://api.dataprem.com"
}
}
}
}Restart Claude Desktop. The four tools should show up as available to the model.
For clients that cannot spawn the server as a subprocess (e.g. a multi-request web app) there is a streamable-http transport that runs the server as a long-lived process listening for JSON-RPC over HTTP.
# Without Docker
python -m dataprem_mcp --transport streamable-http --host 0.0.0.0 --port 8080
# With Docker
docker compose up dataprem_mcp # local image build; exposed only on the internal networkThe MCP endpoint is /mcp (no trailing slash). The standard handshake (initialize → tools/list → tools/call) works with Content-Type: application/json and Accept: application/json, text/event-stream. Each conversation receives an mcp-session-id that the client must echo back on subsequent requests.
# Example: initialize handshake
curl -sL -X POST http://127.0.0.1:8080/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-03-26",
"clientInfo": {"name": "smoke", "version": "1"},
"capabilities": {}
}
}' -iBy default the compose service does not publish the port to the host: place it on a Docker network shared with your client and reach it as http://dataprem_mcp:8080/mcp.
{
"mcpServers": {
"dataprem-dev": {
"command": "python",
"args": ["-m", "dataprem_mcp"],
"cwd": "/path/to/dataprem-mcp",
"env": {
"DATAPREM_API_KEY": "dpa_dev_token",
"DATAPREM_API_URL": "http://localhost:8000"
}
}
}
}Variable | Default | Description |
| (empty) | Bearer token ( |
|
| API base URL. Override to point at a development environment. |
dataprem_catastro_lookup ✅ LiveLooks up cadastral data for a property. Two modes are supported:
By cadastral reference:
Parameter | Type | Description |
| string | Cadastral reference (14, 18 or 20 characters) |
By address:
Parameter | Type | Required | Description |
| string | yes | Literal address (street type + name + number) |
| string | yes | Municipality |
| string | no | Province |
Returns the normalised cadastral record (class, use, surfaces, year of construction, address with INE codes, breakdown of constructions by floor and use). Does not expose the owner for LOPD/GDPR reasons.
dataprem_borme_searchParameter | Type | Required |
| string | yes |
| string YYYY-MM-DD | no |
| string YYYY-MM-DD | no |
| string | no |
| integer (default 25, max 100) | no |
dataprem_subsidies_searchEvery parameter is optional on its own, but at least one is required.
Parameter | Type | Required |
| string | no |
| string (name or NIF) | no |
| string | no |
| ESTADO / AUTONOMICA / LOCAL / OTRA | no |
| string | no |
| string | no |
| string YYYY-MM-DD | no |
| string YYYY-MM-DD | no |
| integer (default 25, max 100) | no |
dataprem_tenders_searchEvery parameter is optional on its own, but at least one is required: searching for everything is not a search.
Parameter | Type | Required |
| string, words from the object of the contract | no |
| string, public body that put the contract out | no |
| string, awarded company by name or NIF | no |
| string, 2 to 10 digits, comma separated | no |
| string, city or NUTS code ( | no |
|
| no |
| string, euros without tax | no |
| string, euros without tax | no |
| string YYYY-MM-DD | no |
| string YYYY-MM-DD | no |
| integer, 25 by default, capped at 100 | no |
buyer is who put the contract out; company is who won it — the one no other source answers: what a given firm has been awarded. cpv widens or narrows by how much of the code you give — 45 is every construction contract, 45210000 one kind of building.
Every tool returns a dict marking success or failure with ok:
{ "ok": true, "data": { ... cadastral record ... } }
{ "ok": false, "error": "unauthorized", "message": "API key invalid or revoked..." }A search also carries meta, which says what the results alone do not: that there are more of them, and which years hold them, so narrowing is not guesswork.
{ "ok": true,
"meta": { "count": 25, "has_more": true, "years": [2024, 2025, 2026] },
"data": [ ... ] }A value the API refuses comes back with the ones it accepts, rather than as a bare failure:
{ "ok": false, "error": "invalid_request", "message": "Unknown tender status \"ABIERTA\".",
"statuses": ["PRE", "PUB", "EV", "ADJ", "RES", "ANUL"] }A search with nothing to narrow by is refused, and the answer says what it takes:
{ "ok": false, "error": "invalid_request",
"message": "A subsidy search needs something to narrow by: text, a beneficiary, a granting body, a level, an amount or a date.",
"levels": ["ESTADO", "AUTONOMICA", "LOCAL", "OTRA"] }Error codes:
| Meaning |
|
|
| Required parameters are missing |
| Token revoked or expired |
| The upstream returned no match |
| The source rejected the input (malformed RC, unknown street, …) |
| Monthly quota exhausted |
| The source is in the catalogue but its connector has not shipped |
| The source or DataPrem temporarily unavailable |
|
|
# Install dev dependencies
pip install -e ".[dev]"
# Run tests
pytest
# Start the installed console script over stdio and list its tools,
# the same way a desktop client does. The suite alone cannot catch a
# package that imports fine from the source tree but not once installed.
python scripts/smoke_stdio.py
# Run the server with a local API key
DATAPREM_API_KEY=dpa_xxx DATAPREM_API_URL=http://localhost python -m dataprem_mcpPublishing runs from CI through PyPI trusted publishing, so no token lives on anyone's machine:
# bump the version in pyproject.toml and add the CHANGELOG entry, then
git tag 0.3.4
git push origin 0.3.4The release workflow builds, checks the artifact, installs the wheel, starts it over stdio, refuses to continue if the tag disagrees with the built version, and only then publishes.
MIT
Busca actos registrales en el BORME (Boletín Oficial del Registro Mercantil).
Permite localizar inscripciones de constitución, nombramientos, ceses, ampliaciones de capital y otros actos mercantiles de una empresa.
Args: company_name: Nombre o razón social de la empresa a buscar. date_from: Fecha de inicio de búsqueda (formato YYYY-MM-DD, opcional). date_to: Fecha de fin de búsqueda (formato YYYY-MM-DD, opcional).
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | No | ||
| date_from | No | ||
| company_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It implies a read-only search operation via verbs like 'busca' and 'localizar', but it does not disclose output format, pagination, error behavior, or any side effects. The description adds some context (act types, date range) but lacks richer behavioral traits.
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 well-structured: a clear opening sentence stating the purpose, followed by a compact, tagged parameter list. Every sentence contributes value, and there is no redundancy or extraneous detail.
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 a simple 3-parameter schema and an output schema is present, so the description need not explain return values. However, it leaves minor gaps, such as whether company_name searching is exact or partial and whether date ranges are inclusive. Overall, it is largely complete for a basic search tool.
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 compensates for the 0% schema coverage by providing an Args section that explains each parameter: company_name (nombre o razón social), date_from (formato YYYY-MM-DD, opcional), and date_to (formato YYYY-MM-DD, opcional). This fully documents all three parameters, adding meaning beyond the bare 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 clearly states the tool's function: 'Busca actos registrales en el BORME' (searches registry acts in the BORME), and it lists specific act types (constitución, nombramientos, ceses, ampliaciones de capital). This specific verb+resource pair distinguishes it from sibling tools like catastro, cendoj, and tenders, which target different data sources.
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 provides clear context: it is used to find commercial registry acts for a company, with optional date range filtering. It does not explicitly mention exclusions or alternatives, but the distinct domain (BORME) compared to siblings (catastro, cendoj, tenders) makes the usage context clear, though not explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta datos catastrales de un inmueble en el Catastro español.
Provee uno de los dos modos de búsqueda:
Por referencia catastral — pasar refcat (14, 18 o 20 caracteres).
Por dirección — pasar address + city, opcionalmente province.
Devuelve la ficha catastral normalizada: clase, uso, superficies, año de
construcción, dirección con códigos INE, y el desglose de construcciones
(constructions[]) con planta, puerta y superficie por componente.
El endpoint no expone titular (datos personales): el SOAP libre del Catastro no lo facilita y la API pública lo descarta por LOPD/GDPR. Consulta autorizada con certificado del titular en pipeline futuro.
Args: refcat: Referencia catastral del inmueble. address: Dirección literal (tipo + nombre + número). city: Municipio. province: Provincia (opcional).
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| refcat | No | ||
| address | No | ||
| province | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses a key behavioral limitation: the endpoint does not expose 'titular' because of the free SOAP and public API LOPD/GDPR constraints, and mentions a future authorized pipeline. It also summarizes the normalized record and return breakdown, giving the agent a good behavioral model. Minor gaps: no error behavior or required-coupling enforcement, but the search-mode rules are stated.
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 well-structured with a clear lead sentence, bullet-style mode summaries, a brief output summary, and an Args list. A bit lengthy due to the GDPR/future-pipeline note, but that content provides meaningful behavioral context and 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 lookup with an output schema present, the description covers the two valid input modes, the expected response shape (class, use, surfaces, construction year, INE codes, constructions[]), and a privacy limitation. It doesn't specify what happens on invalid/no-match input, but the overall context is sufficient for a competent agent to select and invoke the 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?
Schema has 0% description coverage and all four params are nullable with no descriptions, so the description must add meaning. It does: refcat length (14/18/20), address format ('tipo + nombre + número'), city as municipality, province as optional, and the mode-based coupling (address+city). This substantially compensates for schema 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?
Description opens with 'Consulta datos catastrales de un inmueble en el Catastro español', naming exact verb, resource, and domain. It distinguishes this from sibling tools (BORME, CENDOJ, tenders) by focusing on the Spanish cadastre, and clarifies the two lookup modes.
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?
It explicitly defines two mutually exclusive search modes ('Por referencia catastral' vs 'Por dirección') and states which parameters to pass, with province optional. It also warns that owner/titular data is not exposed, which is a clear when-not-to-use indicator. However, it doesn't explicitly contrast with sibling tools, though they are clearly different domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca resoluciones judiciales en el CENDOJ (Centro de Documentación Judicial).
Permite buscar sentencias, autos y providencias de todos los órdenes jurisdiccionales españoles.
Args: query: Términos de búsqueda (texto libre sobre la materia de la resolución). court: Órgano judicial (ej. "Tribunal Supremo", "Audiencia Provincial de Madrid"). Opcional. date_from: Fecha mínima de la resolución (formato YYYY-MM-DD, opcional).
| Name | Required | Description | Default |
|---|---|---|---|
| court | No | ||
| query | Yes | ||
| date_from | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the search scope and provides parameter nuance, but it does not disclose any limitations, side effects, authentication needs, or pagination behavior. As a search tool, read-only is implied but not stated.
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 front-loaded with the main purpose and efficiently uses an Args block to document parameters. It is not overly verbose, though the Args section could be slightly more compact. Every sentence 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 search tool with an output schema and all parameters described, the description is adequately complete. It covers the what, scope, and parameter formats. Minor missing details like date inclusivity or result limits are not critical.
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%, but the description's 'Args' section fully defines each parameter: query (free text), court (examples given), and date_from (format specified). This adds significant meaning beyond the bare schema, providing examples and clarifying optionality.
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 tool searches judicial resolutions in CENDOJ, listing specific document types (sentencias, autos, providencias) and the scope (all Spanish jurisdictional orders). This distinguishes it from sibling tools like Catastro lookup or Borme search, which target different data domains.
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 usage by describing the resource and supported courts, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. Sibling tools are clearly different, so the context is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca licitaciones y contratos públicos en España.
Consulta la Plataforma de Contratación del Sector Público para encontrar licitaciones abiertas, adjudicadas o cerradas.
Args: query: Términos de búsqueda sobre el objeto del contrato. location: Comunidad autónoma o provincia (opcional). status: Estado de la licitación: "open" (abierta), "closed" (cerrada) o "all" (todas). Por defecto "all".
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| status | No | ||
| location | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It does not mention return format, pagination, limitations, or any side effects. It only describes the action and parameters, leaving the agent to infer expectations.
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 short, front-loaded with the main verb, and clearly separated into purpose and parameter sections. Every sentence adds value without redundancy.
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 3-parameter search tool with an output schema, the description covers purpose, source, and parameter semantics adequately. It lacks explicit behavioral constraints, but the output schema reduces the need for return value details.
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 has no parameter descriptions, but the description compensates by explaining each parameter: query, location, and status with its valid values and default. This provides meaningful guidance beyond the raw 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 action ('Busca licitaciones y contratos públicos') and a clear resource ('Plataforma de Contratación del Sector Público'), making its purpose unmistakable. It is clearly distinct from sibling tools covering cadastre, business registry, and judicial documents.
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 usage through its domain focus (tender search), but does not explicitly state when to use it over alternatives or when not to use it. There is no mention of alternative tools or exclusion cases.
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. Dates show when Glama detected each change.
v0.4.0dataprem_borme_searchdataprem_catastro_lookupdataprem_cendoj_searchdataprem_tenders_searchEach tool queries a distinct official Spanish database—cadastre, business registry, judicial decisions, and public tenders—so there is zero overlap in purpose. An agent can easily select the correct tool based on the desired data source.
All tools share the 'dataprem_' prefix and use a consistent snake_case pattern with domain-specific terms. The only minor inconsistency is mixing 'lookup' (catastro) with 'search' (the other three), though both imply similar retrieval actions.
Four tools is a well-scoped count for a server dedicated to Spanish public data access. Each tool covers a distinct domain, and the number is neither too thin nor overwhelming.
The set covers major Spanish public registries relevant to business, legal, and property queries. However, it lacks access to other common official sources like the BOE (official gazette) or trademark registry, leaving minor gaps in the surface.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
CompanyLens is a remote MCP server giving AI agents instant access to official company registry data across 19 jurisdictions in Europe, the Americas, and Asia-Pacific. Eighteen read-only tools let you search companies and people, look up officers and beneficial owners, map corporate networks through shared directors, screen names against the UK disqualified directors register, find every company at a registered address, and pull filing history — all from a single connector. Visit our website: https://companylens.io
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Hosted MCP server for live public-data APIs and Skills for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tekniadev/dataprem-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
