mcp-govern

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
Each tool has a clearly distinct purpose, targeting specific data sources (e.g., contracts, subsidies, judicial sentences) and operations. Even overlapping concepts like contract searches are differentiated by source (Catalonia vs. BOE) and type (minor vs. public). Descriptions are explicit and avoid ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in lowercase with underscores. Prefixes like 'bcn_', 'boe_', 'ine_' clearly indicate the data source, and verbs like 'cercar_', 'detall_', 'llistar_' are uniform. No mixing of styles or irregular patterns.
Tool Count4/5
With 49 tools, the server covers an exceptionally broad domain of government transparency in Spain/Catalonia. While the count is high, each tool addresses a specific need (e.g., detecting contract fragmentation, listing salary tables) and the scope justifies the number. Slightly overwhelming but well-scoped.
Completeness5/5
The tool surface is remarkably comprehensive, covering searching, detailing, statistical aggregation, pattern detection (concentration, fragmentation), cross-entity investigation, and field listing across multiple official sources (BOE, BORME, INE, etc.). There are no obvious dead ends or missing CRUD operations for a read-only investigative toolkit.
Average 3.7/5 across 49 of 49 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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 provided, so the description must disclose behavioral traits. It only mentions querying and listing databases, with no details on safety (read-only/mutative), authentication needs, rate limits, or return behavior. The tool's side effects and constraints are unclear.
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?
Two sentences, each carrying purpose. No filler, but could be restructured for clarity (e.g., separating query vs listing). Efficient but leaves ambiguity.
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?
With 3 parameters, no annotations, and an output schema, the description is too brief. It fails to explain what the output contains (whether it's a list of databases or statistical data), how the parameters affect results, or any usage context. Incomplete for a data-retrieval 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 coverage is 100% (all parameters described in schema). The description adds 'Es pot filtrar per tema' which mirrors the schema description for 'tema', but misses the other parameters (any, territori). It does not provide additional meaning beyond the schema.
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 consults judicial statistics and lists databases, which is ambiguous: does it return actual statistics or just a list of available databases? The parameters (year, theme, territory) suggest querying data, but the description emphasizes listing databases. This vagueness reduces clarity.
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 siblings like cgpj_cercar_sentencies or cgpj_dades_corrupcio. Does not specify prerequisites, limitations, or alternatives. The description implies it's for statistics, but doesn't contrast with 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?
No annotations are present, so the description carries the full burden. It describes the basic search operation but does not disclose external API dependency, rate limits, authentication, idempotency, or data freshness. The mention of dataset count is factual but not behavioral.
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 concise with only three sentences, front-loaded with the action. It efficiently communicates the purpose, but could be slightly more structured (e.g., separate usage context).
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 6 optional parameters and an output schema, the description is minimal. It does not mention pagination behavior despite page/page_size parameters, nor does it describe the result structure. The output schema likely covers return values, so completeness is adequate but lacks some contextual details.
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 baseline is 3. The description adds no additional parameter meaning beyond what is already in the input schema descriptions. It provides a general context but no extra details.
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 searches datasets in the national open data catalog (verb 'cerca', resource 'datasets', specific catalog). It mentions available topics and dataset count, distinguishing it from other search tools by being specific to datos.gob.es. However, it does not explicitly contrast with sibling search tools.
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 other 'cercar' siblings (e.g., cercar_contractes, cercar_subvencions). There are no examples, prerequisites, or exclusions mentioned.
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 fails to disclose behavioral traits such as read-only nature, rate limits, or side effects. It only describes the search behavior implicitly, lacking explicit guarantees.
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 concise with two sentences, efficiently stating the purpose and providing a bulleted list of content areas. No unnecessary words, though a more structured format (e.g., using bullet points) could improve readability.
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 is adequate for a search tool given the presence of an output schema, but it lacks hints about pagination behavior, result limits, or how to interpret the output. The description covers scope but not operational details.
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?
The description adds meaningful context beyond the schema by listing example queries and dataset categories. Schema coverage is 100%, but the description enhances understanding with specific use examples (e.g., 'pressupost', 'seguretat').
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 searches datasets in Barcelona's open data portal, listing example content areas. It distinguishes from siblings like bcn_detall_dataset (detail) and bcn_obtenir_dades (data retrieval) by name and context, though not explicitly.
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 like cercar_contractes or datosgob_cercar_datasets. The description only states what it does, not when to choose it.
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 carry the full burden. It does not disclose behavioral traits such as pagination behavior (limit/offset mention only in schema), search type (exact/fuzzy), read-only nature, or any rate limits. The description only repeats filtering capability and returned fields, which are already partially in the schema.
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 short sentences. The first immediately states the purpose, and the second lists filters and returned fields. No wasted words, perfectly front-loaded.
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 tool has 8 optional parameters and an output schema, the description is brief but covers the core purpose and mentions returned fields. However, it lacks usage context, behavioral details, and pagination explanation, making it only minimally complete for an agent to use effectively.
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 baseline is 3. The description mentions some filters (any, departament, finalitat, import) but adds little meaning beyond the schema descriptions. However, it lists returned fields (codi, títol, objecte, etc.) which adds value over the schema, as there is an output schema present. Overall, adequate but not exceptional.
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 it searches for grant calls (convocatòries de subvencions) in RAISC, with filters by year, department, purpose, and amount. It lists returned fields, but does not explicitly differentiate from sibling tools like 'bdns_cercar_convocatories' or 'cercar_subvencions', though the RAISC mention provides specificity.
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 given on when to use this tool versus alternatives (e.g., 'bdns_cercar_convocatories' for BDNS searches or 'cercar_subvencions' for subsidies). No prerequisites or exclusions are mentioned, leaving the agent without context for selection.
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 lists return fields but omits details about pagination (limit/offset handling), read-only nature, authorization requirements, or any side effects. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: the first states the function, the second lists return fields. It is front-loaded and contains no redundant information, though it could be slightly more structured.
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 tool has 7 parameters, full schema descriptions, and an output schema, the description is adequate but lacks detail on pagination behavior, sorting, or example usage. It is minimally viable but leaves gaps for an agent to infer intent.
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% with each parameter already described (e.g., 'Tema de la reunió'). The description adds a list of return fields but does not provide additional meaning beyond the schema. 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 it searches for meetings of senior officials with interest groups (lobbies), with a specific resource and verb. It distinguishes from sibling tools like 'cercar_viatges_alts_carrecs' or 'cercar_declaracions_activitats' by focusing on lobby meeting records.
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?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, exclusions, or best practices. It only states the function without contextual usage direction.
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 cover behavior. It lacks information on side effects, authentication, pagination, or rate limits. Only lists return fields.
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 action and return summary. Every word is essential. No fluff.
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 an output schema exists (not shown), the description adequately summarizes return fields. However, it could mention pagination or filtering patterns. Overall, sufficient for a simple search 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 description coverage is 100%, so the baseline is 3. The description adds context by listing return fields, but does not elaborate on parameter semantics beyond what the schema already provides.
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 searches the Job Positions List (RLT) of the Generalitat and lists return fields. However, it does not explicitly differentiate from sibling tools like 'cercar_oferta_ocupacio' which also deals with jobs.
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 (e.g., when to use 'cercar_oferta_ocupacio' instead). No prerequisites or constraints mentioned.
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 does not disclose behavioral traits such as rate limits, authentication requirements, or side effects. Only states what the tool returns.
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 that front-load the purpose and list return fields. No unnecessary words, making it efficient for an agent to parse.
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?
With output schema present and only 3 parameters, the description is sufficient but could provide more context on filtering behavior or result ordering. Still, it covers the essential return structure.
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 baseline is 3. Description adds no additional meaning beyond the schema's parameter descriptions. It mentions return fields but not parameter details.
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?
Description clearly states it searches public employment offers of the Generalitat and lists return fields. However, it does not differentiate from sibling tools like cercar_llocs_treball or cercar_convocatories, which may overlap in purpose.
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. Does not specify prerequisites or typical use cases.
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 provided, the description carries the full burden. It states the return fields but does not disclose pagination behavior, rate limits, authentication needs, or any side effects. Given the absence of annotations, more detail is needed.
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 concise, with two sentences achieving the core purpose. It is front-loaded with the action and resource, then lists return fields. Every sentence earns its place, though it could be slightly more structured with separate sections.
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 7 parameters and multiple sibling tools, the description is adequate but incomplete. It explains the purpose and return fields but does not elaborate on filtering options, parameter interactions, or output schema details. For a search tool, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description only lists return fields that correspond to some parameters (e.g., exercici, programa) but adds no new meaning or usage details beyond the schema. It provides context about what the tool returns, which is marginally helpful.
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 'cerca' (search) and the resource 'pressupostos aprovats de la Generalitat de Catalunya', and lists the returned fields. It distinguishes from siblings like 'cercar_pressupostos_municipals' and 'pge_despeses' by specifying the government level and budget type.
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?
The description lacks guidance on when to use this tool versus alternatives. It does not specify exclusions, prerequisites, or preferred scenarios, leaving the agent to infer from the name and siblings alone.
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, and the description only states search and return fields. It does not disclose whether it is read-only, any pagination behavior, rate limits, or other important traits.
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 two sentences: one for purpose and one for return fields. It is concise and front-loaded with no unnecessary 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?
Given the existence of an output schema, the description is adequate but incomplete. It lacks details on pagination, authentication, or result limits beyond the default parameter 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 coverage is 100%, so parameters are already described. The tool description lists return fields, providing context for filtering, but does not add extra semantics beyond what the schema provides.
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 searches for public and private activity declarations of high officials, with a specific verb and resource. It distinguishes itself from sibling tools like 'cercar_viatges_alts_carrecs' which search for different data.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or comparative advantages.
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 convey behavior. It only lists return fields but does not disclose that the tool is read-only, has no side effects, or any rate limits. The agent cannot infer safety or restrictions.
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 two sentences with no wasted words. It front-loads the purpose and concisely lists return fields. Ideal length for quick comprehension.
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 output schema exists, the description need not detail return values, but it does anyway. It covers the core functionality for a search tool with well-described parameters. However, missing usage guidelines and behavioral transparency slightly reduce 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?
All 5 parameters have descriptions in the input schema (100% coverage). The tool description does not add additional meaning beyond the schema, so it meets the baseline for high 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 the tool searches budgets of municipal entities in Catalonia and specifies the returned fields (municipi, any, partida, descripció, import). This distinguishes it from sibling tools like 'cercar_contractes' or 'cercar_subvencions' which target different data.
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. The description only states what the tool does, without mentioning prerequisites, context, or when not to use it.
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, the description partially discloses behavior by stating it returns 'the values of the latest periods' and provides example indicators. However, it does not mention read-only nature, rate limits, data freshness, or limitations on the number of periods (nult default is noted in schema but not description). The output schema covers return format but the description lacks full 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short sentences, front-loading the main action. Every sentence contributes value, and there is no unnecessary detail.
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 has an output schema, so return values are covered. The description is adequate for a simple 2-parameter tool, though it could mention that table IDs come from ine_taules. Overall, it is mostly complete given the context signals.
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%, with both parameters already described. The description adds no extra meaning beyond the schema; it repeats 'últims períodes' which aligns with nult. Therefore baseline score of 3 is appropriate.
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 it retrieves data from an INE statistical table, specifying 'Obté les dades d'una taula estadística de l'INE' and listing example indicators. It implicitly differentiates from sibling tools like ine_taules (which lists tables) by focusing on retrieving data for a given table, but no explicit comparison.
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 like ine_serie or ine_taules. There is no mention of prerequisites, best practices, or exclusions.
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 behavior. It states the tool returns the 'latest value', but does not explain behavior for invalid series codes, multiple series (comma-separated), or any side effects. The lack of behavioral detail is a significant gap for a tool without annotations.
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, consisting of two sentences that efficiently convey the purpose and context. Every sentence adds value without redundancy.
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 tool's simplicity (one parameter) and the presence of an output schema (so return values need not be described), the description is reasonably complete. However, it lacks information on error handling, authentication, or limitations, which would be expected given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about the types of series available (Euribor, IPC, etc.), supplementing the schema's examples. However, it does not add much beyond what the schema already provides, so the 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 tool's purpose: obtaining the latest value of financial series from the Bank of Spain. It specifies the resource (financial series from BDE) and the action (obtain latest value), and distinguishes it from siblings like 'bde_series_destacades' which likely provides predefined highlighted series.
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 provides a high-level use case ('Per contextualitzar investigacions amb dades macroeconòmiques'), but does not offer explicit guidance on when to use this tool versus alternatives like 'bde_series_destacades' or other data tools. No exclusions or prerequisites are mentioned.
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, the description carries full burden. It implies a read-only search operation but does not explicitly state safety (e.g., no destructive actions). It mentions return fields but lacks details on pagination behavior, authentication needs, rate limits, or error responses.
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 two sentences: the first states the purpose with verb and resource, the second lists return values. It is front-loaded, efficient, and contains no extraneous text.
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 4 parameters (none required) and no annotations, the description is minimal. It explains what the tool returns but omits broader context such as how pagination works, date range interpretation, or relation to siblings. The output schema exists but is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no parameter information beyond the schema; it only lists return fields. The schema adequately documents each parameter's format and defaults.
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 searches for grant calls in BDNS ('Cerca convocatòries de subvencions a la BDNS') and lists the returned fields (codi BDNS, descripció, òrgan convocant, imports, dates). It is specific and distinct from siblings like 'bdns_detall_convocatoria' and 'bdns_cercar_concessions' by name and context.
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 such as 'bdns_detall_convocatoria' for details or 'cercar_subvencions' for broader searches. The description does not mention prerequisites, exclusions, or typical use cases.
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; the description lists the content but does not mention side effects, authorization requirements, or data freshness. The output schema exists but is not described.
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 short and efficient, with two sentences listing the key contents. Slightly more detail than necessary, but still 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 has an output schema, the description adequately covers what the tool does and returns. Lacks some context about the BDNS system, but sufficient for its simplicity.
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 covers 100% of parameter descriptions, including an example. The tool description adds no further information beyond what the schema already provides, so baseline score.
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 retrieves the complete details of a BDNS call, and lists the included fields, effectively distinguishing it from sibling tools like bdns_cercar_convocatories.
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, such as whether to first search for calls via bdns_cercar_convocatories before retrieving details with this tool.
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 are provided, so the description carries full burden. It warns that 'retribucio_anual_prevista' is text and sorting may not be numeric, which is a helpful data quality disclosure. However, it does not discuss authentication, rate limits, performance implications, or data freshness.
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 concise: two paragraphs with clear information. The first paragraph states the purpose and output fields, the second adds usage and a note. No unnecessary sentences.
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 7 parameters, no required ones, and an output schema (context signals), the description adequately covers the main use cases, return fields, and a notable data quality issue. It could mention pagination handling (limit/offset) but the schema covers that. Overall, appropriate 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% with descriptive parameter descriptions (e.g., 'Denominació del càrrec (ex: "President")'). The description adds usage hints for 'carrec' and 'nom' but not for other parameters like 'cerca_lliure' or 'vinculacio'. The added value over the schema is modest, justifying a baseline of 3.
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 searches for nominal retributions of high-ranking officials (alts càrrecs) of the Generalitat, listing returned fields and example positions. It distinguishes itself by focusing on retribucions of alts càrrecs, but does not explicitly differentiate from siblings like 'cercar_directius_sector_public' or 'cercar_retribucions_subvencionats'.
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 provides basic usage guidance: use 'carrec' for searching by position and 'nom' for searching by person name. However, it lacks guidance on when to use this tool versus siblings, and no exclusions or prerequisites are mentioned.
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 are provided. The description adds context about returned fields (grup, nivell, etc.) and a special case for 'alts_carrecs'. It does not disclose read/write behavior, side effects, or limitations beyond what the schema indicates. The 'any' parameter (year) is briefly exemplified but not fully explained.
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 concise (5 lines) and efficiently conveys purpose, return fields, special case, and available options. No fluff, though it could integrate the list of cossos more compactly.
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 full param coverage, the description adequately explains the tool's main purpose, output content, and key parameter (cos) options. It omits details about limit and categoria usage but those are covered in schema descriptions.
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 descriptions cover 100% of parameters. The description redundantly lists the cos values and mentions an example for 'any' ('2024'), but adds no substantial meaning beyond the schema. Baseline score of 3 is appropriate as the description does not compensate for opaque 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 consults official salary tables by 'cos' (body) of the Generalitat, specifies returned fields (grup, nivell, sou base, complements, total mensual/anual), and lists available cossos. However, it does not explicitly distinguish from siblings like 'cercar_retribucions_alts_carrecs', which likely serves a similar purpose for high officials.
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 by listing cossos and noting a special case for 'alts_carrecs', but it lacks explicit guidance on when to use this tool versus alternatives (e.g., other salary tools). No when-not-to-use or exclusion criteria.
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 describes the output (tree with links) but does not disclose whether the tool is read-only, requires authentication, has rate limits, or any side effects. The description implies a safe retrieval, but without explicit statement, agents may be uncertain.
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 concise, consisting of two short paragraphs. The first sentence clearly states the main purpose. There is no unnecessary repetition or verbosity. It earns a high score for efficiency.
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 optional parameter) and the presence of an output schema, the description is mostly complete. It explains what the tool returns (tree structure with links) and the valid year range. It could be improved by referencing the sibling tool pge_despeses for differentiation, but overall it is sufficient.
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% with a single parameter 'any_'. The description adds the year range (2015-2025) which is already suggested in the schema's parameter description. Thus, the description provides minimal added value over the schema.
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 that the tool retrieves the structure of the Spanish State General Budgets (PGE). It specifies returning a tree of sections, subsectors, and programs with links to files. This verb+resource description distinguishes it from siblings like pge_despeses, which likely deals with expense details.
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 mentions the available year range (2015-2025) which provides some context, but it does not explicitly state when to use this tool versus alternatives, nor does it provide any conditions for when not to use it. The sibling lists include pge_despeses, but no contrast is made.
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 mentions each entry includes a PDF, but lacks disclosure of behavioral traits such as rate limits, authentication needs, or side effects. Since it's a read operation, it's not destructive, but this is not explicitly stated.
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 concise, front-loads the main purpose, uses bullet-like list for acts, and has no redundant words. Three short paragraphs effectively convey the tool's scope.
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 that an output schema exists (context says 'Has output schema: true'), the description need not explain return values. It mentions the PDF inclusion, which adds value. For a simple query tool, the description is sufficient.
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% with both parameters described. The description does not add additional meaning beyond the schema; it only restates the date format and partial province text. Baseline score of 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 it consults the BORME daily summary, lists types of acts (constitutions, appointments, etc.), and distinguishes from sibling tools like boe_sumari which covers BOE instead of BORME.
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?
It states usefulness for investigating corporate activity and cross-referencing with public contracts, but does not explicitly mention when not to use this tool or provide direct comparisons to alternatives like boe_sumari or cercar_contractes.
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 does not disclose behavioral traits such as read-only nature, pagination limits (max 50000 from schema), or data freshness. Only mentions output fields.
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: purpose, filters, output. Front-loaded and no fluff. Efficient for agent understanding.
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 9 parameters, 0 required, and existence of output schema, description is complete enough. Could mention registry source explicitly, but name implies it.
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% with descriptions. Description lists some filters but adds no additional meaning beyond the schema. 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?
Description clearly states verb (cerca) and resource (contractes públics al Registre públic de contractes de Catalunya). Distinguishes from sibling tools like detall_contracte (detail) and boe_contractes (different source).
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?
Description lists filters but does not explicitly state when to use this tool vs alternatives like cercar_contractes_menors or other contract search tools. No guidance on 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.
Behavior3/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 discloses that the tool searches granted subsidies ('concedits') and lists returned fields, but lacks details on pagination behavior, authentication needs, or any side effects. It is minimally 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?
The description is extremely concise — two short sentences that efficiently convey purpose and filter capabilities. Every sentence is necessary, and no extraneous information is included.
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 10 parameters (none required), a clear purpose, and an output schema (not shown but present), the description covers the core functionality. It could be more complete by adding usage guidelines, but it adequately covers the basics for a search 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 description coverage is 100% (all 10 parameters have descriptions). The description adds a summary of filter options but does not provide additional semantic meaning beyond what the schema already offers. Baseline of 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 ('Cerca') and resource ('subvencions i ajuts concedits al RAISC'), and specifies the scope (Catalunya). It distinguishes itself from siblings by referencing RAISC, while siblings target different databases (BDNS, BOE, etc.) or contract types.
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?
The description does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusion criteria or guidance on prerequisites. It only lists filtering capabilities without context on when it's appropriate.
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 the full burden. It does not disclose behavioral traits such as read-only nature, pagination details, rate limits, or error handling. The description is too brief to inform the agent about potential side effects 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and covers key filters. It is a single paragraph without unnecessary words, earning a high score for efficiency.
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 6 parameters and the presence of an output schema, the description is somewhat incomplete. It does not explain pagination (offset/limit) or free text search, nor does it provide guidance on combining filters. More detail 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 baseline is 3. The description mentions three filters (titol, rang, any) but does not explain limit, offset, or cerca_lliure. While the schema covers them, the description adds little value beyond what the schema already provides.
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 searches regulations (normativa) in the DOGC, specifies the types (lleis, decrets, etc.), and mentions filters. It distinguishes itself from sibling tools that target other official journals like BOE or BORME.
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 makes it clear that this tool is for DOGC regulations, which implicitly tells the agent not to use it for other data sources. However, it does not explicitly provide when-not-to-use or mention alternative tools for other sources.
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, the description partially compensates by stating it returns fields like consolidation status. However, it does not disclose read-only behavior, authentication needs, or rate limits. The tool is a search operation, so the safety profile is implied.
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 concise with two sentences covering purpose, filters, and output. It is front-loaded but could benefit from a bulleted list for readability.
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 6 optional parameters and the existence of an output schema, the description adequately summarizes the tool's capabilities. It mentions the key returned fields, though it omits pagination details which are covered by the schema.
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 does not need to add parameter details. It restates filterable fields already in the schema, providing no extra meaning beyond what is in the 'description' properties.
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 searches consolidated Spanish legislation via BOE. It lists the filtering capabilities and the returned fields, distinguishing it from sibling tools like 'boe_contractes' or 'boe_nomenaments'.
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 searching legislation but does not provide explicit guidance on when to use this tool versus alternatives (e.g., 'boe_sumari' for daily summaries). No exclusions or prerequisites are mentioned.
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 are provided, so the description carries full burden. It correctly implies a read operation returning documents for a date. However, it does not disclose whether the response is paginated, has rate limits, or what happens with empty results. This is a minor gap for a tool that may return large datasets.
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 two paragraphs, front-loaded with purpose and sections, followed by a practical cross-referencing tip. Every sentence is meaningful, no fluff. Appropriate length for the tool's complexity.
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 an output schema exists, the description does not need to detail return format. It covers purpose, parameters, and a use case. Missing explicit notes on empty results or pagination, but overall sufficient for a straightforward query tool.
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 descriptions already cover all parameters (100% coverage). The description adds value by providing usage tips (e.g., trying recent working days for dates, listing section codes with examples). This extra context helps the agent select correct values.
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 it consults the daily BOE summary and lists specific sections (2A, 5A, 1) with their uses. It is a specific verb-resource combination ('Consulta el sumari diari'), but does not explicitly differentiate from sibling tools like boe_contractes or boe_nomenaments, which could be inferred.
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 provides context on when to use (finding appointments, contracts, general provisions) and even suggests cross-referencing with other tools for fraud detection. However, it does not explicitly state when not to use this tool or name alternatives, leaving room for confusion with more specific BOE tools.
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 are provided, so the description carries the full burden. It lists what is included (distributions, metadata, frequency, resources) implying a read operation, but does not explicitly mention safety, side effects, or any limitations. Adequate for a simple retrieval 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?
The description is two short sentences, front-loaded with the purpose, and lists contents efficiently. No wasted words.
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?
With one parameter and an output schema, the description adequately explains what the tool returns. For a detail retrieval tool, it is complete.
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% and the parameter description already states it is obtained from search. The tool description does not add additional semantics beyond what the schema provides. 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 'Obté' (get) and the resource 'detall complet d'un dataset de datos.gob.es'. It specifies the source (datos.gob.es) distinguishing it from sibling tools for other sources like bcn_detall_dataset. The contents are listed.
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?
The description does not provide guidance on when to use this tool vs alternatives. It only implies through the parameter description that it should follow a search, but the description itself gives no explicit usage context or exclusions.
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 that the tool is read-only, nor does it mention rate limits, pagination behavior beyond offset, or potential large result sets. Minimal behavioral context is given.
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 clear, front-loaded sentences with no extraneous information. Every sentence serves a purpose: stating the function and providing usage flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple data retrieval tool with output schema available, the description is adequate. It covers purpose and prerequisite. Could be more complete by mentioning data format or limits, but output schema mitigates this.
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 baseline 3. The description adds value by explaining resource_id as obtained from bcn_detall_dataset, but does not enhance semantics for limit, query, or offset beyond what the schema provides.
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 'Obté dades' and the resource 'un recurs concret de Barcelona'. It distinguishes from siblings by specifying the prerequisite step using bcn_detall_dataset, which sets it apart from search and detail 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?
The description provides explicit guidance: first use bcn_detall_dataset to get resource_id, then this tool. It implies when not to use (without resource_id) but does not explicitly state alternatives or exclusions.
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?
The description highlights that it returns real names (privacy implication) and lists return fields. With no annotations provided, this adds important behavioral context. However, it does not mention that this is a read-only search or pagination 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?
The description is concise, with purpose stated first, followed by key features and a tip. Every sentence adds value. No 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?
The description covers purpose, filters, return fields, and a region-specific tip. It does not mention pagination. Given the presence of an output schema, the missing pagination note is a minor gap but overall adequate for a search 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?
All parameters have schema descriptions (100% coverage). The description reinforces the filter options and adds a specific tip about using 'CATALUÑA' for community. While helpful, it does not provide substantial new meaning beyond the schema.
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 it searches for concessions (granted subsidies) in BDNS Spain. It lists filters and return fields. However, it does not explicitly differentiate from similar sibling tools like 'cercar_subvencions' or 'bdns_cercar_convocatories', though the name suggests distinction.
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 provides filter options and a tip for Catalonia, but no explicit guidance on when to use this tool vs siblings. The context of searching for granted concessions implies use cases, but comparative guidance is missing.
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, the description must disclose behavioral traits. It mentions the data source (BOE Section 5A) and content (tenders and awards) but omits details on pagination, response format, or any side effects, which is adequate for a straightforward search 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?
Two sentences clearly state the purpose and scope with no unnecessary words. The description is front-loaded and every sentence adds 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 an output schema exists, parameter descriptions are thorough, and the tool is simple, the description is largely complete. It could mention date search limitations or error handling, but it sufficiently covers the main purpose.
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 baseline is 3. The description does not add extra meaning to parameters beyond what the schema provides (date format, optional department filter).
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 searches public procurement announcements in the BOE, specifically extracting Section 5A. It includes both tenders and awards, distinguishing it from sibling tools like 'cercar_contractes' or 'boe_sumari'.
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 the tool is for BOE public procurement searches but provides no explicit guidance on when to use versus alternatives (e.g., 'cercar_contractes' for other sources) or when not to use it.
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 are provided, so the description carries the full burden. It specifies that the tool extracts section 2A, which is a behavioral detail, but it does not disclose other traits like authentication needs, rate limits, or whether it is read-only. The description is adequate but not thorough.
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 two sentences long, front-loaded with the main purpose in the first sentence. The second sentence adds specificity and a use case without unnecessary 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 that an output schema exists (not shown), the description does not need to explain return values. It concisely covers the tool's scope and use case, though it could briefly mention the output format.
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%, and both parameters ('data' and 'departament') have descriptions in the schema. The description adds context about extracting section 2A but does not provide additional meaning for the parameters beyond what the schema already conveys.
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 that it searches for appointments, cessations, and personnel situations in the BOE, specifically extracting section 2A. It also mentions a specific use case (detecting revolving doors), which distinguishes it from sibling tools like boe_contractes or boe_departaments.
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 the tool is for personnel changes in BOE section 2A and mentions a use case for detecting revolving doors, but it does not explicitly state when to use it versus alternatives or provide any exclusions.
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 are provided, so the description carries full burden. It specifies return fields and example entities but does not disclose behavioral traits such as case sensitivity, fuzzy search, authentication needs, rate limits, or pagination behavior beyond the schema's offset/limit parameters. It is generally transparent but lacks 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 short sentences that front-load the purpose and output details. Every sentence is informative, with no redundant or extraneous content.
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 complexity (6 optional parameters, search functionality, output schema exists), the description adequately covers purpose and output fields. However, it could be more complete by noting sorting behavior or handling of empty results. The examples help, but pagination is only implied via schema parameters.
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 input schema has 100% description coverage, so the schema already explains each parameter. The description adds marginal value by listing example entities and output fields but does not elaborate on parameter semantics further. 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 it searches salaries of public sector executives ('Cerca retribucions del personal directiu d'entitats del sector públic'), lists specific output fields (NOM, càrrec, entitat, departament, retribució fixa anual), and provides example entities. This distinguishes it from siblings like 'cercar_retribucions_alts_carrecs'.
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 searching executive salary data, but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria. Context signals show many sibling tools, but no comparative guidance is given.
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, and the description lacks behavioral traits such as read-only status, rate limits, pagination behavior, or authentication needs, leaving the agent uninformed about side effects or restrictions.
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 two sentences long, front-loaded with the purpose, and every sentence adds necessary information without waste.
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 complexity of 9 parameters and no annotations, the description provides a good overview of functionality and return fields. It lacks pagination details but output schema exists; overall reasonably complete.
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 coverage is 100%, so baseline is 3. The description adds value by listing the fields available in results (e.g., imports amb i sense IVA, dates, enllaç), providing context beyond parameter 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?
The description clearly states it searches publications on the PSCP platform, listing included types (licitacions, adjudicacions, formalitzacions) and fields, distinguishing it from sibling tools by specifying the source.
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 PSCP contract publications but does not explicitly guide when to use it vs alternatives like cercar_contractes or cercar_subvencions.
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 are provided, so the description must convey behavioral traits. It states what the tool returns but does not disclose if it is read-only, authentication needs, rate limits, or side effects. Basic behavioral info is present 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the primary purpose. Every word adds value, with no 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?
Given 5 parameters and an output schema, the description covers the tool's core function and return fields. It could mention pagination or how to use filter parameters like carrec or empresa, but overall it is sufficient for understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented in the input schema. The tool description adds no additional parameter meaning beyond what the schema provides, earning a baseline score of 3.
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 searches for retributions of directors of entities receiving subsidies >10,000€ and lists the returned fields (entitat, càrrec, retribucions anuals, objecte de la subvenció). This distinguishes it from siblings like cercar_retribucions_alts_carrecs (high-ranking officials) and cercar_subvencions (subsidies).
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 finding retributions of directors of highly subsidized entities but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among 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?
No annotations are provided, so the description must carry the burden of behavioral transparency. It discloses the returned fields, but does not mention pagination behavior, rate limits, or whether the operation is read-only. The agent can infer it is a search (likely read-only), but details are missing.
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 short paragraphs: one for purpose and one for output fields. Every sentence adds value, with no fluff.
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 that an output schema exists (not shown), the description is reasonably complete. It covers the core purpose and output fields. However, it lacks explanation of the 'cerca_lliure' parameter and pagination, but these are documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description does not add meaning beyond the schema; it only lists output fields. No parameter usage details or syntax are added.
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 searches for trips abroad of high-ranking officials of the Generalitat, using a specific verb and resource. This distinguishes it from sibling tools like cercar_retribucions_alts_carrecs or cercar_directius_sector_public.
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 does not provide any explicit when-to-use or when-not-to-use guidance. It only states what the tool does, leaving the agent to infer context from the name. No alternatives or exclusions are mentioned.
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, the description carries the full burden. It clearly indicates a read operation ('Obté dades') but does not disclose any behavioral traits such as authorization requirements, rate limits, or data freshness. The safety profile is implied as non-destructive.
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 two concise paragraphs, with the main action front-loaded in the first sentence. Every sentence adds meaningful context about the data source and scope. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with an output schema, the description provides sufficient context about the data (corruption proceedings, macro-causes, relevant courts). It could mention update frequency or access constraints, but overall it is complete for its simplicity.
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 input schema has zero parameters with 100% schema description coverage. By rule, baseline is 3. The description adds context about the data content (macro-causes, National Court) but does not explain parameters as none exist. No contradiction.
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 'Obté' (obtains) and the specific resource: data from the CGPJ's corruption proceedings repository. It distinguishes from sibling tools like 'cgpj_cercar_sentencies' by focusing specifically on corruption-related macro-cases and superior court proceedings.
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 corruption proceedings data but does not explicitly state when to use this tool over alternatives. No exclusions or comparisons to siblings are provided, leaving the agent to infer context from the title.
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. The description implies a read operation ('obté') but does not explicitly state lack of side effects, permissions, or rate limits. It discloses the output (lots and complete info) but lacks deeper 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence states purpose, second describes output. Efficient and 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 the simple tool (1 param, output schema present), the description covers purpose and output. It does not detail return fields but output schema handles that. Lacks mention of edge cases (e.g., invalid code), but completeness is 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 100% with parameter description 'Codi de l'expedient del contracte'. The description repeats this by mentioning 'codi d'expedient', adding no new semantic value. 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 (Obté) and resource (detall complet d'un contracte), and specifies the input (codi d'expedient). It distinguishes from sibling tools like cercar_contractes (search) by indicating it returns full detail including lots.
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?
No explicit when-to-use or when-not-to-use statements. Usage is implied by context: you have an expedient code and need complete details. No alternatives are mentioned.
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 the full burden. It does not disclose whether the tool is read-only, authentication requirements, error handling for invalid codes, or rate limits. The description only states it 'gets details' without 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence clearly states the purpose, and the second provides a necessary usage condition. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with an output schema, the description is fairly complete. It states what it does and the requirement for input. However, it does not mention behavior when both codes are provided or error cases when neither is provided.
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 coverage is 100%, so the schema already describes each parameter. The description adds the constraint 'Cal proporcionar almenys un dels dos codis' (must provide at least one code), which improves parameter semantics beyond the 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 retrieves full details of a grant using either RAISC or BDNS code. It specifies the resource (subvenció) and action (detall complet), effectively distinguishing it from sibling search tools like 'cercar_subvencions'.
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 states the requirement of providing at least one code, but it does not provide guidance on when to use this tool versus alternatives (e.g., when to choose this over 'cercar_subvencions' or 'bdns_detall_convocatoria'). No explicit when-not or alternatives are mentioned.
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 are provided, so the description carries the full burden. It explains what the tool analyzes but does not explicitly state whether it is read-only, requires authentication, or has side effects. Given the detection nature, read-only is implied, but not confirmed. The description adds behavioral context about analysis content but omits operational details.
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 concise and well-structured. It starts with the core purpose in one sentence, then provides a brief definition of fragmentation, and lists the analysis dimensions. Every sentence adds value without redundancy. It is appropriately sized for the tool's complexity.
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 description is largely complete given the tool's complexity and the presence of an output schema. It explains the detection logic and what it analyzes. However, it lacks mention of how results are returned (e.g., boolean, list) or prerequisites (e.g., company existence). Still, it provides sufficient context for correct invocation.
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% (both parameters have descriptions in the input schema). The tool description does not add new meaning to the parameters beyond what the schema already provides. It explains the analysis context but not parameter-specific details, so it scores the baseline of 3.
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: detecting possible fragmentation of minor contracts for a company. It provides a detailed explanation of what fragmentation is (dividing a large contract to avoid public bidding) and lists the specific aspects analyzed (number of contracts, amounts, departments, temporal patterns). This makes the tool's function distinct from siblings like 'cercar_contractes_menors' or 'detectar_concentracio_contractes'.
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 detecting contract fragmentation but does not explicitly state when to use this tool versus alternatives. It offers no guidance on prerequisites, when not to use it, or how it compares to related tools. The context is clear, but explicit exclusion or alternative guidance is missing.
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. The description does not disclose any behavioral traits such as idempotency, rate limits, or permission requirements. For a read-only query, the lack of safety indicators is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that front-load the purpose, immediately followed by usage guidance. 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?
The tool is simple with one parameter and has an output schema. Description is sufficient for a basic retrieval, though it could explicitly state that it returns 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?
Schema coverage is 100%, so the description adds little beyond the schema. It reinforces the context of using with 'estadistiques' but doesn't add new parameter 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 it returns available fields of a dataset (verb 'retorna' + resource 'camps disponibles d'un dataset'). It distinguishes from sibling tools by mentioning it should be used before 'estadistiques'.
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 using this tool before 'estadistiques' queries to know exact field names. However, it does not mention when not to use or alternative tools beyond that single sibling.
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, the description carries full burden. It discloses that the tool downloads and parses CSVs, which is behavioral, but lacks detail on data freshness, rate limits, or error handling. It is adequate but not rich.
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?
Very concise: two short paragraphs with front-loaded purpose. Every sentence adds value, no filler.
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 description is complete enough given the presence of an output schema (return values are covered). It explains the source and structure of data. Minor gap: no mention of data scope or caching, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema: it restates that parameters are 'any' and 'seccio' but offers no new constraints or formatting details.
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 obtains expenses from the Spanish General Budgets, downloads/parses CSV files, and returns real amounts per budget program. It uses a specific verb (obté) and resource (despeses dels Pressupostos Generals de l'Estat), and distinguishes from siblings like 'cercar_pressupostos' by focusing on expenses.
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 expense data but provides no explicit guidance on when to use this tool versus alternatives (e.g., 'cercar_pressupostos' for overall budgets or 'pge_estructura' for structural data). No when-not or prerequisites are mentioned.
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, the description carries the full burden. It states the tool returns aggregated data (company, number of contracts, total amount) and implies read-only behavior. However, it lacks details on data source, freshness, or any side effects. For a query tool, this is minimally 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?
The description is concise (three sentences) and front-loaded with the core purpose. Every sentence adds value: what it detects, what it shows, and what it returns. 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 simple tool with three optional parameters and an output schema, the description covers the main aspects: purpose, behavior, and return fields. It lacks details like pagination or date range limits, but is sufficient 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 100% with descriptions for all three parameters. The description adds little beyond the schema, only reinforcing that 'departament' is optional. Baseline 3 is appropriate as the schema does the heavy lifting.
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 detects anomalous concentration of contracts among few companies, shows companies with most contracts and total amount per department or year, and is useful for detecting favoritism. This distinguishes it from siblings like 'cercar_contractes' (search contracts) and 'detall_contracte' (contract details).
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 implies usage for detecting potential favoritism when analyzing contract concentration. It provides context (per department or year) but does not explicitly state when not to use or mention alternatives. Given siblings, the purpose is clear enough to guide selection.
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 are present, so the description carries full burden. It discloses that the tool fetches a time series by code, but does not mention safety (read-only), rate limits, or data freshness. The behavior is implied but not explicitly stated beyond what the schema provides.
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 two concise sentences, front-loading the action and usage. Every word is necessary and 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?
Given the tool's simplicity, existence of an output schema, and full parameter descriptions, the description is complete enough. It could mention that it returns time series data but is already implied. A small gap is not explaining the 'nult' parameter behavior, but schema covers it.
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%, with both parameters already described. The description adds no additional meaning beyond the schema. Baseline of 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 tool retrieves a specific time series from INE when the exact series code is known. It distinguishes from sibling INE tools like 'ine_operacions' and 'ine_taules' which deal with operations and tables, not specific series.
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 says it is useful when the exact series code is known, providing a clear usage context. It does not mention alternatives or when not to use, but the context is clear enough.
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 are provided, so the description bears full burden. It explicitly states 'Retorna l'últim valor' (returns the last value), disclosing it provides only the most recent observation. However, no other behavioral characteristics (e.g., data freshness, rate limits) are mentioned.
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: first states the purpose, second lists the returned data. No unnecessary words, front-loaded with key information.
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?
Given zero parameters and an output schema (noted in context), the description sufficiently explains what the tool does and what data it returns. No additional details are needed for an agent to invoke it correctly.
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?
With zero parameters and 100% schema coverage (empty), the description adds value by enumerating the exact series returned (Euribor terms, ECB rate, CPI, public debt). This compensates for the lack of defined inputs, following the baseline of 4 for 0-parameter tools.
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 shows the most highlighted financial series from the Bank of Spain, listing specific series (Euribor, ECB rate, CPI, public debt). This differentiates it from sibling tools like bde_serie which likely require a series ID.
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 it is for quickly retrieving key market indicators but does not explicitly state when to use this vs. bde_serie or other financial tools. No alternatives or exclusions are mentioned.
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 the full burden. It explains that minor contracts are direct awards without publicity and lists the return fields (year, department, object, company, amount), which is informative beyond the schema.
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 plus a line of return fields. It is front-loaded with the search purpose and contains no fluff.
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?
Given the tool has 7 parameters with full schema descriptions, an output schema, and the description explains the concept and return values, it is complete for the agent to understand usage without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add parameter-level details beyond what the schema already provides. It only mentions return fields.
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 searches for minor contracts (contractes menors) of the Generalitat de Catalunya, with specific verb 'cerca' and resource 'contractes menors'. It distinguishes from siblings like 'cercar_contractes' by specifying a subtype.
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 use for minor contracts but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusion criteria or sibling differentiation 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 bears full responsibility for behavioral disclosure. It only states a read operation and gives examples. It does not mention that the operation is read-only, requires no special permissions, or any potential side effects. More detail on safety and constraints would be beneficial.
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 very concise: two sentences. The first states the primary purpose, the second provides examples and workflow context. Every sentence is informative and necessary, with no redundancy or filler.
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?
Given that an output schema exists (context signals show 'Has output schema: true'), the description does not need to explain return values. It sufficiently covers what the tool does, how to use it, and its relationship to sibling tools. The mention of 111 operations and common examples provides adequate context for agent understanding.
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 covers 100% of the single optional parameter with a clear description and examples (e.g., 'IPC', 'empleo'). The tool description adds a count of 111 operations but does not significantly enhance parameter meaning beyond the schema. Baseline 3 is appropriate given full 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 the tool lists all available INE statistical operations, with specific examples like IPC, EPA, PIB. It also explains the workflow: use this tool first to find the operation code, then use ine_taules for tables. This effectively distinguishes it from sibling tools like ine_taules.
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?
The description explicitly instructs the agent to use this tool first to find the operation code, then proceed to ine_taules. This provides clear guidance on when to use this tool and its role in the sequence of operations, differentiating it from other 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?
No annotations provided, so description carries the burden. It describes the tool as returning metadata and resource list, which is a read operation. It is transparent about output and its use with another tool. Could add more on error cases, but sufficient for a simple detail 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?
The description is two sentences, front-loaded with the main purpose, and no unnecessary words. It is efficient and 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?
Tool has output schema, so return values are covered. The description is brief but covers main functionality. Could mention that dataset_name should match results from bcn_cercar_datasets, but the parameter examples already guide this. Minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with examples provided in the parameter description. The tool description repeats that the parameter is the dataset name but adds no new meaning beyond what the schema already provides. 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 it gets full detail of a Barcelona dataset including resources, and explicitly lists the output (metadata and resource list with resource_id). This distinguishes it from siblings like bcn_cercar_datasets (search) and bcn_obtenir_dades (get data from a resource).
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 explains when to use: to get complete dataset detail and resource IDs. It explicitly links to bcn_obtenir_dades for further data retrieval. Although it doesn't state when not to use, the context from siblings implies alternatives.
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. Discloses it lists all departments but lacks details like ordering, pagination, or potential caching. Basic but adequate for a simple listing 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?
Two sentences front-loaded with the action and purpose. No extraneous words; every sentence earns its place.
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 zero parameters and presence of output schema, description is sufficient. Tells what it lists and why. Minor bonus if it mentioned sorting, but not necessary.
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?
No parameters; baseline 4. Description adds value by indicating what the tool returns (department codes and names), even though schema coverage is 100%.
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 it lists all departments in the BOE. Distinguishes from siblings (e.g., boe_contractes, boe_legislacio) which focus on other BOE content.
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 usefulness for obtaining department codes/names for filtering in other BOE queries. Provides clear usage context but no explicit 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.
Behavior3/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 lists tables and returns IDs, but does not mention error handling (e.g., invalid operation) or output structure details (though an output schema exists). Adequate for a simple read-only 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?
Two sentences with no superfluous information. The first sentence states the action, the second the outcome. Perfectly front-loaded and 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?
For a simple 1-parameter tool with an output schema, the description covers the main purpose, parameter source, and downstream usage. Could hint at empty result cases, but overall sufficient.
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 coverage is 100%, baseline 3. The description adds value by explaining the parameter's source (obtained via ine_operacions) and providing examples, which aids correct invocation beyond the schema alone.
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 lists available tables for an INE statistical operation and returns table IDs for use with ine_dades_taula. It distinguishes its role in a pipeline by referencing sibling tools (ine_operacions and ine_dades_taula).
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 implies usage after obtaining an operation code from ine_operacions and before querying data with ine_dades_taula. It provides clear context but lacks explicit when-not-to-use or alternative suggestions.
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 provided, the description carries the full burden. It details the cross-source search behavior, mentions special handling for public bodies (searching awarded contracts), and states the output is a complete report. This provides sufficient behavioral context, though it lacks specifics on error handling 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear intro, bullet-like list of sources, and a summary of behavior. It is informative without being verbose, though slightly longer than necessary. Every sentence contributes value, so it earns a 4.
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?
Given the existence of an output schema (true), the description need not detail return values; it succinctly says 'Retorna un informe complet.' It covers inputs, search behavior, and the tool's purpose comprehensively for a cross-source investigation tool in a large set of siblings.
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 baseline is 3. The description adds minimal extra meaning beyond the schema: it emphasizes 'nom' as the primary identifier and that 'cif' ensures uniqueness, and clarifies 'limit_per_font' is per data source. This adds marginal value but doesn't significantly enhance the schema's information.
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 it investigates an entity across ALL data sources, listing specific sources (contractes, subvencions, etc.) and includes special behavior for public bodies. This distinguishes it from sibling tools like cercar_contractes which are single-source, ensuring the agent understands its broad scope.
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 says 'Ideal per investigar empreses, persones o organismes sospitosos,' providing clear usage context. While it doesn't explicitly list when not to use, the contrast with sibling tools (single-source searches) implicitly guides the agent to choose this for comprehensive investigations.
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?
There are no annotations, so the description bears the burden. It discloses that the tool returns ROJ, ECLI, date, and URL per sentence. It does not mention side effects or rate limits, but the read-only nature is implied.
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 two short paragraphs. The first states purpose, the second adds context. It is efficient but could be more front-loaded.
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?
Given an output schema exists, the description does not need to explain return values, but it does mention the fields. It also provides example crimes and states the dataset source, making it complete for a search tool.
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 coverage is 100%, so baseline is 3. The description adds value by listing example search terms like corruption-related crimes, which is beyond the schema's parameter 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 specifies the resource (CENDOJ judicial decisions) and the action (search by text). It also mentions specific crime types, clearly distinguishing this tool from sibling tools that handle datasets, contracts, or other data.
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 states to search for sentences from the National Court by text and provides example use cases (corruption, embezzlement, etc.). However, it does not explicitly exclude other uses or mention alternative tools, but the context is clear.
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 provided, the description carries full burden. It explains the aggregation operation, notes that field names are internal Socrata names, and advises using another tool to list fields. It does not discuss rate limits or authentication, but is transparent about 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, uses bold for emphasis, and front-loads the purpose. It is slightly lengthy but every part adds value. Could be trimmed slightly, but overall effective.
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?
Given the complexity of the tool, the number of siblings, and the presence of an output schema, the description is comprehensive. It covers common usage patterns, provides field mappings, examples, and guidance on parameters. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds significant value beyond the schema: it explains common fields per dataset, provides examples of usage, clarifies the relationship between operacio and camp_suma, and explains the dataset parameter. This is exemplary.
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 that it generates aggregated statistics about contracts or subventions, provides specific field names and examples, and distinguishes this tool from sibling tools that focus on searching or detailing individual records.
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 clear guidance on when to use (for aggregated stats), recommends using 'llistar_camps' to check field names, and provides common fields per dataset. It does not explicitly state when not to use, but the context is clear.
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:

[![mcp-govern MCP server](https://glama.ai/mcp/servers/xavimf87/mcp-govern/badges/card.svg)](https://glama.ai/mcp/servers/xavimf87/mcp-govern)

Score Badge

Copy to your README.md:

[![mcp-govern MCP server](https://glama.ai/mcp/servers/xavimf87/mcp-govern/badges/score.svg)](https://glama.ai/mcp/servers/xavimf87/mcp-govern)

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/xavimf87/mcp-govern'

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