MCP-BOE
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation2/5
The tool set has multiple overlapping functions, such as get_law_structure and explain_law_structure, find_related_laws and list_related_laws, and several table retrieval tools that serve similar purposes. Descriptions attempt to differentiate them, but the boundaries are still unclear, making it difficult for an agent to select the correct tool confidently.
Naming Consistency5/5All tools follow a consistent snake_case verb_noun convention (e.g., get_scopes_table, search_law_articles, compare_law_versions). While verbs vary, the pattern is uniform and predictable, which greatly aids readability and selection.
Tool Count2/5With 31 tools, the count is excessive for the actual scope. Several tools could be consolidated (e.g., structure-related tools, table lookups), and the abundance adds unnecessary complexity without clear benefits.
Completeness5/5The tool set thoroughly covers the domain of BOE legislation access: searching, metadata, structure, full text retrieval, related laws, version comparison, and monitoring. There are no obvious dead ends or missing core operations for a read-only public document service.
Average 3.5/5 across 31 of 31 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- 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.jsonto 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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose behavioral traits such as read-only nature, required date format boundaries, what the summary contains, or error behavior. The description essentially only restates the tool's function without adding operational 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence conveys the core purpose without redundancy. It is front-loaded and free of unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 params, no output schema), the description is minimal but sufficient for basic invocation. However, it lacks context about what makes this weekly summary distinct from sibling summary tools, and it does not clarify the expected output format or edge cases, so completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters already have meaningful descriptions in the schema. The description adds no extra semantic weight beyond what the input schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Obtiene') and resource ('resumen semanal de publicaciones del BOE'), making the core purpose evident. However, it does not differentiate from closely named siblings like 'get_boe_summary' or 'get_boe_summary_range', so some ambiguity remains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There are no context cues, exclusions, or mentions of related sibling tools, leaving the agent to infer the use case from the name 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, so the description carries the full burden of behavioral disclosure. It only mentions the high-level function and does not reveal details such as pagination, filtering capabilities, output format, or whether it represents a read-only operation. This is insufficient for a tool with multiple configurable options.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. However, it omits any mention of the tool's configurable options (max_items, province_filter, include_pdf_links), making it slightly under-informative for the tool's actual complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, no output schema, and no annotations, the description fails to convey the tool's full capabilities. It only mentions the date-based summary, ignoring the filtering, limiting, and PDF link features that the schema documents. This leaves significant gaps for an agent deciding how to invoke the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters, including format for date, constraints for max_items, and purpose for province_filter and include_pdf_links. The description adds no additional semantic value beyond the schema, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the BORME summary for a specific date ('Obtiene el sumario del BORME para una fecha específica'), using a specific verb and resource. It differentiates from siblings like get_boe_summary_range by emphasizing a single date, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 siblings such as get_boe_summary_range, get_weekly_summary, or get_boe_summary. The description merely states what it does without indicating appropriate use cases 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 carry the disclosure burden. It only states that the tool retrieves a description; it does not mention what happens when a code is not found, whether it searches across multiple types, what the output format is, or any potential side effects. The simple verb 'obtiene' implies a read, but behavioral context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb 'Obtiene,' and contains no redundant wording. It could include more detail about code types or return values without bloating, but as written it is clean and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description alone must convey what the tool returns and how it behaves. It does not explain what the 'description' contains, how the search works without a code_type, or how this tool relates to the sibling table tools. Users are left with only a minimal high-level statement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters fully: code includes examples ('7723', '1300') and code_type has an enum with the note that it speeds up searching. Since schema coverage is 100%, the description adds no extra parameter semantics, and the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Obtiene la descripción de un código específico' (gets the description of a specific code). It identifies the resource (code description) and the operation, but it doesn't differentiate from sibling table-listing tools or specify which code domains are covered, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The schema's note that code_type 'acelera la búsqueda' hints at usage, but the description itself offers no when/when-not or alternative tool references, leaving the selection process to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention that full text is optional or that include_analysis and include_eli_metadata exist. It also fails to state that output may be very large. The description carries minimal behavioral burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core purpose without waste. It is appropriately sized and front-loaded, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and no output schema, the description is too sparse. It does not explain return value behavior, relationship to the many sibling tools, or the conditions under which this tool should be preferred.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 no additional parameter semantics beyond what the schema already provides. All parameters are clearly described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Obtiene') and resource ('norma consolidada específica'), indicating that the tool retrieves full text and metadata. It distinguishes from siblings like get_law_metadata (metadata only) and get_law_text_block (specific text blocks). However, the claim of 'texto completo' may overpromise since include_full_text defaults to false.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 lacks any mention of alternatives or contextual usage, leaving the agent to infer from the tool name 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool obtains a table, omitting details like default filtering (active_only defaults to true), whether search filtering is applied, pagination, ordering, or return format. This is minimal transparency for a tool with two optional parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core function. It contains no filler, but its brevity leaves out critical context, making it more under-specified than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a table retrieval tool with no output schema and no annotations, the description is incomplete. It fails to explain what legal ranges are, how the filters affect results, or what the table contains, leaving the agent without enough context to predict behavior or interpret returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters fully (active_only: 'Mostrar solo rangos activos'; search_term: 'Término de búsqueda para filtrar rangos por nombre'), so the baseline is 3. The description adds no additional parameter meaning beyond what's already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a table of regulatory ranges (Ley, Real Decreto, etc.), using a specific verb ('Obtiene') and naming the resource. It distinguishes itself from sibling table tools by focusing on legal ranges rather than matters, departments, or consolidation states, though it doesn't explicitly call out alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description simply states what it does without presenting context, prerequisites, or exclusion criteria, leaving the agent to infer appropriate usage.
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 responsibility for behavioral disclosure. It only says 'search specific information' without explaining match behavior (exact vs. fuzzy), result limits, whether it searches across all table types by default, or any permissions/rate constraints. This is a significant gap for a 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets to the point without unnecessary words. However, its brevity sacrifices useful detail; it could still be concise while adding valuable context about the search scope or behavior. The front-loading is acceptable as the core action is stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (two params, one enum, no output schema, no annotations), the description is inadequate. It fails to explain what 'auxiliary tables' are, how the search behaves, what the default table_type is, or what kind of results to expect. Sibling tools provide context, but the description itself is too thin to be fully useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for both parameters ('query' and 'table_type'), so the baseline is 3. The description adds no additional semantic value; it simply restates that information is being searched without elaborating on parameter usage or the meaning of the table_type enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('search') and resource ('auxiliary tables'), which indicates a general search capability across a defined set of internal tables. It is somewhat clear from the sibling tools and the schema enum that this refers to tables like departments, ranges, matters, scopes, and states, though 'auxiliary tables' alone could be ambiguous without that 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus sibling tools like get_scopes_table or search_departments_advanced. It does not mention situations where this generic search is preferable or when a more specific table accessor should be used.
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 of behavioral disclosure. 'Obtiene' implies a read operation, but the description does not disclose return format, pagination behavior, default filtering from active_only, or any potential side effects. This is minimal for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded with the verb and resource, and every word adds meaning. Under-specification is handled in other dimensions, not here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema fully documents parameters, but the description lacks any mention of return shape or usage context. There is no output schema, and the description says only 'gets the table', which is somewhat thin for an agent to know what to expect or when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with clear explanations for limit, active_only, and search_term. The description itself adds no extra semantics beyond the fact that the table is of official department codes, so the baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Obtiene') and identifies the resource ('tabla de códigos de departamentos oficiales'). It is clear it retrieves the official department codes table, and this distinguishes it from sibling table getters like get_matters_table or get_scopes_table. However, it does not explicitly contrast with the similar search_departments_advanced tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as search_departments_advanced or other get_*_table tools. There is no mention of context, prerequisites, or exclusions, so the agent gets no decision support from the description.
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 responsibility for behavioral disclosure. It does not mention side effects, permissions, return format, pagination, or whether the result is a simple index or full text structure. Beyond stating it 'obtiene' (gets), it gives no behavioral details. This is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete sentence that front-loads the primary verb and object. It is concise, with no superfluous information, and every word contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (one parameter, no output schema) and the absence of annotations, the description provides a minimum viable explanation. It identifies what is returned (index/structure) but lacks details about the structure of the output or any limitations. More context would improve completeness, but it is adequate for a straightforward retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter 'law_id', including a pattern and description, so the description does not need to add parameter semantics. However, the description also does not reinforce the connection between the parameter and the structure retrieval, but the baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves the index/structure of a legal norm, with examples ('títulos de artículos, disposiciones'). It uses a specific verb ('Obtiene') and resource ('norma'), but does not explicitly distinguish it from the similar sibling 'explain_law_structure' (which likely explains rather than retrieves). Thus it is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description only states what it does, without mentioning contexts, exclusions, or relationship to siblings like 'get_law_text_block' or 'explain_law_structure'. No usage conditions or recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'obtiene' (gets), which implies a read operation, but it does not disclose return format, error behavior, side effects, or authentication needs. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb, and contains no unnecessary words. It effectively communicates the core purpose in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 params, no output schema), the description is adequate for the basic purpose, but it lacks details about the output format and does not clarify how it differs from related tools like paginate_law_text. This leaves some ambiguity for an agent selecting among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters fully with descriptions and examples for block_id. The tool description adds no additional parameter context beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving a specific text block from a legal norm, with examples (article, provision). It uses a specific verb ('Obtiene') and resource, but does not explicitly differentiate it from sibling tools like get_law_structure or paginate_law_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any preconditions or exclusions. It simply states what the tool does, leaving the agent to infer usage context from the name and siblings.
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 of behavioral disclosure. It only mentions 'search', which implies a read-only operation, but lacks details on pagination behavior, search semantics, result format, or any limitations. This is insufficient for a search tool with 10 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the key action and resource. It is not verbose, and every word is functionally relevant. However, its brevity limits the amount of information conveyed, though this is more a completeness issue than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is notably incomplete for a tool with 10 parameters, no output schema, and no annotations. It fails to explain how parameters interact, what return values look like, or any edge cases. The one-sentence description is insufficient to fully understand the tool's behavior and expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already fully documents all 10 parameters with descriptions. The tool description itself adds no parameter-specific meaning, but since the schema is comprehensive, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for norms in the consolidated legislation of the BOE, specifying both the verb ('Busca') and the resource ('legislación consolidada del BOE'). This distinguishes it from sibling search tools like search_recent_boe or search_auxiliary_data by focusing specifically on consolidated legislation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 exclusions or prerequisites. It simply states what the tool does, leaving the user to infer usage context.
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 of behavioral transparency. It only states that the tool obtains a summary, without disclosing return format, pagination behavior, handling of unavailable dates, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy or filler. Every word earns its place, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters, no output schema, and no annotations, a one-line description is insufficient. It does not explain what the summary contains, how filters like section_filter or department_filter affect the result, or what the agent should expect in the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 no significant parameter semantics beyond the schema; the mention of 'fecha específica' only reinforces the date parameter documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Obtiene' and the resource 'sumario del BOE', with 'para una fecha específica' clearly scoping it to a single date. This distinguishes it from sibling tools like get_boe_summary_range and get_weekly_summary, which cover ranges or weekly summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 get_boe_summary_range, get_weekly_summary, or get_borme_summary. There are no exclusions, prerequisites, or context cues to help an agent choose correctly.
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 of behavioral disclosure. However, it only mentions the search action and relation types, omitting any information about return format, pagination, read-only nature, or error conditions. This is insufficient without structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action ('Encuentra') and efficiently adds key detail in parentheses. Every word contributes value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple interface (2 parameters), but the lack of an output schema and annotations means the description should clarify the expected return value. It gives the purpose but not the result structure or any qualifiers, which is adequate for a basic tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptive comments for both parameters: law_id (with pattern) and relation_type (with enum values). The schema coverage is 100%, so the description adds no extra parameter semantics, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Encuentra' (finds) and clearly specifies the resource 'leyes relacionadas' while adding a parenthetical that narrows the meaning to normative relations (modify, repeal, or modified by). This differentiates it from the sibling tool 'list_related_laws' by focusing on specific legal relationships rather than a generic list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, such as 'list_related_laws'. It only states what the tool does without offering contextual cues, exclusions, or references to sibling 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states a simple retrieval action without mentioning whether the operation is read-only, what the response contains, or if there are any side effects or prerequisites. This is a significant gap for a tool with no structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. It is efficient and to the point, though it lacks any structural elaboration. The brevity is appropriate for a simple getter, but it borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and no annotations, the description is the only context an agent has. It does not explain what 'consolidation states' are, why an agent would need them, or how the table relates to the law domain. This is insufficient for an agent to confidently select and invoke the tool, especially given the many sibling table tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. The baseline for 0-parameter tools is 4, and the description does not need to elaborate on parameter details since none exist. It adds no parameter semantics, but none are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Obtiene') and resource ('la tabla de estados de consolidación'), clearly distinguishing it from sibling table retrieval tools like get_scopes_table and get_departments_table. The resource name is explicit, leaving no ambiguity about what the tool fetches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Sibling tools such as get_scopes_table and get_matters_table exist, but the description does not differentiate usage scenarios or mention any prerequisites 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the tool gets a table, but does not mention whether it is read-only, any side effects, authentication needs, or what the returned table contains. The verb 'obtiene' implies a read operation, but no further 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the core purpose without any fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple table retrieval with two optional parameters and no output schema, the description is minimally adequate but lacks detail about the returned table structure, pagination behavior, or any additional context. It does not mislead, but it also does not provide extra helpful information beyond the tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'limit' and 'search_term' documented in the input schema. The description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the table of matters/topics from the controlled vocabulary. It uses a specific verb ('obtiene') and resource ('tabla de materias/temáticas'), distinguishing it from sibling tools like 'get_scopes_table' and 'get_departments_table'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool compared to alternatives, nor does it mention any exclusions or context about when to prefer other table retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool searches for documents, without mentioning whether the operation is read-only, what it returns, or any limitations. The lack of detail about side effects or response format leaves an agent unprepared for invoking the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words or filler. It conveys the essential function immediately and is appropriately concise for a straightforward search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having full parameter documentation, the description lacks information about the output format or search behavior. Since there is no output schema and no annotations, the description should at least hint at the expected return value or any usage constraints, but it does not. This makes it minimally viable but incomplete for an agent encountering this tool for the first time.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have detailed descriptions in the input schema (100% coverage), so the baseline is 3. The description itself does not elaborate on any parameters beyond what the schema already provides, offering no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'busca' (searches) with the resource 'documentos en el BOE' (BOE documents) and the scope 'últimos días' (recent days). This clearly states the tool's function and differentiates it from sibling search tools that target other data sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for searching BOE documents from a recent time window, but does not provide explicit guidance on when to use it over alternatives such as search_auxiliary_data or search_consolidated_legislation. No exclusions or alternative recommendations are offered, so usage context is only implied.
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?
There are no annotations, so the description must carry the full burden of explaining behavior. It only says the tool 'sugiere' (suggests) codes, which implies a read-only, non-destructive operation, but it does not disclose output format, pagination, or any other behavioral traits. The agent is left without enough detail to predict what the tool returns or how it might behave.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that front-load the main action and then give a practical usage note. There is no fluff or redundant information, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain what the tool returns and any relevant limitations. It only gives a high-level purpose and a usage hint, but does not describe the output format or any caveats. For an agent to correctly invoke and use the results, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both 'query' and 'max_suggestions' have descriptions in the input schema. The description adds no extra parameter-level meaning; it only mentions the types of codes suggested, which is not directly about parameters. This meets the baseline for high coverage but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: given free text, it suggests department codes, subject codes, and regulatory ranges for use as filters. It uses a specific verb ('suggests') and names the resource types, making the purpose clear. However, it does not explicitly contrast with similar sibling tools like search_auxiliary_data, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Útil para descubrir los códigos correctos antes de una búsqueda de legislación' (useful for discovering correct codes before a legislation search). This tells the agent when to use the tool, but it does not mention alternatives or exclusions, so a 4 is 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?
With no annotations, the description carries the full burden of behavioral disclosure. 'Obtiene' implies a read-only operation, but the description does not state whether it requires authentication, returns a specific format, or has any side effects. For a simple table retrieval, this is minimal but still misses an explicit statement of non-mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource, and every word contributes meaning. There is no wasted text or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema), the description is adequate but minimal. It explains the purpose but does not detail the return structure or any potential edge cases. For a zero-parameter table getter, this is sufficient to invoke the tool, but lacks richness compared to the best examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The description adds value by stating what the table contains (scopes), which is not evident from the empty schema. The baseline for 0 params is 4, and the description meets it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Obtiene' (Gets) and the resource 'la tabla de ámbitos' (the scopes table), with a clarifying parenthetical '(estatal, autonómico)' that distinguishes it from sibling table tools like get_matters_table and get_legal_ranges_table. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any conditions, exclusions, or comparisons with the many sibling table tools, leaving the agent to infer usage from the name 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, so the description must carry the full burden of behavioral disclosure. It mentions the granular control over relation types, but that is already visible in the schema. It does not state whether the operation is read-only, whether it has rate limits or permissions, or what the output structure looks like. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise, front-loaded sentences that state the core action first, then add the key differentiator (more filtering options) and specific relation types. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a list tool: it explains the main purpose and names the sibling alternative. However, with no output schema and no annotations, it lacks details about the return format, pagination, possible empty results, or any prerequisites. The description is clear enough for basic invocation but leaves out behavior and output specifics that an agent might need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all parameters, so the baseline is 3. The description adds a high-level summary ('control granular sobre qué tipos de relaciones incluir') and explicitly mentions the relation types (derogaciones, desarrollo reglamentario, referencias genéricas), which reinforces the boolean parameters. However, it does not add new meaning 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lista') and resource ('las normas relacionadas'), and clearly distinguishes this tool from the sibling find_related_laws by stating it 'Complementa a find_related_laws con más opciones de filtrado'. The granular control over relation types is explicitly mentioned, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the alternative find_related_laws and explains the differentiating factor (more filtering options). This implies when to use this tool (when granular relation-type filtering is needed) versus the simpler alternative, though it does not provide explicit 'when not to use' guidance.
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 the core behavior (keyword search with configurable lookback) but omits details like result format, pagination, or that it's read-only. Some important behaviors are missing, so score 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, first states function, second gives use case. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and schema covers parameters, but there's no output schema and description doesn't clarify return values or differentiate from sibling search tools. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 4 parameters, so baseline is 3. The description doesn't add parameter-level semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Busca') with a clear resource ('publicaciones recientes del BOE') and scope (keywords + configurable days back). However, it doesn't explicitly differentiate from sibling search tools like search_recent_boe, so it's not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context for when to use it: as a 'radar normativo' for monitoring topics of interest. It doesn't mention alternatives or exclusions, but the use case is clear.
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 mentions the grouping and output type but omits a key behavioral trait: the max_items_per_dept parameter limits how many dispositions are shown per department (default 10), so the description's promise of showing 'cuáles disposiciones' may be misleading. It also does not disclose whether sections filter affects results or any edge-case 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly communicates the tool's core function and output. There is no wasted verbiage, and every clause contributes meaningfully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 params, no output schema), the description adequately explains the return value (grouped dispositions with counts). However, it omits the max_items_per_dept limit and section filtering behavior, which are important for setting expectations. Still, the schema covers parameter details, and the description covers the main output shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description adds context by explaining the grouping and the output (counts and dispositions), but it does not elaborate on parameter-specific formats or the effect of sections or max_items_per_dept beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool obtains a BOE summary for a date range and groups publications by issuing department, showing counts and specific dispositions. This specific verb+resource+grouping clearly distinguishes it from siblings like get_boe_summary_range and get_weekly_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it: when a BOE summary grouped by department over a date range is needed. It does not explicitly mention alternatives or exclusions, but the purpose is specific enough to guide selection among the many summary-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It explains the cursor-based pagination mechanism ('Usa el cursor devuelto en next_cursor' ), which is useful, but it does not disclose other behavioral aspects like error handling, ordering guarantees, or what happens at the end of the text. This 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the core purpose, followed by the value proposition and the key cursor usage instruction. Every sentence warrants its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and no output schema, the description sufficiently explains the pagination flow and how to request subsequent fragments. It does not describe the response format in detail, but the cursor reference provides the essential behavior needed for the intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover all three parameters (cursor, law_id, max_chars), so the baseline is 3. The description adds only a small semantic link by referencing next_cursor in the response, but it does not meaningfully enrich parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns legal text in manageable fragments ('Devuelve el texto de una norma en fragmentos manejables'), giving a specific verb, resource, and scope. It does not explicitly differentiate from sibling tools like get_law_text_block, so it misses the full distinction required for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear usage context: it allows the LLM to read long norms piece by piece without loading them entirely, implying use for long texts. However, it does not explicitly mention alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of transparency. It discloses that the tool accepts various formats and returns the type, normalized identifier, and other extracted fields, which is useful. However, it does not mention error handling, unrecognized references, or any limitations, leaving gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that front-load the main action in the first sentence and provide examples and output in the second. Every word earns its place, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple interface with one parameter and no output schema, so the description must explain return values. It does mention the type and normalized identifier, but the phrase 'otros campos extraídos' is vague and doesn't enumerate all possible outputs or error behavior. This leaves an agent uncertain about the full response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage for the single parameter with a basic description. The tool's description adds significant value by listing concrete examples ('Ley 40/2015', 'Real Decreto 123/2020') and indicating that the parameter accepts free text in multiple formats, going beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts free-form legal references into a normalized form, with a specific verb ('Convierte') and resource ('referencia libre a una norma o BOE'). It provides examples of accepted inputs and output fields, distinguishing it from sibling tools that operate on structured data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a free-text reference needs normalization, but does not explicitly state when to prefer this tool over alternatives or mention any exclusions. The examples help, but there is no explicit 'use this when' guidance, so it falls at the baseline of implied usage.
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 burden. It discloses the return behavior (only matching articles with a relevant fragment) but does not explicitly state that the operation is read-only or mention any side effects. It adds some behavioral detail but not exhaustive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the primary purpose and immediately clarifying the output scope. No filler, every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the description gives a basic idea of the return value (matching articles with a fragment), it lacks detail on the exact response format (e.g., fields, ordering, or how the fragment is chosen). Since there is no output schema, the description should compensate but only partially does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the tool description adds no extra meaning for parameters like law_id, query, limit, or search_in. It stays at the baseline expected when structured data already documents all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: searching for articles within a law that contain a given text, and explicitly contrasts with returning the entire law. It distinguishes itself from sibling tools like get_law_structure or paginate_law_text by focusing on text-based article search and filtered output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case: when an agent needs to find specific articles containing a text without fetching the whole law. It does not explicitly name alternatives or exclusions, but the context is unmistakable.
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 discloses the core behavior (compares text and detects changes) but does not mention authentication, side effects, rate limits, or output format details. For a read-only comparison tool, the main behavior is clear, but some safety or constraint information is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action, and contains no redundant information. Every word contributes to understanding the tool's purpose and use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (all documented in schema) and no output schema, the description sufficiently explains the core function and intended use. It implies that the output consists of detected changes, which is useful for an agent to know how to handle results. The lack of output schema details is acceptable because the description conveys the key outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters, so the baseline is 3. The description does not add parameter-specific semantics beyond what the schema already provides; it only gives general context about comparing versions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Compara el texto de una norma entre dos fechas de consolidación distintas') and the resource, distinguishing itself from sibling tools that fetch single versions or structure. It also specifies what is detected (articles added, modified, or deleted), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Útil para entender qué cambió en una norma a lo largo del tiempo' provides clear context for when to use this tool (comparing versions to understand changes). However, it does not explicitly mention alternatives or when not to use it, so it lacks explicit 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?
With no annotations, the description must disclose behavior itself. It specifies the output fields and compact nature, but doesn't mention error handling, permissions, or any edge cases. Since it's a simple read operation, this 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are used efficiently: the first states the return value and structure, the second provides a comparison and use case. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's output structure and use case, and the single parameter is fully described in the schema. It doesn't specify output format or error conditions, but for a summary tool this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a full description of law_id with pattern and meaning, so baseline is 3. The tool description doesn't add any additional parameter information beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a compact structural summary of a norm, listing levels with type, id, title, and direct child count. It also distinguishes itself from get_law_structure by being more concise, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names get_law_structure as a more detailed alternative and suggests this tool is ideal for quickly understanding organization. However, it doesn't explicitly state when NOT to use it, though the contrast implies a trade-off.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does state what the tool returns (subjects/topics from a controlled vocabulary) but does not mention any side effects, permission requirements, rate limits, or edge cases. This is adequate for a simple read-only tool, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, with the primary action in the first sentence and a practical use case in the second. Every word contributes value, and it is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description adequately explains the purpose, the input, and the practical benefit. It does not detail the output format, but given the tool's simplicity and the lack of an output schema, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the only parameter (law_id), and the schema already includes a regex pattern and example. The description adds no additional parameter-level details beyond confirming the parameter is a law identifier. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: returning controlled-vocabulary subjects/topics associated with a specific norm (law). The verb 'Devuelve' and resource 'materias/temas... asociados a una norma' make the purpose specific and distinguish it from sibling tools like get_matters_table which likely returns the full table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: 'Útil para entender la temática de una ley y encontrar filtros para búsquedas relacionadas.' This provides clear use cases but does not mention when not to use it or name alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It mentions pagination and hierarchy exploration but does not disclose default filters like active_only, sorting, or return format. The search is clearly read-only but no explicit safety cues are 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every phrase earns its place without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description covers the key features and differentiation from a sibling tool. It doesn't mention return format or defaults, but these are partially covered by the schema; overall it's adequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so descriptions already document each parameter. The description adds overall context by naming the filter types but does not provide additional detail beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs an advanced search of departments with specific additional filters (parent code, text, pagination), and explicitly distinguishes it from get_departments_table by noting it complements that tool with more filtering options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the alternative tool (get_departments_table) and indicates this tool provides additional filtering options, giving clear context for when to choose it. However, it doesn't explicitly state exclusions or specific scenarios beyond that.
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 discloses that it builds URLs automatically and handles both PDF URLs and identifiers. However, it overpromises 'texto COMPLETO' without mentioning the max_pages limit (default 30) or potential truncation for long documents, which is a significant behavioral limitation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, front-loaded with the main purpose, and packed with useful details (types of documents, usage triggers, input formats, exclusivity). No filler, though it is slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage triggers, input formats, and differentiation from siblings. However, it lacks information about output behavior, potential pagination/truncation issues, and error conditions. Given the tool's moderate complexity and no output schema, it is fairly complete but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), but the description adds meaningful detail for the 'source' parameter: acceptable formats (URL or BOE identifier), automatic URL construction, and a concrete example. This goes beyond the schema's description, warranting a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads and extracts the complete text of BOE documents, listing specific document types. It also explicitly distinguishes itself as the only tool for non-consolidated documents, differentiating it from siblings like get_consolidated_law.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage triggers (when the user asks for 'más detalles', 'el contenido', etc.) and explains input formats. It implies alternatives by noting it is the only tool for non-consolidated texts, but does not explicitly state when to prefer other 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?
With no annotations provided, the description carries the full burden. It adds the 31-day range limit and mentions aggregation behavior, which is useful. However, it does not disclose output format, pagination, possible errors, or whether it is read-only. This is moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no fluff. It front-loads the purpose and immediately follows with usage guidance and constraints. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must cover more ground. It explains the main purpose, when to use it, and a key constraint, but it does not describe the return structure or how aggregation affects results. For a moderate-complexity tool with 4 parameters, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 the valuable constraint of a maximum 31-day range, which is not present in the schema's parameter descriptions. It does not elaborate on section or max_items, but the added date-range constraint justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'obtiene y agrega los sumarios del BOE para un rango de fechas' clearly stating it gets and aggregates BOE summaries for a date range. It distinguishes itself from sibling get_boe_summary by explicitly mentioning it avoids day-by-day calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'Permite ver todas las publicaciones de un período sin llamar a get_boe_summary día por día', naming the alternative tool and giving a clear use case. It also provides the constraint of a maximum 31-day range.
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?
Sin anotaciones, la descripción asume el rol de explicar el comportamiento: dice que devuelve un esqueleto 'sin texto completo', delimitando el alcance de la respuesta. No describe efectos secundarios ni requisitos, pero al ser una operación de consulta es suficiente.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
La descripción es breve, de dos oraciones, y está front-loaded: la primera oración define claramente el resultado y la segunda el caso de uso. No contiene información redundante.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Aunque no hay output schema, la descripción explica la estructura de retorno (lista de bloques, títulos, primer párrafo) y su limitación (sin texto completo). Para un resumen de secciones con un solo parámetro, es completa y suficiente.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
El esquema cubre el 100% del parámetro law_id con descripción y patrón; la descripción no añade detalles adicionales sobre el parámetro, por lo que se mantiene la línea base.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
La descripción especifica el verbo 'Devuelve' y el recurso 'esqueleto de la norma', detallando la composición (bloques con título y primer párrafo), lo que distingue claramente su propósito de herramientas como get_law_text_block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Indica el contexto de uso: 'para obtener una visión rápida del contenido antes de profundizar', lo que orienta cuándo elegir esta herramienta sobre otras de lectura completa. Sin embargo, no menciona explícitamente alternativas ni exclusiones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses a key behavioral trait: it does not load the full text, and it is faster than get_consolidated_law. This adds meaningful context beyond the name, though it does not cover error conditions or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences, front-loaded with the primary purpose and immediately followed by the usage context. Every word earns its place; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description covers purpose, scope, and performance characteristics. It could mention return format in more detail, but the listed metadata fields and explicit exclusion of full text provide adequate context for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the sole parameter law_id with a pattern and example (100% coverage). The description adds no new semantics about the parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Obtiene') and resource ('los metadatos de una norma'), enumerating the exact metadata fields. It explicitly contrasts with the sibling tool get_consolidated_law, making the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this tool: 'cuando solo se necesita información descriptiva' (when only descriptive info is needed), and implicitly when not to use it (when full text is required). It names the alternative (get_consolidated_law) and highlights the speed advantage.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/ComputingVictor/MCP-BOE'
If you have feedback or need assistance with the MCP directory API, please join our Discord server