BOE, Spanish public tenders and INE statistics behind one MCP server.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 5 tools
Each tool targets a distinct data source or action: BOE by date, BOE full-text search, INE series, tender search, and server info. No meaningful overlap.
Names mostly follow a clear domain_prefix pattern (boe_day, boe_search, ine_series, tenders_search), with 'info' as a minor exception. Overall consistent and predictable.
Five tools is well-scoped for a focused Spanish open-data server, covering BOE, INE, and tenders without unnecessary bloat.
The core advertised domains (BOE, INE, tenders) are covered with search/retrieval operations. A general dataset catalog or additional data sources could round it out, but the main use cases are addressed.
Every BOE item published on ymd (YYYYMMDD).
| Name | Required | Description | Default |
|---|---|---|---|
| ymd | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits such as pagination, rate limits, or side effects. The limit parameter is not explained, and no annotations are present to cover safety or side-effect information.
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, tight sentence that directly conveys the core function. It is free of unnecessary words or 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?
The description is adequate for a simple daily-retrieval tool, but it omits details like pagination behavior, the meaning of the limit parameter, and any ordering or format of results. This leaves some gaps for an agent trying to use it 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 description adds format details for the 'ymd' parameter (YYYYMMDD), but it does not describe the 'limit' parameter, which is present in the schema. With two parameters and only one explained, the coverage is partial and the missing limit semantics create ambiguity.
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 indicates this tool retrieves all BOE items for a given date ('Every BOE item published on ymd'), which is a specific resource and action. It is distinct from sibling tools like boe_search, though it lacks an explicit verb such as 'returns' or 'lists'.
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 explicit guidance is provided on when to use this tool versus alternatives. It is implied that this is for daily retrieval, but there is no instruction to prefer it over boe_search for filtered queries or to use it for snapshots.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search over BOE item titles and text.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The term 'search' implies a read-only operation, but the description does not explicitly state that it has no side effects or that it returns a list of results. With no annotations to clarify, the description partially carries the burden but could be more explicit.
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 superfluous words. It is well-structured and easy to parse.
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?
While the tool is simple, the description omits essential details about parameters and result behavior. Without an output schema, an agent would need to infer how to construct a valid query and interpret the response. The lack of parameter explanations makes it incomplete for reliable invocation.
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 two parameters (query, limit) with zero description coverage. The description does not explain what 'query' means (e.g., search terms, filters) or how 'limit' behaves (e.g., maximum results). It fails to compensate for the lack of schema documentation.
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 verb ('search') and a clear resource ('BOE item titles and text'), which distinguishes it from sibling tools like boe_day and tenders_search.
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?
Provides no guidance on when to use this tool versus alternatives (e.g., boe_day for daily records, tenders_search for tenders). The description only states what it does, not when it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest values of one INE series by code (see series.txt).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full responsibility for disclosing behavior. It does not mention read-only nature, error handling, rate limits, or what happens for invalid codes. The only extra hint is 'see series.txt' for valid codes, but this is not elaborated.
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 immediately states the purpose and references the series list, making it efficient for quick scanning.
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 read tool, the description is minimally adequate. It tells the agent the purpose and points to a code list, but it does not describe the return format, whether multiple values are returned, or error behavior. Given no output schema, these gaps remain unresolved.
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 explains that the parameter 'code' identifies an INE series and points to series.txt for valid values. This adds meaning beyond the schema's bare type declaration, though it does not specify format or value constraints in 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, specific action: retrieving the latest values of one INE series by code. It names the resource (INE series) and the key parameter (code). It distinguishes from siblings because they cover BOE and tenders, so there is no ambiguity about which tool to use for INE data.
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 no explicit guidance on when to use this tool versus alternatives. While the siblings are clearly different domains (BOE, tenders), it does not state conditions or exclusions. It only implies usage for INE series data, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Contact and scope of this server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations or additional description, the tool's behavior is not transparent. It is unclear whether it performs a read-only operation, has side effects, or requires any authentication. The description does not disclose any potential impacts or constraints.
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 short and to the point, which is efficient. However, the phrasing is terse and could benefit from a bit more detail to clarify its purpose, slightly reducing the score from a perfect 5.
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?
There is no output schema, and the description does not state what the tool returns (e.g., a JSON object with contact info and scope definitions). Without this, an agent cannot fully anticipate the response format or content, making the description incomplete.
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 no parameters, so the schema fully covers the input space. The description does not need to elaborate on parameters since there are none, earning a baseline score of 4.
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 'Contact and scope of this server' indicates the tool provides server information but lacks a clear verb or explicit statement of what is returned. It is somewhat vague and does not differentiate well from potential sibling tools without further context.
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 the sibling tools (e.g., boe_day, tenders_search). The description does not mention any conditions or contexts where calling 'info' would be appropriate or preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search public tenders by text, CPV prefix, budget range, deadline.
| Name | Required | Description | Default |
|---|---|---|---|
| cpv | No | ||
| limit | No | ||
| query | No | ||
| max_budget | No | ||
| min_budget | No | ||
| deadline_after | 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. It does not disclose whether the operation is read-only, any side effects, or rate limits. Only implies a non-mutating search.
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, tightly worded sentence conveys the tool's purpose and key parameters without any filler or 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?
Given the absence of an output schema, the description does not mention result format, pagination, or sorting. For a search tool, this leaves some ambiguity, but the essential entry-point information is present.
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, but the description maps most parameters to search criteria (text→query, CPV→cpv, budget range→min/max_budget, deadline→deadline_after). It omits 'limit' and does not explain value formats (e.g., date format, budget units).
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 verb ('search'), specific resource ('public tenders'), and lists the four main filtering criteria. Clearly distinguishes from sibling tools that target different datasets (BOE, INE).
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?
Lists the available search dimensions but does not explicitly state when to prefer this tool over siblings. However, the domain difference is obvious, so some implicit guidance exists.
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.
boe_dayboe_searchine_seriesinfotenders_searchMCP server for French (BOAMP) + EU (TED) public procurement data via TenderAPI.
28 MCP servers behind one endpoint: earth, sky, policy, records and research
TED MCP Server: Real-time EU public tenders access. https://www.lexsocket.ai/
Add one secure layer between your agents and this server.
