Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@loxeai/mcp-server Scan my Terraform infrastructure for SOC 2 issues and explain the top finding."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for SOC 2 compliance work that runs entirely on your machine.
It scans your Infrastructure-as-Code, maps findings to SOC 2 Trust Services Criteria, explains them in plain English, and drafts the documents an audit will ask for. Your files never leave the laptop.
claude mcp add loxeai -- npx -y @loxeai/mcp-serverEvery compliance-automation platform surveyed converges on the same artifact: a dashboard of green checkmarks asserting things a viewer cannot verify. Auditors have noticed, some now refuse platform-reported data and require raw exports instead.
This tool tells you what it can't prove as clearly as what it can:
An IaC scan is the primary evidence source for 3 of the 33 SOC 2 Common Criteria. It partially informs 8 more. The remaining 22 are out of reach of any infrastructure scan — they need documents, people, or live cloud state. The tool says this to your face rather than implying broader coverage.
It never reports a criterion as satisfied. The absence of a finding is not evidence of compliance, and that judgment belongs to a licensed CPA. A test asserts the string "satisfied" cannot appear in the OSCAL output.
When a control mapping is a guess, it says so. Every mapping carries a mappingSource and a confidence, and the mapper declines to stretch rather than inventing a criterion. That refusal is the designed behavior, not a gap.
Related MCP server: AWS Compliance MCP Server
Requires Node 20+ and one scanner:
pipx install checkov # recommended — richer metadata
brew install trivy # or this — faster, single binary, no PythonIf neither is installed, the server tells you so and refuses to return an empty result — an empty finding list would read as "compliant."
claude mcp add loxeai -- npx -y @loxeai/mcp-serverclaude_desktop_config.json:
{
"mcpServers": {
"loxeai": {
"command": "npx",
"args": ["-y", "@loxeai/mcp-server"]
}
}
}No env block. There is nothing to authenticate against.
The trust page prints a fingerprint and a command. That command is real:
npx @loxeai/mcp-server verify --root /path/to/their/repo --expect <fingerprint>Exit 0 means the tree is byte-identical to the one that produced the report. Exit 1 means it is not. Needs no scanner, no account, and no network — it just hashes the files.
git clone <repo> && cd loxeai-mcp-server
npm install && npm run build
npm test # 140 tests
bash scripts/verify.sh # the full invariant gate
npx @modelcontextprotocol/inspector node dist/index.jsEvery tool is readOnlyHint: true, destructiveHint: false, and declares an outputSchema, so a client can validate every payload it receives.
Tool | What it does |
| Scan Infrastructure-as-Code for SOC 2 misconfigurations |
| List findings from a scan batch |
| Get full detail for one finding |
| Explain a finding in plain English |
| Map an IaC check to a SOC 2 control |
| SOC 2 control catalog |
| Group findings into action items by blast radius |
| Get the eight scoping questions |
| Scope SOC 2 to your company from eight questions |
| Preview what a trust page would say right now |
| Render the trust page as a self-contained file |
| Export scan results as NIST OSCAL assessment-results |
| Draft a SOC 2 policy grounded in your actual setup |
| List draftable policies and what each supports |
| Report what this server can and cannot do with your credentials |
| Check scanner availability and server scope |
URI | Contents |
| All 33 Common Criteria |
| One criterion, with completion on |
| The keyword rules the mapper uses, so you can audit them |
| Scan counts and fingerprint |
| The scan → fix → rescan loop |
Prompt | Purpose |
| Grounded remediation brief for one finding |
| Honest coverage summary for a repository |
"Do I even need SOC 2, and what would it involve?"
Ask me the applicability questions.Eight questions, then a per-criterion brief telling you what satisfying each one looks like for a company shaped like yours, and which three to deal with first. Fully deterministic — no model, no network.
It will not tell you a criterion doesn't apply. All 33 apply to essentially every SOC 2 Security engagement, and a tool that told you otherwise would be handing you an exception at fieldwork.
"What's wrong with my Terraform?"
Scan /abs/path/to/infra and explain the worst finding in plain English.scan_iac returns a handoff, not findings — a real repo produces hundreds. Page through with list_findings, then explain_finding gives you what it means, the real-world risk, why an auditor would care, what to change, and the shape of the fix.
"What would a trust page say right now?"
Preview my trust page.Per-criterion evidence status, each exception traced to file, line, rule ID, severity and mapping confidence, plus a fingerprint a reviewer can recompute.
Covered: SOC 2 Security category — the 33 Common Criteria (CC1.1–CC9.2), by identifier.
Not covered: the optional Availability (A1.x), Confidentiality (C1.x), Processing Integrity (PI1.x) and Privacy (P1–P8) categories. All five in scope would be 61 criteria. Also not covered: ISO 27001, HIPAA, PCI DSS, NIST, GDPR. The tool has no mapping for any of them and will not pretend otherwise.
Coverage within the Security category:
Count | Meaning | |
IaC-primary | 3 | CC6.1, CC6.6, CC6.7 — a scan is the main evidence source |
IaC-partial | 8 | A scan contributes but cannot satisfy alone |
Out of reach | 22 | No infrastructure scan can evidence these |
Of those 22, most are evidenced by a written document or by a human actually performing an activity — a risk assessment, a vendor review, an incident response. Across all 33, 21 have a document or a human process as their primary evidence source. Those are the ones no compliance tool automates, whatever its dashboard implies.
Every criterion carries an iacNote explaining precisely what a scan can and cannot show for it.
It performs no write operations. No filesystem writes, no mutating API calls. Remediation comes back as text; your agent applies it through its own approval step, with you in the loop. CI greps src/ to keep this true.
The server itself makes no outbound network requests. Enforced by grep in CI.
It does spawn subprocesses that can, and it would be dishonest to elide that:
Checkov is invoked with --skip-download and Trivy with --skip-check-update, suppressing their default policy/metadata fetches. (Cost: Checkov's guideline URL is then absent from findings.)
check_capabilities runs aws sts get-caller-identity and gh auth status, which contact AWS STS and api.github.com by definition — that is what they are for.
Everything else is local, and your file contents are never uploaded anywhere by anything.
That your credentials can't write. This is a different claim, and an important one. When a tool inherits your ambient CLI session it does not choose the scopes. A typical gh auth login carries repo (full control of private repositories — read and write) and workflow. An az login Graph token carries Group.ReadWrite.All and User.ReadWrite.All, and neither you nor a tenant admin can narrow that.
Run check_capabilities to see exactly where you stand. On GitHub, true credential-level read-only is achievable via a fine-grained PAT with read-only permissions. On Azure via az, it is not.
The worst thing this tool could do is hand you a confident, fingerprinted, prospect-facing document that says the opposite of the truth. Three separate conditions now force every reachable criterion to not-covered-by-this-scan and put INCOMPLETE SCAN at the top of the artifact:
no IaC files were found or read;
the scanner evaluated zero resources and ran zero checks — what an unparseable or unsupported configuration actually looks like;
any file failed to parse, or any check was explicitly suppressed in source (#checkov:skip=...).
The suppression case matters most. A suppressed check vanishes from failed_checks entirely, so without this a developer could silence a finding and the trust page would go green. A suppressed check is an accepted risk, not an absent one, and it is listed by ID, resource, file and stated reason on the artifact.
IaC carries attacker-influenceable strings: resource names, tags, comments, module source URLs. A scanner echoes them back, and they flow into an agent holding filesystem write access.
Before anything reaches model context, this server strips invisible and bidi unicode, neutralizes known injection patterns, and wraps content in explicit <untrusted-data> boundaries. Verified against live Checkov: a payload smuggled through a resource name comes back as aws_ebs_volume.[loxe:neutralized](32 chars)_and_[loxe:neutralized](13 chars).
This reduces the attack surface. It does not eliminate semantic prompt injection, and no encoding step can. Plausible instruction text that avoids the patterns will still get through. In particular, serializing to JSON is not a defense — {"name": "Ignore all previous instructions"} is still legible instruction text to a model. Any claim that structured output prevents injection is false.
It is not an audit, examination, attestation, assurance engagement, or opinion. Those are terms reserved to licensed CPAs under state accountancy law, not merely by convention. This is automated static analysis.
There is no such thing as "SOC 2 certified." SOC 2 is an attestation, not a certification. There is no certifying body and no certificate. Only a licensed CPA firm can perform a SOC 2 examination and issue a report.
Generated artifacts never assert compliance. The trust page emits per-criterion evidence status with traceable sources — never a framework badge, never "compliant." The OSCAL export only ever emits not-satisfied. Policy drafts state in their own header that having the document does not satisfy the criteria it supports.
If you need a claim you can safely put in front of a prospect while mid-process, this is the shape:
SOC 2 Type II examination in progress. Independent CPA firm [name] engaged; observation period [X]–[Y]; report expected [date].
Every element is a verifiable fact.
Code: MIT.
Control catalog: every title, description and plain-English restatement in src/catalog/soc2-controls.ts is original wording written for this project. None of it is AICPA text.
This matters more than it might appear. The official criterion text in AICPA TSP Section 100 is free to download but not free to redistribute — it carries "All rights reserved." Every widely-used SOC 2 control corpus we examined redistributes it anyway; one does so with "entity" search-replaced to "organization". An open-source license conveys only rights the licensor actually holds, so none of those corpora are safe to build on.
This catalog references criteria by identifier only and describes them in its own words. If you want the official text, buy it from the source:
AICPA & CIMA. TSP Section 100, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus — 2022). https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022
SOC 2® and Trust Services Criteria are property of the AICPA. This project is unaffiliated with the AICPA and references the criteria descriptively.
Points of focus are not requirements. TSP 100 §.07 states that using the criteria "does not require an assessment of whether each point of focus is addressed." So this tool says "MFA supports CC6.6", never "CC6.6 requires MFA." MFA appears only as a point of focus, and an auditor cannot fail you against one. Stating a point of focus as a requirement is the most common credibility failure in automated SOC 2 tooling.
Variable | Default | Purpose |
| cwd | Colon-separated directories the scanner may read |
|
| Bypass the trust check. Not recommended |
| unset | Path to a JSON file pinning |
Scan paths must be absolute. Relative paths resolve against the server's working directory and would silently scan the wrong tree.
Mapping overrides are validated against the catalog — an override naming a criterion that doesn't exist is rejected and logged to stderr, not silently accepted.
npm run build # tsc
npm test # vitest, 140 tests
npm run inspect # build + MCP InspectorInvariants enforced by scripts/verify.sh, run in CI: no filesystem writes in src/ · no outbound network from the server itself · no console.log (it corrupts the stdio protocol stream) · no deprecated SDK APIs · no Zod .description() · no stale scope strings · the mapper can never emit a criterion whose IaC capability is none · a scan that evaluated nothing can never report a clean criterion · every tool declares an outputSchema · the trust page never asserts a compliance claim on an assertive surface · OSCAL never emits satisfied.
The gate exits non-zero on any failure. A check that prints a count without failing the build is worse than no check, because it manufactures confidence — an earlier version of this script did exactly that and hid seven real failures.
Built on @modelcontextprotocol/sdk 1.30.0 using registerTool / registerResource / registerPrompt. Transport is stdio only — the deprecated SSE transport is not used.
Most parser tests run against hand-written fixtures matching Checkov's documented JSON shape, and the injection tests run against real Checkov 3.3.10 output. Before trusting field-level parser behavior in production, re-capture a fixture from your own Checkov version:
checkov -d <dir> -o json > test/fixtures/checkov-real.jsonBatches live in memory for the life of the server process. Restart the host and previous batchIds are gone.
Checkov's open-source build ships no severity metadata, so most findings come back UNKNOWN. The tool reports that honestly rather than inventing a level.
Control mapping is heuristic. It's driven by the scanner's own check names and resource types, not by a pinned check-ID table, because those IDs shift between scanner releases and a wrong mapping is worse than none. Confidence is always reported. Use LOXE_MAPPING_OVERRIDES to pin mappings you've validated.
No runtime evidence. Everything here describes declared configuration. Proving deployed state needs a live cloud check, which this server does not do.
--skip-check-update requires a warm Trivy cache. On a machine that has never run Trivy, the policy bundle is absent and the scan will under-report. Use Checkov, or run trivy config once with network access first.
Answer eight questions about how your company is set up and get back, for each of the 33 SOC 2 Common Criteria, what satisfying it actually looks like for a company shaped like yours and which ones to deal with first. Fully local and deterministic; no account, no network call, no model. Call applicability_questions first to get the question list. IMPORTANT: this does not remove criteria from scope — all 33 apply to essentially every SOC 2 Security engagement. It tells you what each one means for you and what to prioritise.
| Name | Required | Description | Default |
|---|---|---|---|
| cloud | Yes | Where infrastructure runs | |
| premises | Yes | Physical premises or company-owned hardware | |
| timeline | Yes | Where the company is in the SOC 2 process | |
| workforce | Yes | Who does the work | |
| iacCoverage | Yes | How much infrastructure is defined as code | |
| customerData | Yes | What kind of customer data is handled | |
| changeProcess | Yes | Whether every production change goes through a reviewed pull request | |
| productionAccess | Yes | How many people can change production |
| Name | Required | Description |
|---|---|---|
| answers | Yes | |
| caveats | Yes | |
| summary | Yes | |
| controls | Yes | |
| startHere | Yes | |
| scopeNotes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent, non-destructive), the description adds meaningful behavioral detail: fully local, deterministic, no account, no network call, no model. It also discloses the important caveat that results are prioritization guidance, not scope reduction, which an agent could easily misunderstand.
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 compact and front-loaded with the core value, then adds the prerequisite call and the critical scope caveat. Every sentence earns its place; there is no repetition of schema or annotation content.
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?
With a full input schema, an output schema, prerequisite guidance, and behavioral disclosure, the description is complete for an agent to select and invoke the tool correctly. The key caveat about not reducing scope is explicitly stated, and return-value details are covered by the output schema.
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 description coverage is 100%, with every parameter described and all eight using enums, so the schema carries the parameter documentation burden. The description adds context about the questions collectively but no per-parameter meaning beyond the schema, which is acceptable given full coverage.
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 names a specific action (answering eight questions) and a clear resource (the 33 SOC 2 Common Criteria), and explains exactly what the tool returns: tailored meaning and priorities for each criterion. It is immediately distinguishable from siblings like applicability_questions, which is positioned as a prerequisite rather than the same action.
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 clearly instructs the agent to call applicability_questions first and warns that the tool does not remove criteria from scope, which prevents a critical misuse. It doesn't explicitly enumerate alternative tools or when-not-to-use conditions beyond the prerequisite, but the context is clear enough for routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the eight questions used by applicability_brief, with the allowed values for each and why each question is asked. Ask the user these conversationally, then call applicability_brief.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| questions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so no safety disclosure is needed. The description adds behavioral context by explaining that the returned questions are meant to be asked conversationally and that they feed into applicability_brief. It also discloses the substance of the return value (questions, allowed values, rationale).
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?
Two sentences carry the full purpose, content, and usage workflow with no wasted words. The return content is front-loaded, and the actionable instruction is placed second. This is an ideal length for a zero-parameter tool.
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?
With no parameters, an output schema present, and a clear usage instruction, the description covers everything needed for correct invocation. It even tells the agent what to do with the result (ask the user) and what to call next. Nothing important is missing.
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?
The tool has zero parameters, so there is nothing for the description to clarify. The schema is empty and fully documented by its nonexistence. The description appropriately focuses on the tool's output and usage rather than inventing parameter details.
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 states a specific verb ('Returns') and a clear resource ('the eight questions used by applicability_brief'), and it distinguishes the tool by naming the sibling it serves. It also explains what content is included: allowed values and the rationale for each question. This is unambiguous and contextually rich.
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 gives explicit usage instructions: ask the user the questions conversationally, then call applicability_brief. This establishes the tool's role in a workflow and its relationship to the obvious sibling tool. No alternative tool could be confused for this one after reading the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reports which cloud/VCS CLIs are authenticated on this machine and whether those credentials are WRITE-CAPABLE. This matters because 'read-only' is two separate claims: that this server performs no write operations (true, and verifiable by code inspection), and that the credential itself cannot write (a property of the token, which this server does not control when it inherits your ambient CLI session). Use this before telling anyone the integration is read-only. Never reads, stores, or transmits a token value — it asks each CLI what it is already logged in as.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| caveats | Yes | |
| summary | Yes | |
| credentials | Yes | |
| serverGuarantee | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds meaningful behavioral nuance beyond that: it distinguishes server-side read-only behavior from token-level write capability, and it promises the tool never reads, stores, or transmits token values. It also clarifies the mechanism of asking each CLI what it is logged in as.
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 dense but every sentence earns its place: the core report capability, the important read-only distinction, a direct usage instruction, and a security guarantee. It is front-loaded with the main function before providing context.
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?
With no parameters, rich annotations, an output schema, and a description covering purpose, usage context, and security-relevant behavior, nothing essential is missing for an agent to select and invoke this tool correctly.
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?
The tool has zero parameters, so there is no parameter semantics burden on the description. The baseline of 4 applies because nothing needs to be documented beyond the already-complete empty schema.
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 names a specific verb ('Reports') and a specific resource: which cloud/VCS CLIs are authenticated and whether those credentials are write-capable. This clearly distinguishes the tool from the scanner/policy/finding siblings, none of which address credential capability checking.
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 explicitly says to call this tool 'before telling anyone the integration is read-only', giving a clear trigger condition. It does not name alternatives or exclusions, but no sibling tool appears to be a close alternative, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Collapses a list of findings into deduplicated action items and classifies each by how widely the fix applies: account-wide (fix once), per-region (rollout), per-resource (each resource), or per-person (human coordination).
This is what turns '400 findings' into '9 action items across 400 resources'. Pass a batchId to classify a whole scan, or pass findings inline to classify results from elsewhere.
Pure and offline: no scan, no network.
| Name | Required | Description | Default |
|---|---|---|---|
| batchId | No | Classify every finding in this batch. | |
| findings | No | Classify these findings instead of a batch. Ignored when batchId is given. |
| Name | Required | Description |
|---|---|---|
| groups | Yes | |
| byScope | Yes | |
| totalFindings | Yes | |
| totalActionItems | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds concrete behavioral detail: it deduplicates, classifies by blast radius, and is 'pure and offline: no scan, no network.' No side effects or caveats are omitted.
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?
Three sentences, front-loaded with the core transformation, then invocation modes, then a property. No filler or redundant restatement of schema fields.
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?
With an output schema, rich annotations, and 100% parameter coverage, the description covers purpose, invocation, and constraints. The parameter precedence (findings ignored when batchId is given) is in the schema, so no gap remains.
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 100%, so the baseline is 3. The description adds slight contextual flavor by linking batchId to 'whole scan' and findings to 'results from elsewhere,' but this mostly restates schema semantics rather than adding substantive parameter meaning.
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?
States a specific verb 'collapses' and resource 'findings' into 'deduplicated action items' with explicit classification categories. The phrase 'turns 400 findings into 9 action items across 400 resources' clearly differentiates it from sibling tools that list or scan findings.
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?
Clearly frames the tool as a post-processing step and offers two invocation modes: batchId for whole scans, findings inline for external results. It does not name sibling alternatives or state when not to use it, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the SOC 2 control catalog this server evaluates against. Pass controlId for
one control; omit it for all.
Scope is the SOC 2 Security category, which is all 33 Common Criteria (CC1.1-CC9.2). The optional A / C / PI / P categories are NOT covered.
An IaC scan is the primary evidence source for only 3 of the 33 and partially informs 8;
the remaining 22 need documents, people or live cloud state. Each control reports what a
scan can and cannot evidence for it via its iac capability and iacNote.
| Name | Required | Description | Default |
|---|---|---|---|
| controlId | No | A single control to return. Omit for the full catalog. |
| Name | Required | Description |
|---|---|---|
| controls | Yes | |
| frameworkScope | Yes | |
| supportedControlIds | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and idempotent, and the description adds meaningful behavioral context beyond that: it limits scope to 33 Common Criteria, states which categories are not covered, and explains the IaC evidence limitations (3 primary, 8 partial, 22 requiring non-scan evidence). It also tells the agent how each control reports scan capability via `iac` and `iacNote`. This is substantial added transparency with no contradiction.
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 compact and well structured: it opens with the core behavior, then scope, then the important evidence caveat. Every sentence carries useful information and none are redundant with the annotations or schema. The front-loaded main sentence lets an agent quickly understand the tool.
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?
For a read-only catalog retrieval tool with one optional enum parameter and an output schema, the description is complete. It covers what the catalog contains, what it excludes, how parameter omission behaves, and what evidence capability each control reports. No critical missing context stands out.
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?
The schema already describes the only parameter well at 100% coverage: controlId is an enum with 'Omit for the full catalog.' The description reinforces this and adds context about what the enum values represent (CC1.1-CC9.2) and that optional categories are excluded, but it does not add materially new parameter-level semantics beyond the schema.
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 first sentence states a specific action and resource: 'Returns the SOC 2 control catalog this server evaluates against.' The description further clarifies the exact scope (SOC 2 Security category, CC1.1-CC9.2) and distinguishes what it is not (optional A/C/PI/P categories). This is clear enough to separate it from sibling tools like list_policies or map_iac_finding_to_control.
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 gives direct usage guidance: pass controlId for a single control, omit it for the full catalog. It also explicitly excludes the optional A/C/PI/P categories, which prevents a common misuse. It does not explicitly name sibling alternatives or state when not to use this tool, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produces a policy DRAFT in Markdown, grounded in the answers you gave to applicability_brief and, optionally, a real scan. Returned as a string; this server writes no files. Every judgment call is left as an explicit {{PLACEHOLDER}}, counted and returned separately rather than silently filled with a plausible default — because a policy describing controls you do not actually operate is worse than no policy, and becomes an audit exception. The draft states in its own header that having the document does not satisfy the criteria it supports; SOC 2 also wants evidence it was approved, communicated, acknowledged and followed.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Which policy to draft | |
| cloud | No | ||
| batchId | No | Optional scan batch to ground the draft in | |
| premises | No | ||
| timeline | No | ||
| workforce | No | ||
| companyName | No | Company name. Omitted leaves a placeholder. | |
| iacCoverage | No | ||
| customerData | No | ||
| changeProcess | No | ||
| productionAccess | No |
| Name | Required | Description |
|---|---|---|
| kind | Yes | |
| title | Yes | |
| markdown | Yes | |
| warnings | Yes | Set when the draft would describe a control you do not operate. |
| groundedIn | Yes | Facts from your answers and scan that shaped this draft. |
| alsoRequires | Yes | What else you must produce beyond the document. |
| placeholders | Yes | Every {{PLACEHOLDER}} a human must resolve before use. |
| placeholderCount | Yes | |
| supportsCriteria | Yes | Criteria this CONTRIBUTES toward. A policy never satisfies one on its own. |
| suggestedFilename | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description adds meaningful behavioral detail beyond them: the server writes no files, placeholders are explicitly marked and counted rather than silently filled, and the draft itself warns that possessing the document does not satisfy the SOC 2 criteria. This is exactly the kind of non-obvious behavior an agent needs to know.
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 dense but each sentence earns its place: purpose and format, grounding source, placeholder behavior and rationale, and the audit-safety caveat. The core function is front-loaded, and the additional sentences address exactly what an agent must not overlook.
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?
Given the tool's complexity, the lack of detailed documentation for 11 parameters, and the presence of annotations and an output schema, the description is remarkably complete. It clarifies output format, side effects, placeholder handling, and a non-behavioral safety concern. There is no missing behavioral information that would prevent correct invocation or mislead the agent.
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 description coverage is only 27%, so the description bears extra responsibility for parameter semantics. It does add useful meaning by tying the draft to applicability_brief answers and an optional scan batch, which helps map parameters to context. However, it does not explain the individual parameter roles or how they override or supplement the applicability_brief answers, leaving much of the semantic burden on self-explanatory enum names and the schema.
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 opens with a specific verb and resource: it produces a policy DRAFT in Markdown, grounded in applicability_brief answers and optionally a scan. It clearly distinguishes itself from sibling tools like list_policies (which lists existing policies) and applicability_brief (which gathers answers), so an agent can tell them apart immediately.
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 explicitly states the grounding requirement: use the answers from applicability_brief and optionally a real scan. This gives clear when-to-use context. It does not explicitly name when not to use this tool or mention alternatives by name, 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.
Takes a finding from a scan and explains it without jargon: what it actually means, the real-world risk of ignoring it, why an auditor would care, what to change, and roughly what shape of work the fix is. Everything returned is derived from the finding itself — severity, control mapping and its confidence, blast radius — so it never invents a risk claim. Where the data is missing or the mapping is weak, it says so.
| Name | Required | Description | Default |
|---|---|---|---|
| batchId | Yes | Batch ID returned by scan_iac | |
| findingId | Yes | Finding ID from list_findings or get_finding |
| Name | Required | Description |
|---|---|---|
| effort | Yes | |
| caveats | Yes | Populated when the explanation rests on a weak mapping. |
| headline | Yes | |
| findingId | Yes | |
| strengths | Yes | |
| whatToFix | Yes | |
| weaknesses | Yes | |
| realWorldRisk | Yes | Hedged when the scanner assigned no severity. |
| whatThisMeans | Yes | |
| whyAnAuditorWouldCare | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description adds a meaningful behavioral guarantee: every output is derived from the finding itself and it never invents a risk claim. It also discloses that missing or weak control-mapping data will be explicitly flagged rather than silently filled in, which is important trust context for an AI agent.
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?
Three sentences each carry distinct information: what the tool produces, the content of the output, and the honesty/limitation behavior. The list of explanation components is compact and front-loaded, with no filler.
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?
For a read-only tool with two simple required parameters and an output schema, the description covers what the result contains, where the data comes from, and how gaps are handled. Nothing essential is missing for correct invocation and interpretation.
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 100%, so the two parameters are already documented in the input schema. The description adds no extra parameter-level semantics beyond identifying the finding context, so the baseline 3 is appropriate.
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 names a specific resource ('a finding from a scan') and a specific action ('explains it without jargon'), then enumerates exactly what the explanation covers: meaning, risk, auditor relevance, remediation, and fix size. This separates it from siblings like get_finding (raw retrieval) and map_iac_finding_to_control (mapping only), even though no sibling is named.
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 purpose is clearly to get a plain-English, auditor-oriented explanation of a specific finding, so an agent can infer when to call it after identifying a finding. It does not explicitly name alternatives or state when not to use it, but the context is clear enough that no exclusions are needed for a read-only explanation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Emits the scan as a NIST OSCAL assessment-results document (JSON), the machine-readable format used by GRC platforms and assessment tooling. Returned as a STRING; this server writes no files. Two deliberate limitations are stated inside the document itself: no official OSCAL catalog for SOC 2 exists, so criterion IDs are used descriptively; and only 'not-satisfied' findings are ever emitted — this tool never asserts 'satisfied', because the absence of a scanner finding is not evidence that a criterion is met.
| Name | Required | Description | Default |
|---|---|---|---|
| batchId | Yes | Batch ID returned by scan_iac |
| Name | Required | Description |
|---|---|---|
| bytes | Yes | Size of the OSCAL JSON, which is returned in `content`, not here. |
| oscalVersion | Yes | |
| findingsEmitted | Yes | Only ever not-satisfied findings. 'satisfied' is never emitted. |
| suggestedFilename | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint/idempotentHint annotations by disclosing that the result is a STRING, that the server writes no files, and that the document contains deliberate limitations: descriptive criterion IDs due to no SOC 2 catalog, and only 'not-satisfied' findings emitted. These are non-obvious, decision-relevant behaviors.
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?
Three sentences with no filler: the first states the core action and format, the second covers return type and side effects, and the third explains the two key limitations. Each sentence earns its place and the most important information is front-loaded.
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?
For a one-parameter, read-only, idempotent export tool with a full input schema and an output schema, this description covers every behavioral nuance an agent needs: return type, file effects, and embedded limitations. Nothing material is missing.
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 description coverage is 100% and the single parameter batchId is already documented as 'Batch ID returned by scan_iac,' so the description does not need to add parameter-level detail. The baseline of 3 applies because the schema carries the semantic weight and the description adds no further parameter context.
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 names a specific verb ('Emits') and a precise resource ('NIST OSCAL assessment-results document (JSON)'), with a clear format and purpose. The machine-readable GRC orientation implicitly differentiates it from human-readable siblings like render_trust_page and preview_trust_page, so an agent can tell them apart.
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 gives useful context about the output being machine-readable for GRC platforms and assessment tooling, so an agent can infer this is for integrations rather than human review. However, it never explicitly states when to use this tool versus alternatives, nor does it mention any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a single finding with its SOC 2 control mapping (including how the mapping was derived and how confident it is), blast-radius classification, and remediation guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| batchId | Yes | Batch ID returned by scan_iac. | |
| findingId | Yes | Finding ID from list_findings. |
| Name | Required | Description |
|---|---|---|
| finding | Yes | |
| mapping | Yes | |
| blastRadius | Yes | |
| remediationGuardrails | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by disclosing exactly what the returned finding contains, including how the SOC 2 mapping was derived and its confidence level. There is no contradiction with the annotations.
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 a single compact sentence that leads with the core action ('Returns a single finding') and then packs the distinguishing payload details without filler. It is easy to scan and earns its length.
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?
Given the presence of an output schema, read-only annotations, and full input-schema documentation with parameter provenance, the description is complete enough for an agent to invoke the tool correctly. It explains what makes this tool valuable without needing to restate structured schema information.
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 100%, and both batchId and findingId already have descriptions that specify their origin from scan_iac and list_findings, respectively. The tool description adds no extra parameter-level detail, so the baseline score of 3 is appropriate.
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 verb and resource: it returns a single finding, and it enumerates the specific detail categories included: SOC 2 control mapping, mapping derivation and confidence, blast-radius classification, and remediation guidance. It does not explicitly differentiate from siblings like explain_finding, but the 'single finding' framing distinguishes it from list-oriented tools.
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?
Usage is implied rather than explicit: the title and description suggest retrieving full details for one finding, and the input schema mentions that batchId comes from scan_iac and findingId from list_findings. However, the description does not state when to prefer this over explain_finding or other related tools, nor does it provide 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.
Pages through findings from a previous scan_iac call. Returns lightweight rows;
call get_finding for full detail on one.
Findings with UNKNOWN severity are never filtered out by minSeverity. Checkov's open-source build often omits severity metadata, and dropping those findings would under-report real misconfigurations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows to return. Default 50. | |
| cursor | No | Opaque cursor from a previous call's nextCursor. | |
| batchId | Yes | Batch ID returned by scan_iac. | |
| controlId | No | Only findings mapped to this SOC 2 control. | |
| minSeverity | No | Only findings at or above this severity (UNKNOWN always included). | |
| unmappedOnly | No | Only findings no rule could map to a control. |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| batchId | Yes | |
| findings | Yes | |
| returned | Yes | |
| nextCursor | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this read-only and idempotent, and the description adds meaningful behavioral context beyond those hints: it returns lightweight rows, pages via a cursor, and—crucially—never filters UNKNOWN severity findings, with a rationale. This non-obvious filter behavior could change an agent's interpretation of results, so disclosing it is high value.
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 compact and front-loaded: the main action and sibling distinction appear in the first sentence, and the second paragraph justifies a crucial filter exception without repetition. Every sentence earns its place.
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?
For a paginated list tool with a rich output schema and full parameter documentation, this description covers the workflow context, row granularity, and a key behavioral exception. Nothing an agent needs to call it correctly is missing; the output schema presumably handles return-field details.
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 100%, so the baseline is 3. The description adds value by explaining the UNKNOWN severity behavior with an underlying reason and by characterizing the return rows as lightweight, which informs how an agent should interpret limit and cursor parameters. It does not systematically enrich every parameter, but the minSeverity context goes beyond the schema.
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 states a specific verb and resource: 'Pages through findings from a previous scan_iac call.' It also distinguishes itself from get_finding by noting it returns lightweight rows rather than full detail, which differentiates it from a key sibling without opening schemas.
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?
It explicitly ties usage to a prerequisite ('from a previous scan_iac call') and routes the agent to get_finding when full detail is needed. The UNKNOWN severity caveat also tells the agent when not to expect filtering behavior, providing actionable selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the policies this server can draft, the SOC 2 criteria each contributes toward, and what else you must produce beyond the document itself for those criteria to actually be addressed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| policies | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior, so the description need not repeat that. It adds valuable behavioral context by revealing that the tool returns not just policy names but also SOC 2 criteria and extra deliverables beyond the document, which goes beyond the raw annotations.
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 a single sentence but conveys three distinct pieces of information: the scope (server-draftable policies), the criteria mapping (SOC 2), and the caveat about additional required outputs. There is no redundancy with the title or annotations, and every clause earns its place.
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?
With zero parameters, a rich output schema, and safety annotations already provided, the description covers the essential operational context: what the tool returns, the scope of that return, and a key nuance about what else is needed. Nothing critical is missing for an agent to decide whether to call this tool.
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?
The input schema has zero parameters, so there is no parameter burden for the description to carry. The baseline for a parameterless tool is 4, and the description appropriately focuses on return semantics instead.
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 states a specific verb ('Returns') and resource ('the policies this server can draft'), and further specifies what each policy supports: SOC 2 criteria and additional required deliverables. This clearly distinguishes it from sibling tools like draft_policy or list_findings.
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 clearly implies the tool should be used when an agent needs to see which policies are draftable and what each entails, which differentiates it from scanning or finding tools. It does not explicitly name alternatives or state when not to use it, 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.
Maps a scanner check to a SOC 2 Trust Services Criterion without running a scan. Useful for checks surfaced by another tool, CI output, or a scanner this server does not wrap.
Always returns mappingSource and confidence. A low confidence mapping is a
keyword match that the resource type did not corroborate -- verify it before relying
on it. unmapped means no rule matched; that is a real answer, not a failure.
| Name | Required | Description | Default |
|---|---|---|---|
| checkId | No | Scanner check ID, e.g. CKV_AWS_19 or AVD-AWS-0088. | |
| checkName | Yes | The scanner's check name or title, e.g. 'Ensure S3 bucket has encryption enabled'. | |
| resourceType | No | Resource type, e.g. aws_s3_bucket. Raises mapping confidence when it corroborates. |
| Name | Required | Description |
|---|---|---|
| controlId | Yes | |
| rationale | Yes | |
| confidence | Yes | |
| requirement | Yes | |
| controlTitle | Yes | |
| evidenceLimit | Yes | |
| mappingSource | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds valuable behavioral detail beyond annotations: it always returns mappingSource and confidence, explains what low confidence means, and clarifies that unmapped is a real answer rather than a failure. This materially helps an agent interpret the tool's response.
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 compact and front-loaded. The first sentence states what the tool does, the second gives usage context, and the final paragraph explains output semantics. Every sentence earns its place with no filler or redundancy.
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?
Given the tool's simplicity, the rich input schema, the output schema, and the safety-related annotations, the description covers everything an agent needs: what it does, when to use it, what it returns, and how to interpret confidence and unmapped results. No critical behavioral gap remains.
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 description coverage is 100%, so the baseline is 3. The description adds semantic meaning for resourceType by explaining that it 'corroborates' and raises mapping confidence, which is not fully captured in the schema. It does not add much for checkId or checkName, but those are already well documented in the schema.
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 uses a specific verb ('maps') and identifies the exact resource and outcome: a scanner check to a SOC 2 Trust Services Criterion. It also explicitly distinguishes itself from scan-based tools by stating it runs 'without running a scan,' which helps an agent separate it from siblings like scan_iac.
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 gives clear when-to-use context: checks surfaced by another tool, CI output, or a scanner this server does not wrap. It also implies an exclusion ('without running a scan'), but it does not explicitly name alternative tools or state when to prefer those siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Builds a per-criterion evidence summary from a scan, suitable for showing a prospect's security team. Every row traces to the file, line, rule ID, mapping confidence and timestamp behind it, and the document carries a fingerprint the viewer can recompute. This returns DATA ONLY — nothing is published and no file is written. It never emits a compliance badge or the words 'compliant' or 'certified': SOC 2 is an attestation that only a licensed CPA firm can issue, and this is an automated scan.
| Name | Required | Description | Default |
|---|---|---|---|
| batchId | Yes | Batch ID returned by scan_iac |
| Name | Required | Description |
|---|---|---|
| scan | Yes | |
| scope | Yes | |
| summary | Yes | |
| controls | Yes | |
| notCovered | Yes | |
| statusLine | Yes | Prefixed INCOMPLETE SCAN when coverage cannot support a clean result. |
| disclaimers | Yes | |
| generatedAt | Yes | |
| documentTitle | Yes | Deliberately not an audit/attestation title. Reserved terms. |
| documentFingerprint | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnly/idempotent annotations by disclosing that no publish or file write occurs, that the output is data-only, and that it never emits compliance language like 'compliant' or 'certified' — with the CPA-attestation rationale explaining why. It also reveals a fingerprint mechanism the viewer can recompute, which is meaningful behavioral detail an agent would not infer from annotations alone.
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 front-loaded with the primary purpose and then adds traceability, non-publishing, and compliance guardrails. It is somewhat verbose, especially the CPA/attestation rationale, but every sentence contributes substantive context and none of it is filler.
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?
With one fully documented parameter, an output schema present, and annotations already establishing read-only and non-destructive behavior, the description is complete for safe invocation. It covers the tool's outputs, evidence lineage, side-effect absence, and content constraints, so an agent has everything needed to select and call it correctly.
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 100% because batchId is documented as the batch ID returned by scan_iac. The description adds only 'from a scan' at a concept level and does not provide additional parameter-specific guidance, so the schema carries the load 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it 'builds a per-criterion evidence summary from a scan' for a prospect's security team. It also distinguishes itself from publication tools by emphasizing 'returns DATA ONLY — nothing is published and no file is written', which separates it from siblings like render_trust_page.
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 makes the usage context clear: use this when you need a previewable evidence summary without publishing or persisting anything. It does not explicitly name alternatives or say 'use render_trust_page when you want to publish', so it lacks an explicit when-not, but the data-only framing provides strong implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the trust page as a complete HTML or Markdown document, as a STRING. This server never writes files — save it yourself, or ask your agent to write it so the diff goes through your normal approval step. The HTML is fully self-contained: no CDN, no webfont, no analytics, no script, no external request of any kind, because a trust page that phones home would be flagged in exactly the security review it exists to serve.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format | html |
| batchId | Yes | Batch ID returned by scan_iac |
| Name | Required | Description |
|---|---|---|
| bytes | Yes | Size of the document, which is returned in `content`, not here. |
| format | Yes | |
| suggestedFilename | Yes | |
| documentFingerprint | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description explicitly discloses that no file is written and the returned HTML is fully self-contained with no CDN, webfont, analytics, script, or external requests. This adds meaningful behavioral detail and aligns with the annotations.
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 compact and front-loaded: it states the core behavior first, then gives actionable usage guidance, then explains the self-contained security rationale. Every sentence contributes meaning without redundancy.
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?
Given the annotations and output schema, the description covers the essential operational details: what it returns, that it does not write files, and why the output is self-contained. This is sufficient for an agent to call the tool and handle the result correctly.
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 description coverage is 100%, so the schema already documents the parameters. The description references HTML and Markdown, which maps to the format enum, but it does not add extra parameter-level detail beyond the schema.
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 returns the trust page as a complete HTML or Markdown string. It identifies the exact resource and output form, but it does not explicitly distinguish itself from the sibling preview_trust_page, so it lacks full sibling differentiation.
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 gives clear practical guidance: the server never writes files, so the agent must save the output itself or have its agent write it to go through approval. This is useful context, though it does not explicitly discuss when to prefer render_trust_page over preview_trust_page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scans Infrastructure-as-Code for security misconfigurations and maps each finding to a SOC 2 Trust Services Criterion. Supports Terraform, CloudFormation, Kubernetes, Dockerfile, Helm, ARM and Bicep via a locally installed Checkov or Trivy.
The scan runs entirely on this machine. File contents are never transmitted anywhere.
Returns a SUMMARY AND A HANDOFF, not the findings themselves -- a real repository
produces hundreds of findings. Call list_findings with the returned batchId to page
through them, then get_finding for detail on a specific one.
The path MUST be absolute. Run pwd in the target directory if you need it.
Scope: SOC 2 Security category only. All 33 Common Criteria are catalogued, but an IaC scan is the primary evidence source for just 3 of them and partially informs 8 more -- the remaining 22 are out of reach of any infrastructure scan and need documents, people, or live cloud state. This server does not support ISO 27001, HIPAA, PCI, NIST or GDPR. Do not claim coverage it does not have.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the directory or file to scan. Must be absolute, not relative. | |
| scanner | No | Force a specific scanner. Omit to prefer Checkov, which has richer control metadata. | |
| configPath | No | Optional absolute path to a scanner config file (Checkov only). | |
| frameworks | No | Restrict the scan to these IaC frameworks. Omit to let the scanner auto-detect. |
| Name | Required | Description |
|---|---|---|
| next | Yes | |
| caveat | Yes | |
| counts | Yes | |
| batchId | Yes | Pass this to list_findings and get_finding. |
| scanner | Yes | |
| scannedAt | Yes | |
| fingerprint | Yes | SHA-256 over the scanned input. An identical fingerprint across two scans proves the input did not change. |
| parseErrors | Yes | Files the scanner could not parse. A partial result, NOT a clean one. |
| sanitization | Yes | |
| suppressions | Yes | Checks a developer explicitly suppressed in source. These do NOT appear as findings; a suppressed check is an accepted risk, not an absent one. |
| totalFindings | Yes | Findings produced before any cap. `counts` reflects this, not the retained list. |
| scannerVersion | Yes | |
| findingsTruncated | Yes | True when the retained finding list was capped. A criterion with no findings may simply have had them dropped. |
| filesFingerprinted | Yes | |
| frameworksDetected | Yes | |
| fingerprintTruncated | Yes | True when the fingerprint walk hit its file cap and covers only a subset of the tree. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds meaningful behavioral context: the scan runs entirely on this machine, file contents are never transmitted, and the result is a summary/handoff rather than the full findings. This goes well beyond the annotation baseline and does not contradict it.
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 dense but each paragraph earns its place: core action, privacy guarantee, result handoff, path requirement, and scope boundary. It is front-loaded with the primary purpose and contains no filler or repetition.
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?
For a multi-framework scanning tool, the description covers the essential operational details: supported frameworks, scanner choice, local-only execution, absolute path requirement, output handoff flow, and strict scope limitations. An output schema exists, so return-value documentation is not needed.
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 description coverage is 100%, so the baseline applies. The description reinforces that path must be absolute, but the schema already states this; it adds little new parameter-level meaning beyond what the structured definitions provide.
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 opens with a specific verb and resource: scans Infrastructure-as-Code for security misconfigurations and maps each finding to a SOC 2 Trust Services Criterion. It also clarifies the tool's role relative to downstream siblings like list_findings and get_finding, making its purpose unambiguous.
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 explicitly tells the agent what to do after scanning: call list_findings with the returned batchId, then get_finding for detail. It also scopes use to SOC 2 Security, lists unsupported standards, and warns against claiming unsupported coverage, which provides clear when-to-use and 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.
Reports which IaC scanners are installed, which control framework is supported, and which trusted roots this server will scan. Call this first when a scan fails.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| coverage | Yes | |
| scanners | Yes | |
| anyAvailable | Yes | |
| trustedRoots | Yes | |
| networkEgress | Yes | |
| frameworkScope | Yes | |
| criteriaCatalogued | Yes | |
| supportedControlIds | Yes | |
| iacAddressableControlIds | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context by specifying exactly what information is reported and when it is appropriate to call, without contradicting the annotations.
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?
Two sentences carry all necessary information: the first enumerates the report contents, the second gives a direct usage directive. No filler or redundancy.
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?
With no parameters, a rich output schema, and strong annotations, the description is fully sufficient. It explains the tool's scope and provides actionable guidance for when to call it.
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?
The tool has zero parameters, so there is nothing to explain. The schema coverage is effectively complete, and the description correctly focuses on behavior rather than inputs.
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 states a clear verb ('Reports') and specific resources: installed IaC scanners, supported control framework, and trusted roots to be scanned. This precisely distinguishes the tool from its siblings, which focus on scanning and finding operations.
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 explicitly says 'Call this first when a scan fails,' providing clear diagnostic context. It does not list exclusions or alternative tools, but the guidance is sufficient for a zero-parameter status tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0applicability_briefapplicability_questionscheck_capabilitiesclassify_blast_radiuscontrolsdraft_policyexplain_findingexport_oscalget_findinglist_findingslist_policiesmap_iac_finding_to_controlpreview_trust_pagerender_trust_pagescan_iacscanner_statusEvery tool targets a distinct step in the scan-to-evidence pipeline: scan vs paginate vs detail vs explain vs classify vs map are clearly separated, and even the adjacent preview/render and status/capability pairs are differentiated by their names and descriptions. There is no pair an agent would plausibly confuse when selecting a tool.
Most tools follow a lower_snake_case verb_noun pattern (scan_iac, list_findings, render_trust_page); a few are noun-phrase names (controls, scanner_status, applicability_brief). The style is still internally consistent and readable, so this is a minor deviation rather than a real problem.
16 tools is one above the typical well-scoped range, but each tool maps to a distinct stage in the SOC 2 IaC workflow: environment checks, scanning, finding navigation, mapping, applicability, policy drafting, and reporting. No tool is redundant, so the count feels deliberate rather than bloated.
The tool surface covers the full lifecycle this server promises: environmental preflight, scanning, finding investigation, control mapping, blast-radius triage, tailored applicability, policy draft, trust-page rendering, and OSCAL export. The read-only/no-file-write constraint is consistently honored and does not leave obvious dead ends; list_findings/get_finding and applicability_questions/applicability_brief are properly chained.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
HIPAA compliance AI agent — scan, grade, SRA, and generate compliance docs.
Threat modeling, code/cloud/pipeline scanning, shadow-AI discovery, compliance checks and fixes.
Scans schema metadata to classify PHI, score HIPAA readiness, and generate compliant migrations.
Generate, audit, and maintain legal policies that match what your code actually does.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/adog0822/loxeai-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
