Catalunya Open Data MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.4
Disambiguation5/5
Each tool has a clear, distinct purpose within its data source group (BCN, IDESCAT, Socrata). Tools like bcn_plan_query, bcn_execute_city_query, and bcn_answer_city_query are complementary, not overlapping. Cross-group tools are clearly differentiated by prefix.
Naming Consistency5/5
Tool names follow a consistent pattern: {source_prefix}_{verb}_{noun}. For example, bcn_search_packages, idescat_get_table_metadata, socrata_describe_dataset. Naming conventions are uniform and predictable, aiding agent selection.
Tool Count4/5
22 tools is relatively high but justified by covering three distinct data platforms (BCN, IDESCAT, Socrata) with full discovery and query workflows. Each tool serves a specific step, and the count aligns with the server's broad scope.
Completeness5/5
For each data source, the tools cover the full lifecycle: discovery (search, list, recommend), metadata inspection, query execution, and specific operations like geospatial queries and place resolution. No obvious gaps in functionality.
Average 3.7/5 across 22 of 22 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It states 'safe bounded' but does not explain what that means in practice, nor does it disclose side effects, auth requirements, rate limits, or any behavioral traits. The output fields listed are not behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loaded with the main action, but it is dense and lists many output fields. Some cutting could improve readability without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, nested objects, no annotations), the description is incomplete. It lacks parameter guidance, usage context, and behavioral details. The presence of an output schema does not compensate for the lack of input parameter explanations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 8% (only 'limit' has a description). The tool description does not explain any parameters, leaving 12 parameters largely undocumented. The description adds no meaning beyond the schema's minimal info.
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?
The description clearly states the tool executes a city-question plan and composes an answer, listing many return fields. It identifies the specific resource and action, but does not differentiate from sibling tools like 'bcn_execute_city_query' or 'bcn_plan_query', missing an opportunity to clarify its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any conditions or prerequisites. The description does not mention when not to use it or what distinguishes it from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only offers a high-level purpose and examples, with no information on authentication, rate limits, pagination, result format, or any side effects. This is insufficient for an AI agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence). While brevity is valued, it sacrifices necessary detail. It could be restructured to include parameter hints or usage context without significant lengthening.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context indicates it exists), the description does not need to detail return values. However, the description is too sparse: it lacks parameter semantics, usage guidance, and behavioral context. The tool has several parameters and many siblings, so completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema itself provides no parameter descriptions. The description adds no information about the three parameters (query, limit, offset). It does not explain that 'query' is a search string or that 'limit' and 'offset' paginate results. This is a critical gap.
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?
The description clearly identifies the tool's purpose: to discover or search for CKAN packages on Open Data BCN related to Barcelona city datasets. It provides examples of dataset types, which helps distinguish it from sibling tools like bcn_get_package (which retrieves a specific package). However, it could be more explicit about the search action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling tools for querying, previewing, and searching, the description should indicate that this is the primary search tool for discovering packages, while others are for specific operations. Missing context on when to use search vs other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It claims the tool is 'safe bounded' and 'blocks instead of guessing,' but fails to explain side effects, authorization needs, rate limits, or error handling. The behavior remains opaque.
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?
The description is extremely concise (two sentences) and front-loads the main action. Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high complexity (13 parameters, nested objects, output schema), the description is severely incomplete. It does not explain what a 'city-question plan' is, how to construct one, or how parameters relate. The output schema exists but goes unmentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 8%, yet the description adds no parameter details. It does not explain what parameters like place_kind, resource_id, or group_by represent, leaving the agent to guess despite the complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it executes a 'city-question plan' and mentions safe/bounded behavior, but does not clearly differentiate from siblings like bcn_plan_query or bcn_answer_city_query. The term 'blocks instead of guessing' is vague and doesn't clarify the tool's specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings. The phrase 'blocks instead of guessing' implies a behavior but offers no decision-making criteria or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must cover behavioral traits. It does not mention side effects, authentication, rate limits, or error handling. Only states what is included in the response.
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?
Single sentence, 20 words, front-loaded with action and scope, zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need no explanation. However, given no annotations and no description for the sole parameter, completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet description adds no meaning to the only parameter (package_id). No format, example, or purpose beyond schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies verb 'fetch', resource 'Open Data BCN package', and lists included details (resource IDs, formats, etc.), distinguishing it from siblings like bcn_search_packages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites or exclusions. Implies use for single package fetch but does not clarify when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether the tool is read-only, requires authentication, has rate limits, or pagination behavior. The only hint is 'list' implying read, but that is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded with purpose. However, it sacrifices critical details for brevity, making it less useful than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of parameter descriptions in schema and no annotations, the description should compensate. It fails to explain required inputs or output structure (though output schema exists). The tool has 6 parameters, 3 required, yet the description ignores them entirely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema), and the description adds no meaning to any of the 6 parameters (statistics_id, node_id, table_id, lang, limit, offset). Agent has no clue what each parameter represents or how to use them.
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?
The description states it's a 'bridge from table discovery to metadata/data' and instructs to 'choose a returned geo_id', clearly indicating the tool lists geographic variants for a table. It distinguishes its role from sibling data/metadata tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly prescribes the workflow order: use this tool, then call idescat_get_table_metadata before idescat_get_table_data. However, it does not mention when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It does not mention pagination (though limit/offset parameters exist), error conditions, rate limits, or authentication requirements. The description only indicates a read-like operation but lacks sufficient behavioral detail.
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?
The description is extremely concise: two sentences with no redundant information. The first sentence states the purpose, and the second provides critical usage context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema is present, the description fails to cover key aspects like pagination behavior (despite limit/offset parameters) and error handling. Given the absence of annotations and parameter descriptions, the description is not complete enough for an agent to use the tool effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% schema description coverage, but the tool description adds no information about the parameters. It mentions statistics_id and node_id only in the context of output, leaving all parameter semantics unaddressed. This severely hinders correct tool invocation.
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?
The description clearly states the action ('browse tables') and the context ('within an IDESCAT statistic node'), distinguishing it from sibling tools like idescat_list_nodes and idescat_list_statistics. However, 'browse' is somewhat vague; explicitly stating 'list tables' would improve clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by directing the agent to use the returned IDs with idescat_list_table_geos before metadata or data calls, establishing a clear sequence for tool use. It does not, however, specify when not to use this tool or compare it with alternatives like idescat_get_table_metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions discovery of metadata but does not disclose behavioral traits like read-only nature, pagination behavior, or what happens with empty results. The existence of offset/limit parameters is not highlighted.
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?
The description is a single, front-loaded sentence that conveys the core purpose efficiently with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description is minimally adequate but lacks details on return format, pagination, and expected behavior. For a search tool with 3 parameters and pagination support, more context would improve completeness.
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 coverage is 100%, so the description adds limited value beyond the schema. It provides context about the catalog source but does not elaborate on parameter usage or format beyond the schema definitions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Discover' and the resource 'dataset IDs and metadata' from a specific catalog (Catalunya open data Socrata). It distinguishes this search tool from siblings like 'socrata_describe_dataset' and 'socrata_query_dataset' by focusing on discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., when to search vs describe vs query). Context signals show sibling tools, but the description does not provide exclusion criteria or comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as side effects, rate limits, or auth requirements. It only states the purpose, failing to add transparency beyond that.
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?
Two sentences, front-loaded with key purpose and usage, no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks parameter explanations and does not cover the full context needed to use the tool independently. It only covers the high-level workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the three parameters (lang, limit, offset). Agent gets no guidance on their meaning or effect beyond the schema's type/enum definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Browse fallback when idescat_search_tables is too broad or empty', specifying the action (browse) and resource (statistics), and distinguishes from sibling tools by positioning it as a fallback and part of a workflow with idescat_list_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use ('when idescat_search_tables is too broad or empty'), and what to do after ('call idescat_list_nodes with a returned statistics_id'), providing a clear usage flow and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly states the tool returns a plan without side effects, listing key output components. It lacks details on authorization or rate limits, which is acceptable for a planning tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise and front-loads the purpose. While it could be more structured with bullet points, it avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions key outputs and has an output schema, but given the complexity (13 parameters, nested objects), it omits details about the output structure and parameter use, leaving the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 8%, and the description does not explain any of the 13 parameters beyond implying 'query' is the natural-language input. This is a significant gap given the number of parameters.
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?
The description clearly states the tool's function: planning a natural-language Barcelona city question into an explainable workflow, with a list of return items. It distinguishes from sibling tools like bcn_execute_city_query by noting it does not run the final query, but lacks explicit differentiation from bcn_recommend_resources or bcn_resolve_place.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes the tool is for planning and 'without running the final data query,' guiding when to use it versus execution tools. However, it does not provide exclusions or mention alternatives like bcn_query_resource for direct queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'browse,' implying a read-only operation, but does not specify whether it requires authentication, is destructive, or has rate limits. The presence of limit/offset hints at pagination but is not explicitly explained in the description.
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?
The description is extremely concise with two sentences. It front-loads the purpose and immediately provides the essential workflow. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters (including pagination) and an output schema, the description covers the basic purpose and workflow but omits details on pagination behavior, language options, and output structure (though output schema exists). It is adequate for a simple browse tool but lacks completeness for a full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain parameters. Only statistics_id is mentioned ('Use a statistics_id...'). The other parameters (lang, limit, offset) are not described at all, leaving the agent to infer their meaning from the schema alone. This is insufficient given the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Browse nodes under an IDESCAT statistic.' It specifies the resource (nodes) and verb (browse). It also provides a workflow hint linking to sibling tools (idescat_list_statistics and idescat_list_tables), distinguishing this tool from those that list statistics or tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'Use a statistics_id from idescat_list_statistics, then call idescat_list_tables with the returned node_id.' This clearly guides the agent on prerequisites and subsequent steps. It doesn't include exclusions or when-not-to-use, but the flow is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states purpose without disclosing side effects, return format, or behavior of the optional 'name' parameter.
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?
Single concise sentence that is front-loaded with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health check tool with one optional parameter, the description is sufficiently complete, and output schema handles return values.
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 has 100% coverage for the single optional parameter; description adds no additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks server health, distinguishing it from the sibling data query tools.
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?
Implied usage as a health check, but no explicit guidance on when to use or not use compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It indicates a read-only metadata operation, but does not mention any specific behavioral traits such as authentication needs, rate limits, or whether the operation is safe/idempotent. The description is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It is front-loaded with the core action and resource. Slight improvement could be made by adding structure (e.g., listing what is returned), but overall it is efficient.
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?
The tool is simple with one parameter and an output schema, so the description does not need to explain return values. The description is sufficient for understanding the tool's purpose, though it could briefly mention that the output contains metadata and field names.
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?
The schema has 100% coverage for the single parameter source_id, and its description provides an example identifier. The tool's description adds context about 'Catalunya open data Socrata dataset' but does not add new semantic meaning beyond what the schema already provides. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'describe' and the resource 'Catalunya open data Socrata dataset', specifying that it includes queryable API field names. This distinguishes it from sibling tools like socrata_query_dataset and socrata_search_datasets, which handle querying and searching respectively.
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?
The description implies usage for obtaining dataset metadata and field names, but does not explicitly state when to use this tool versus alternatives (e.g., socrata_query_dataset for data queries or bcn_query_resource for general resource info). No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not explicitly state if the tool is read-only, non-destructive, or any safety constraints. The name implies inspection, but behavioral traits like side effects or auth needs are not disclosed.
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?
Two sentences, zero wasted words. Purpose is front-loaded, and every sentence adds value. Highly concise.
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?
Given the tool's simplicity (one parameter, output schema exists), the description covers the key distinction between active/inactive resources. It is nearly complete; only minor behavioral transparency is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 does not explain what 'resource_id' is or how to obtain it. The only parameter is not described beyond the schema's type constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Inspect one Open Data BCN resource' with a specific verb and resource. It distinguishes from siblings by noting that active DataStore resources include queryable fields, and inactive resources should use bcn_preview_resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (inspect a resource) and when to use an alternative (bcn_preview_resource for inactive resources). Provides clear context about active vs inactive resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it returns candidate coordinates using source-bounded resources, implying geocoding with multiple possibilities. Lacks details on error handling, no-match behavior, or rate limits.
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?
Two sentences, no filler, front-loaded with purpose. Every sentence adds necessary context without 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?
Has output schema to document returns. Covers core geocoding function, filters, and usage in relation to sibling. Could mention default behavior or handling of ambiguous queries, but overall adequate.
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 25% (only limit described). Description adds meaning for bbox and kinds by listing filter types (facilities, landmarks, etc.) but does not detail all schema properties like bbox structure. Partially compensates for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves Barcelona place names to WGS84 coordinates using specific Open Data BCN resources. It distinguishes from sibling bcn_query_resource_geo by noting it is for named places instead of lat/lon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs use before bcn_query_resource_geo when user provides a named place. Mentions optional bbox and kind filters, but does not explicitly state when not to use or provide alternative sibling references beyond the one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool only follows HTTPS BCN-hosted URLs and validated redirects, providing important safety and behavior cues beyond the basic fetch action.
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?
Two concise sentences, front-loaded with the core purpose, no wasted words.
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?
Given the presence of an output schema and the tool's simplicity, the description covers the essential context (safe, bounded, non-DataStore). It could mention error behavior or format details, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only 'limit' has description). The description does not add meaning for 'resource_id', which is undocumented. It only mentions 'CSV or JSON preview' vaguely. This is insufficient compensation for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch'), the resource ('preview for an Open Data BCN non-DataStore resource'), and the boundaries (CSV or JSON). It distinguishes from sibling tools like bcn_query_resource and bcn_get_resource_info by specifying 'non-DataStore'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that the tool is for non-DataStore resources, providing clear context. However, it does not explicitly mention alternatives or when not to use it, which would move it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must compensate. It mentions boundedness, flatness, non-exhaustive nature, and retry logic, but does not describe potential errors, side effects, or prerequisites being met.
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 sentences front-load the main action and prerequisite, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. However, given 8 parameters and no schema descriptions, the description omits details on 'lang', 'limit', and error handling, making it somewhat incomplete.
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?
With 0% schema coverage, description adds meaning for required parameters and 'last'/'filters', but does not explain 'lang', 'limit', or the structure of the 'filters' object, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a bounded, flattened data extract and specifies it must be used after two sibling tools, distinguishing it from listing/metadata tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use only after idescat_list_table_geos and idescat_get_table_metadata, and provides instructions for using filters, 'last', and retry logic when narrow_filters is returned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It states the tool is for discovery-only, implying read operation, and details behavior like semantic alias support and geo_candidate preference. Does not mention rate limits or auth, but adequately explains core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences packed with information, front-loaded with purpose. Efficiently includes usage instructions and links to sibling tools. Could be slightly more concise but overall well-structured.
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?
Given the presence of an output schema (not shown), the description covers purpose, usage flow, and provenance. It references related tools and provides enough context for a search/discovery tool. Minor gaps in parameter details but complete for typical use.
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 coverage is 0%, so description must compensate. It adds meaning for 'query' parameter with examples and semantic aliases, but does not describe 'lang' or 'limit' parameters beyond their schema. Partial compensation for missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for 'Topic discovery for IDESCAT Tables v2' with specific verb 'search' and resource 'IDESCAT tables'. It distinguishes from sibling tools like idescat_list_tables and idescat_get_table_data by emphasizing discovery and provenance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on preferring geo_candidates and confirming with idescat_list_table_geos, and notes that search is discovery-only, recommending citation of metadata tools. Lacks explicit when-not-to-use scenarios but gives clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It reveals read-only inspection nature, explains optional place_query triggers filter_guidance, and describes output fields (dimension IDs, category IDs, recommended_data_call). Lacks detail on error conditions or restrictions, but sufficiently transparent for a metadata inspection tool.
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 sentences: first states purpose and prerequisite, second covers optional parameter, third explains downstream use. No redundant words, information is front-loaded. Each sentence contributes distinct value.
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?
Given the tool's role in a pipeline (6 params, 4 required, no annotations), the description covers key aspects: prerequisite, optional feature, and how to use results. It does not detail all parameters, but the output schema is available and the tool's purpose is clear. Minor gaps remain for full parameter documentation.
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 0%, so description must compensate. It explains geo_id (through prerequisite context) and place_query (explicitly with examples). Other parameters (lang, node_id, table_id, statistics_id) are not described, though their roles can be inferred from tool name and typical use. Adds some meaning but not full semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Inspect an IDESCAT table' with specific verb and resource, and distinguishes itself by referencing prerequisite 'idescat_list_table_geos' and downstream tool 'idescat_get_table_data'. It also mentions optional usage for filter_guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite (after selecting geo_id with idescat_list_table_geos) and downstream integration (use returned IDs in idescat_get_table_data). Provides context for when to use, but does not explicitly state when not to use or list alternatives beyond the implicit differentiation from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses use of POST JSON to datastore_search, returns bounded page with truncation. No annotations provided, so description carries burden; lacks details on rate limits or authentication but sufficient for typical use.
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?
Five sentences, no fluff, front-loaded purpose, then guidelines, then technical details.
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?
Output schema exists, so return values not needed. Covers main behavior, pagination mentions truncation but lacks full pagination details. Overall adequate.
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 coverage is low (14%), but description adds context: filters must be JSON, fields should come from bcn_get_resource_info. Does not detail all parameters like q, sort, offset.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries rows from an active Open Data BCN CKAN DataStore resource, distinguishing it from siblings like bcn_preview_resource for non-active resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: call bcn_get_resource_info first, use JSON filters, avoid raw SQL, prefer POST, and use bcn_preview_resource if resource is not DataStore-active.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool is deterministic, source-bounded, and intended as a recommender. It does not mention rate limits or failure modes, but these are less critical. The description implies read-only behavior, which is adequate.
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?
Two sentences efficiently convey purpose, usage context, and parameter hints. No wasted words, front-loaded with the main action. Examples are concrete and helpful.
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?
Given the tool has an output schema (though not shown), the description need not detail return values. It covers usage sequence, parameter intent, and ties to sibling tools. Slightly incomplete: could specify what 'high-value' means or the format of recommendations, but overall sufficient for an AI agent.
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 25% (only limit parameter described). The description adds 'natural-language city question' for the query parameter, but provides no added meaning for task or place_kind, which are enums without descriptions. Baseline 3 because description partially compensates for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it recommends high-value Open Data BCN resources for natural-language city questions. It differentiates from sibling tools like bcn_search_packages by specifying it should be used 'before package search' for broad questions, and mentions follow-up tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (before package search for broad questions like 'trees on a street', 'facilities near a place') and suggests follow-up tools (bcn_get_resource_info, bcn_resolve_place, bcn_query_resource_geo). Also notes the recommender is deterministic and source-bounded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses key behaviors: server caps on rows/bytes, truncation signaling, aggregate query patterns, and stability requirements for pagination. No contradictions exist.
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?
Six concise sentences with front-loaded purpose. Every sentence adds unique value: prerequisite, usage rules, pagination, limits, aggregates. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisite (describe), query construction, pagination, limits, aggregates, and example. Output schema likely handles return values; no gaps for a query tool.
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 already describes each parameter (100% coverage), so description adds limited semantic value. Usage patterns like passing clause values only and needing order with offset are helpful but not parameter-specific meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries rows from a Catalunya open data Socrata dataset, distinguishing it from siblings like socrata_describe_dataset and socrata_search_datasets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises calling socrata_describe_dataset first and using field_name values, provides rules for order with offset, and recommends narrowing filters. Lacks explicit when-not-to-use but offers strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations supplied, so description must disclose behavior. It mentions that active near/bbox calls use generated CKAN SQL internally and explains coordinate field inference. It does not explicitly state read-only nature or error behavior, but the geospatial focus and 'safe' mention imply non-destructive behavior.
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?
A single paragraph of five sentences, each adding distinct value: purpose, data sources, query types, coordinate inference, and fallback for ambiguous fields. No fluff, front-loaded.
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?
Given 13 parameters, nested objects, and an output schema, the description covers the core geospatial functionality and most important parameters. It lacks details on filters and pagination, but those are standard. Overall adequate for initial selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 8%, so the description compensates by explaining the main geospatial parameters (near, bbox, within_place, contains, group_by, lat_field, lon_field). However, it does not explain filters, offset, or fields, leaving some gap for complex filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: running bounded geospatial queries over Open Data BCN resources with WGS84 coordinates. It distinguishes from sibling tools like bcn_query_resource by specifying geospatial capabilities and listing query types (near, bbox, within_place, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use near for distance queries, bbox for rectangular areas, within_place for district/neighborhood polygons...'. It also clarifies that it works for DataStore-active resources and safe CSV/JSON downloads, setting prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![catalunya-opendata-mcp MCP server](https://glama.ai/mcp/servers/aalises/catalunya-opendata-mcp/badges/card.svg)](https://glama.ai/mcp/servers/aalises/catalunya-opendata-mcp)

Score Badge

Copy to your README.md:

[![catalunya-opendata-mcp MCP server](https://glama.ai/mcp/servers/aalises/catalunya-opendata-mcp/badges/score.svg)](https://glama.ai/mcp/servers/aalises/catalunya-opendata-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aalises/catalunya-opendata-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server