Skip to main content
Glama

Get Framework Coverage

get_framework_coverage
Read-only

Get real ControlCodeMap-backed coverage percentages, gap counts, and mapped controls for EU AI Act, DORA, NIST AI RMF, ISO 27001, SOC 2, etc.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
frameworkNoOptional framework filter (e.g. eu-ai-act, dora, nist, iso)
diagram_idYesDiagram id/uuid
include_graphNoInclude crossmap relationship graph

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / diagram_id / description
      Previous value: -"Diagram pk or uuid"New value: +"Diagram id/uuid"
    • changedInput schema / properties / framework / description
      Previous value: -"Optional framework filter (e.g. 'NIST-800-53', 'SOC2')"New value: +"Optional framework filter (e.g. eu-ai-act, dora, nist, iso)"
    • removedInput schema / properties / include_graph / default
      Removed value: -false
    • changedInput schema / properties / include_graph / description
      Previous value: -"Also return the crossmap node/edge graph"New value: +"Include crossmap relationship graph"
  2. First observed

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that results are 'real ControlCodeMap-backed' and enumerates the output categories, which is useful, but it says nothing about scoping behavior, cost, or what happens when a framework is unsupported.

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?

A single front-loaded sentence with no filler; the verb and payload come first. The trailing 'etc.' and the long framework list are slightly loose but not wasteful.

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 no output schema, the description usefully names what is returned (coverage percentages, gap counts, mapped controls), covering the main gap. It leaves the include_graph graph behavior and failure modes unexplained, which is the only notable omission for a 3-parameter read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so framework, diagram_id, and include_graph are all documented in the schema itself. The description's framework list (EU AI Act, DORA, NIST, ISO 27001, SOC 2) loosely illustrates the framework filter but adds no syntax or format detail beyond the schema's own examples, so baseline 3 applies.

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?

States a specific verb (Get) and resource (framework coverage) and enumerates the concrete return values: coverage percentages, gap counts, and mapped controls. It does not, however, explicitly distinguish itself from near siblings like get_cloud_compliance or compliance_status, leaving the agent to infer the boundary.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as compliance_status or get_cloud_compliance. The 'real ControlCodeMap-backed' qualifier hints at authority but does not tell the agent when this tool is the correct choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.