Skip to main content
Glama
Sign In
CodeInspectus

CodeInspectus

by Synvoya
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Code-level compliance coverage report

codeinspectus_compliance_report
Read-onlyIdempotent

Generate a per-framework code-level control-coverage report from a prior scan, showing X of N code-visible controls with findings for NIST, ISO 27001, SOC 2, CIS, Essential Eight, and OWASP.

Instructions

Produce a per-framework code-level control-coverage view for a prior scan (NIST CSF 2.0, ISO 27001:2022, SOC 2, CIS v8.1, Essential Eight, OWASP Web/LLM). Reports 'X of N code-visible controls have findings' with the code-visible subset as the explicit denominator. This is NOT a compliance audit, certification, or attestation — code-level evidence only.

Input Schema

NameRequiredDescriptionDefault
scan_idYesscan_id returned by a prior codeinspectus_scan call.
frameworkNoRestrict the report to one framework. Default: all frameworks.

Output Schema

NameRequiredDescriptionDefault
scan_idYes
disclaimerYes
frameworksYes
posture_noteYes
posture_scoreYes
coverage_notesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.0.0
    • addedOutput schema / properties / coverage_notes
      Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "component": {
+        "type": "string"
+      },
+      "detail": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "component",
+      "detail"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
  2. Changed1 schema field changedv0.3.0
    • addedInput schema / properties / scan_id / pattern
      Added value: +"^scan-[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$"
  3. First observedv0.2.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the report is derived from a prior scan's results, coverage is measured against a code-visible subset rather than full control sets, and the results must not be read as attestation. It does not describe behavior on a stale or invalid scan_id, which is the main remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core action and denominator semantics, closing with the scope disclaimer. No filler and nothing buried.

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, the description needn't explain return fields, and it covers the prerequisite, denominator semantics, and interpretation limits well. Minor gap: it doesn't say what happens when the referenced scan doesn't exist or a framework has no code-visible controls.

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

Parameters3/5

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

Schema description coverage is 100%, with both parameters documented and the framework enum fully enumerated, so the schema does the heavy lifting. The description's framework list mirrors the enum and it does not add meaning to scan_id beyond what the schema states. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('produce a per-framework code-level control-coverage view') and names the exact frameworks covered. The output form is concretely described ('X of N code-visible controls have findings' with an explicit denominator), so an agent knows precisely what it gets back.

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?

Establishes the prerequisite clearly ('for a prior scan', matching the scan_id param) and draws an explicit boundary that this is not an audit/certification/attestation. It does not, however, contrast itself with siblings like codeinspectus_explain_finding or codeinspectus_generate_sbom, so the routing decision against alternatives remains implicit.

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

Deploy Server

Other Tools