map_controlsCrosswalk corpus controls between two compliance frameworks via the cross_references frontmatter graph. Useful for prompts like 'I am ISO 27001 certified — what gaps for NIS2?'. Returns an array of mapped pairs with confidence + source slug.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| to_framework | Yes | Target framework (e.g., nis2). | |
| from_framework | Yes | Source framework (e.g., iso27001). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, but the description adds valuable behavioral details: it operates on the 'cross_references' frontmatter graph and returns an array of mapped pairs with confidence and source slug. This goes beyond the annotations by explaining the underlying data source and output shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first stating purpose and mechanism and the second giving a usage example and output summary. It is front-loaded and free of unnecessary words, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, usage, mechanism, output type, and includes an example. Since there is no output schema, the description appropriately explains the return array and its fields. It does not mention error conditions or edge cases, but the tool is simple and read-only, so this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the description helps clarify the from/to frameworks using an example, but it does not mention the 'limit' parameter at all. The schema property descriptions are minimal ('Source framework', 'Target framework'), so the description adds some semantic value but does not fully compensate for the missing explanation of limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Crosswalk') and resource ('corpus controls between two compliance frameworks') via a specific mechanism ('cross_references frontmatter graph'). It also distinguishes itself from sibling tools like search_controls and assess_gap by focusing on mapping between frameworks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete usage example ('I am ISO 27001 certified — what gaps for NIS2?') that illustrates when to use the tool. It does not explicitly mention when not to use it or compare with alternatives, so it lacks exclusionary guidance but still offers clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: search_controls finds controls, assess_gap performs gap analysis, map_controls crosswalks frameworks, and generate_policy creates policy documents. No overlapping boundaries.
All tool names follow a consistent verb_noun pattern with lowercase and underscores: assess_gap, generate_policy, map_controls, search_controls. No deviations.
Four tools is well-scoped for a compliance-focused MCP server, covering search, analysis, mapping, and generation without unnecessary bloat.
The surface covers core workflows for compliance assessment and policy generation. A minor gap is that search is the only retrieval method and there is no direct 'get_control' tool, but search_controls with excerpts largely compensates.