ensmcp

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool has a clearly distinct purpose: listing categories, listing/filtering measures, retrieving one measure, searching, computing applicability, computing audit scope, raw audit questions, article checks, evidence requests, and data freshness. The closely related declaracion_aplicabilidad and alcance_auditoria are differentiated by their return content (levels vs. verification requirements). No two tools overlap enough to cause misselection.
Naming Consistency2/5
Naming is inconsistent: the first four tools use English verb_noun patterns (list_, get_, search_), while the rest are Spanish noun phrases (declaracion_aplicabilidad, alcance_auditoria, requisitos_auditoria, etc.) with varying structure. This mixed-language, mixed-pattern approach lacks a predictable convention.
Tool Count5/5
With 10 tools, the server is well-scoped for its domain of ENS security framework legislation and auditing. Each tool covers a distinct aspect of the data model, and the count feels neither sparse nor bloated for the service's purpose.
Completeness4/5
The tool surface covers the core lifecycle: exploration (list/get/search), applicability computation, audit scope generation, raw requirement queries, article checks, and evidence listing. One minor gap is the lack of a separate tool to fetch refuerzos directly, though that data is embedded in get_measure and declaracion_aplicabilidad. Overall, no critical dead ends for typical audit workflow.
Average 3.9/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- Last stable release on August 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, and the description's 'Devuelve' is consistent with those — no contradiction. Beyond annotations, the description adds valuable behavioral context: accepted dimension values ('bajo'/'medio'/'alto', with 'basico' tolerated for compatibility), the rule that at least one dimension must be valued, omission when a dimension is not valued, the category being the highest level, and the semantics of `alternative: true` reinforcements (only one needed). This meaningfully exceeds what the annotations signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the purpose in the first line and uses line breaks to separate the recurrence of the input rules, output contract, and alternative-reinforcement semantics. Each sentence earns its place; there is minimal filler. The phrasing 'se omite si el sistema no la valora' is slightly unwieldy but not bloated. It is efficient for the amount of rule context it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters and 0% schema coverage, the description covers the core dimension semantics and the output shape (category, required measures, reinforcement levels, alternative behavior), and an output schema exists to reduce the return-value burden. However, it does not address pagination (limit/cursor), the behavior or filtering effect of measure_codes, the meaning of compact, or what include_norm_text toggles. These gaps leave an agent uncertain about controlling output scope for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It usefully explains the five dimension parameters (integridad, autenticidad, trazabilidad, disponibilidad, confidencialidad) by specifying their value vocabulary and rules. However, the remaining five parameters — limit, cursor, compact, measure_codes, and include_norm_text — are left unexplained beyond their names; measure_codes as an output filter and compact/include_norm_text as format controls are not described. The compensation for the schema gap is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific function: compute measures and reinforcements required of a system for its DdA (Declaración de Aplicabilidad), returning the system category and per-measure required levels. The verb 'Devuelve' plus the resource (system applicability) makes the purpose understandable. It does not explicitly name a sibling to distinguish from, but the computation-based nature is evidently distinct from listing tools like list_measures and search_measures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case — querying required measures for a system given its dimension security levels — but gives no explicit when-to-use vs alternatives, no exclusions, and no mention of sibling tools (list_measures, get_measure, search_measures, snapshot_status). An agent must infer that this tool aggregates applicability from dimension levels rather than listing static measures. There is no 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true, idempotentHint=true and openWorldHint=false, which the description does not contradict. Beyond that, the description adds real behavioral value: it discloses that an invalid category_code is an error, that an empty result can only mean an invalid category (since every Annex II category has measures), and that level accepts 'basico' as a compatibility alias.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition front-loads the one-line purpose before the parameter breakdown, and each parameter note earns its place with concrete values and examples. It is somewhat long for a listing tool, but the organization is logical and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 0% schema coverage, and an output schema that covers return values, the description explains the three filtering dimensions in depth but omits the pagination and output-format controls. An agent calling with limit/cursor would have no documentation of how pagination behaves, which is a meaningful gap for a list tool with plausible large result sets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, and it does well for three of seven parameters: category_code gets concrete examples ('mp.if' or 'mp') plus error semantics, dimension gets all five allowed values, and level gets its values plus the 'basico' alias. But limit, cursor, compact and include_norm_text are left unexplained; their names are partially self-evident but the pagination semantics (limit units, cursor mechanics) are not documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Lista medidas de seguridad con filtros opcionales' states a specific verb (listar), a concrete resource (seguridad/security measures), and the filtering behavior, which lets an agent tell it apart from list_categories and get_measure. It doesn't explicitly contrast with search_measures, so it falls just short of full 5 differentiation, but the core purpose is 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus its siblings search_measures or get_measure, and states no exclusions. The filter parameter notes imply a use case (filtered listing), but nothing tells an agent why to choose list_measures over search_measures when a broad or fuzzy search is needed.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only safety profile is covered. The description adds genuine behavioral context beyond annotations: it explains the live_check state machine (pending/unchanged/updated/unavailable) and the failure behavior of 'unavailable' (no Chrome, no display, no network — keeps serving the snapshot). This non-obvious 'fallback to stale data' behavior is exactly the kind of transparency that helps 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the one-line purpose statement followed by a structured field-by-field breakdown. Each field earns its place by explaining possible values and conditions (e.g., when guia_808 appears). Slightly verbose but well organized; the bullet-style per-field formatting makes it scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool, the description is largely complete: it documents all three response fields, their value spaces, and edge cases. The main gap is the absence of a 'when to use this' note connecting it to the sibling content tools, which would round out the context. The output schema covers return-value structure, so the absence of explicit return-format detail is not a penalty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4 and the description correctly focuses on the response fields (captured_at, live_check, guia_808) instead of parameters. It adds semantic meaning by enumerating the possible live_check values and their meanings, and clarifying that guia_808 appears only when the guide is loaded. The output schema exists, but the description enriches what those fields represent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line 'Origen y frescura de los datos servidos' (origin and freshness of served data) states the purpose clearly, and the field-by-field explanation of captured_at and live_check makes it evident this is a status/metadata inspection tool. It distinguishes well from the content siblings (list_categories, get_measure, search_measures, etc.) which operate on data rather than on the freshness/origin of what's being served.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It never mentions that this should be checked before trusting data, nor does it exclude any scenarios or reference sibling tools. Given the sibling set contains audit/data tools that depend on this same underlying data, explicit usage context (e.g., 'check this before interpreting requisitos_articulos') would significantly help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to repeat that. It adds useful behavioral detail: it searches specific named fields and ignores case and accents. This goes beyond the annotations and helps the agent predict search behavior without over-explaining. A minor gap is the lack of any mention of result ordering or pagination, but given the annotation coverage, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. It uses two short paragraphs, the first stating the action, the second detailing the fields and the case-insensitivity. There is no fluff, though slightly more structure (e.g., separating the parameter notes) would improve readability. Still, it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the search scope and case handling, which covers the core behavior. However, it omits any explanation of the optional parameters (limit, cursor, compact, include_norm_text) and does not mention pagination behavior. Given that an output schema exists, return values are not needed, but the parameter semantics are an important gap. Overall, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate by explaining parameters. However, it only implicitly covers `query` and never mentions `limit`, `cursor`, `compact`, or `include_norm_text`. The agent may not know what `compact` does or whether `include_norm_text` affects the search scope. This is a significant gap for a tool with five parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Busca' = search) and resource ('medidas' = measures), and enumerates the specific fields searched (code, title, description, norm_text, text). This clearly distinguishes it from sibling tools like list_measures (which lists) and get_measure (which retrieves a single record). The purpose is unambiguous and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. The use case is implied by the verb 'search' and the field list, but there is no direct guidance on when to choose this over list_measures or get_measure. It is adequate but relies on inference.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only, non-mutating safety profile is covered — and the description is consistent with it (no contradiction). The description adds value by explaining the documentary/governance nature of the checks and citing the source (CCN-STIC 808 §6.1). However, it discloses nothing about response behavior, pagination, or filtering; the fact that an output schema exists lowers the burden, keeping this at a solid 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, then builds context across three short paragraphs. Every sentence contributes something (scope, the audit-half distinction, evidence meaning, source attribution). It is slightly more verbose than strictly necessary for a zero-parameter tool, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only tool with an output schema and safety annotations, the description covers the essential ground: what the tool checks, how it splits from the Anexo II audit, what `evidence` refers to, and the governing source standard. The main remaining gap is not explicitly tying this tool to its sibling requisitos_auditoria / evidencias_auditoria, but that is a minor omission for a passive, parameterless tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and the schema coverage is trivially 100% (empty properties object), so there is nothing for the description to document. Per the rubric, 0 params warrants a baseline of 4. The description appropriately spends no time on parameter syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource ('articulado del RD 311/2022') and a specific kind of operation ('Comprobaciones de auditoría'). It distinguishes its scope from the Anexo II half of the audit, which separates it from related tools. However, it never explicitly names a sibling tool, so an agent must infer the differentiation from the 'esta es esa mitad' framing rather than being told which tool does the other half.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives solid contextual guidance: it explains that an audit verifies both the articles and Annex II, positions this tool as one half, and notes this is where the auditor typically starts ('por las que suele empezar el auditor'). It also clarifies the evidence concept. But it stops short of explicit when-to-use/when-not-to-use instructions or naming alternatives like requisitos_auditoria or evidencias_auditoria.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds genuine behavioral context beyond that: the category-based accumulation rules (Básica applies to all, Media to MEDIA/ALTA, Alta only to ALTA, CCN-STIC 808 §5), the meaning of `nivel_madurez_requerido`, and the `essential` flag semantics. This enriches what the raw annotations convey. No contradiction with annotations — the compute/read behavior described matches readOnlyHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, input contract, accumulation rules, maturity levels, and the `essential` flag semantics. It is front-loaded with the purpose statement and organized in logical paragraphs. It is somewhat long and technical (CCN-STIC references, CMM level names), but the complexity of the domain justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (so return values need not be spelled out) and 12 parameters, the description covers the core semantics thoroughly: dimension inputs, accumulation behavior, maturity requirements, and essential flags. The only real gap is the output-formatting/pagination parameters (limit, cursor, compact, include_*) left unexplained, but those are largely self-evident from their names. It is complete enough for an agent to call the tool correctly for its primary purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. It does map the key semantic inputs — the dimension levels (integridad, autenticidad, disponibilidad, confidencialidad, trazabilidad) and their 'omitted if not valued' behavior — and explains output fields like `nivel_madurez_requerido` and `essential`. However, it never mentions `limit`, `cursor`, `compact`, `include_evidence`, `include_norm_text`, or `include_questions`, leaving 6 of 12 parameters undocumented in both schema and description. It compensates only partially for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line states a specific purpose — the audit syllabus of a system, i.e., what will be asked — and the description makes clear it returns applicable measures with their accumulated verification requirements. It provides a concrete resource and verb. However, it does not differentiate itself from close siblings like `requisitos_auditoria` or `evidencias_auditoria`, which an agent could easily confuse with this tool, so it stops 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit calling context: takes the same arguments as `declaracion_aplicabilidad` (dimension level per dimension, or omitted if not valued), explaining the input semantics needed to invoke it correctly. It also states the accumulation logic clearly. It does not, however, state when NOT to use this tool versus its siblings, so the guidance is strong on how but weaker on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds minimal context about the category examples, but does not disclose other behavioral traits (e.g., return format, pagination, errors). Since annotations cover the key behavioral aspects, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets straight to the purpose with no filler. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema present, the description is complete. It clearly states what the tool lists and provides examples, leaving no ambiguity for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers this aspect. The baseline for 0 params is 4, and the description adds nothing beyond the schema, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all categories of Annex II, with specific examples (org, op.pl, mp.if). It uses an explicit verb (list) and resource (categories), distinguishing it from sibling tools focused on measures or other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It only describes what it does, without mentioning exclusions or alternative tools. The purpose is clear, but there is no explicit context for selection.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds beyond annotations: the error behavior for a non-Annex II code, the join key (measure_code) linking it to sibling outputs, and the authoritative source. This gives the agent behavioral detail the annotations do not include.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose first, then parameter semantics, then use-case and source context. It is dense but every sentence earns its place. Slightly run-on in the parameter section, but no filler words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values don't need explanation. The description covers the selection semantics, error case, join relationship with sibling tools, and source authority. The only minor gap is no explicit indication of pagination or result limits, but for a single-parameter lookup tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the only parameter is a bare 'code' field with anyOf string/null. The description fully compensates: it explains the format with a concrete example ('org.1'), the omission semantics ('Omitido, todas'), and the error condition for invalid codes. This is complete, actionable parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear statement of what the tool returns: the documentation an auditor can request, per measure. It grounds the resource precisely (Annex II measures) and hints at differentiation from siblings via the source note ('no el ENS Navegable') and the join relationship with alcance_auditoria and declaracion_aplicabilidad. It slightly misses full sibling differentiation but the verb+resource+scope is 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the question it answers ('¿qué papeles preparo?') and places it in the pre-audit preparation phase. It also signals the source (CCN-STIC 808 §6.2, not the ENS Navegable), which helps an agent route to the correct data lineage. It does not state explicit when-not-to-use cases, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, repeatable read. The description adds the exact-match behavior, which is useful context beyond the schema, but it does not disclose potential edge cases (e.g., not-found behavior, error handling). Given the annotations carry the safety profile, the description provides modest additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It front-loads the core action (get by exact code) and immediately provides an illustrative example, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are documented separately. The tool is simple (one parameter, exact lookup), and the description explains the input format clearly. It does not address not-found behavior, but for a get-by-code tool with read-only annotations, the information provided is sufficient for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and there is only one parameter (code). The description gives a concrete example ('org.1') and clarifies that the code must be exact, adding meaning beyond the bare schema property. For a single-parameter tool, this compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Obtiene una medida de seguridad' (gets a security measure) and specifies the lookup by exact code ('por su código exacto'). This clearly distinguishes it from siblings like list_measures (list all) and search_measures (fuzzy search), so an agent can tell them apart without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'por su código exacto' implies the tool should be used when the exact measure code is known, which provides clear context. However, it does not explicitly mention alternatives or situations when to prefer other tools (e.g., search_measures for partial matches), so no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds substantial non-obvious behavioral details: invalid codes cause an error (not an empty list), the `essential` flag determines measure failure, and `code` within a measure is not unique (five '1.1' exist in op.acc.5) while `position` is the true identifier. This goes far beyond the annotations and prepares the agent for real edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bolded parameter names and front-loaded purpose. It is longer than minimal but earns its length by explaining tricky semantics. A minor typo ('tools.' mid-sentence) and a slightly meandering level explanation cost it a perfect score, but it remains appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, 0% schema coverage, and an output schema. While the description covers `code` and `level` thoroughly, it omits `limit`, `cursor`, and `essential_only` entirely. It also doesn't describe the overall return format or pagination behavior. For a tool with this complexity, the description is not complete enough to ensure correct invocation without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains `code` (measure example, error semantics) and `level` (official categories, section vs syllabus), but provides no explanation for `limit`, `cursor`, or `essential_only`. These three parameters remain undocumented, leaving a significant gap in the agent's ability to use them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Preguntas del cuestionario de auditoría (CCN-STIC 808), en bruto.' It specifies the verb (devuelve/returns), the resource (audit questionnaire), and the raw nature. It also distinguishes itself from sibling `alcance_auditoria` by explicitly pointing to it as the correct tool for the actual system syllabus, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: it warns that `level` filters by the guide's section, not the system's syllabus, and says 'Para el temario real de un sistema usa `alcance_auditoria`.' This directly routes the agent to the correct sibling and clarifies the subtle distinction, covering both when to use this tool and when not to.
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:

[![ensmcp MCP server](https://glama.ai/mcp/servers/seifreed/ensmcp/badges/card.svg)](https://glama.ai/mcp/servers/seifreed/ensmcp)

Score Badge

Copy to your README.md:

[![ensmcp MCP server](https://glama.ai/mcp/servers/seifreed/ensmcp/badges/score.svg)](https://glama.ai/mcp/servers/seifreed/ensmcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/seifreed/ensmcp'

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