Scans Terraform configurations for security misconfigurations, explains findings, applies safe fixes, provides hardened templates, and maps results to compliance frameworks.
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., "@sovereign scan my Terraform for security issues"
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.
Your AI assistant writes Terraform. This checks it before you do.
An MCP server that scans Terraform for security misconfigurations while the code is being generated, not after it lands in a pull request. It runs locally, needs no account, and your infrastructure code never leaves your machine.
You: "add an RDS instance for the orders service"
Assistant: [writes HCL] → [scans it] → [fixes 4 findings] → shows you the resultProvider defaults optimise for it works, not it is safe. Terraform generated from a model's memory is routinely unencrypted, publicly reachable, or missing deletion protection — and the cost of fixing that rises steeply the further it travels. In the editor it is one attribute. In a PR it is a review cycle. In production it is an incident.
CI already catches this. CI catches it three days and one argument later.
Related MCP server: Cybrium MCP Server
claude mcp add sovereign -- uvx sovereign-observer~/.cursor/mcp.json:
{
"mcpServers": {
"sovereign": {
"command": "uvx",
"args": ["sovereign-observer"]
}
}
}.vscode/mcp.json:
{
"servers": {
"sovereign": {
"type": "stdio",
"command": "uvx",
"args": ["sovereign-observer"]
}
}
}~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"sovereign": {
"command": "uvx",
"args": ["sovereign-observer"]
}
}
}First run downloads the engine (~100 MB) and takes a moment. After that it is local and fast.
Tool | What it does |
| Scan HCL — from disk or an unsaved buffer. Returns findings by severity with file and line. |
| The full remediation for one finding: what is wrong and the exact Terraform to fix it. |
| Apply the mechanically-safe fixes and return patched HCL. |
| A hardened starting point for a resource type, so the insecure version never gets written. |
| Map findings to SOC 2, ISO 27001, NIST 800-53, PCI-DSS, DORA, NIS2, NCA (Saudi), NESA (UAE). |
| Which articles of a regulation automated scanning can and cannot evidence. |
| Your organization's own rules for a resource type — before the code is written. |
| Whether org policy is in force, or built-in rules only. |
You do not call these. The assistant does, on its own, because the server tells it to.
Everything above works with no account. Connecting an organization adds your company's own rules to the same local evaluation:
export SOVEREIGN_TOKEN=... # Integrations → GitHub in the dashboardThe difference this makes is in when the rule applies. Without it, the assistant writes Terraform and then finds out it was wrong. With it:
You: "add an RDS instance for the orders service"
Assistant: → org_requirements("aws_db_instance")
← "backup_retention_period must be at least 365"
"region must be one of: eu-west-1, eu-central-1"
[writes Terraform that already satisfies both]
→ scan_terraform → cleanThe rule is supplied to the generator, not applied to the output. That is the whole point — a violation that never gets written costs nothing to fix.
Company rules appear in scans tagged source: org_policy, so a developer can always tell
a company requirement from a built-in one. They are authored in the dashboard as YAML and
enforced identically in the editor, in CI, and in a cloud scan.
This does not change what leaves your machine. Rules come down; code never goes up.
The only request this server makes is a GET for your org's rules —
tests/test_org_policy.py::test_no_terraform_is_ever_uploaded asserts that at the
transport, and asserts an unconnected install opens no socket at all. If the API is
unreachable or the token is rejected, the built-in rules still run locally and the scan
still works.
Worth stating plainly, because a security tool that overstates its scope is worse than no tool:
It is not a compliance assessment. check_compliance returns control mappings —
evidence that shortens an audit. Every framework it maps also carries governance,
process and training obligations no configuration scanner can observe. A clean scan is
not a compliant organisation.
NCA control identifiers are provisional, pending reconciliation against the authority's published catalogue. Cite the subdomain names.
apply_fixes is deliberately narrow. It applies only single-attribute, in-place
changes from a hand-verified allowlist, and never overwrites a value wired to a variable
or expression. Everything else stays advisory, because a mechanical fix that is
syntactically clean can still take a running system down.
It scans Terraform, not live cloud accounts, container images, or dependencies.
For live multi-cloud posture management, attack-path analysis and audit-ready reporting, this is the editor-side slice of Sovereign Observer.
The scan runs in this process, on your machine. There is no API key, no account, and no network call in the default path — the server works with networking disabled. Your Terraform is never uploaded.
pip install -e ".[dev]"
python -m pytest tests/ -qsovereign_mcp/_vendor/ holds the IaC engine. In the Sovereign Observer
monorepo those modules are generated at build time by scripts/vendor_engine.py
so the rule logic has exactly one source; here they are committed so this
package builds on its own. Edit them upstream, not here — changes made in
this repository are overwritten on the next sync.
tests/test_parity.py verifies the vendored copies match their upstream source
and that the Checkov pin matches the backend's. Those checks skip automatically
outside the monorepo, since there is nothing to compare against.
Licensed Apache-2.0. Built on Checkov (Apache-2.0).
Apply the mechanically-safe fixes from scan_terraform to Terraform source and return the patched HCL. Pass the file content plus the findings you want fixed (each as {check_id, resource_address}). Only fixes on the hand-verified allowlist are applied; everything else is returned in skipped with the reason, and must be applied by hand. Never overwrites a value that is wired to a variable or expression. Returns content — it does not write to disk.
| Name | Required | Description | Default |
|---|---|---|---|
| fixes | Yes | ||
| content | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses safety guarantees: only hand-verified allowlist fixes are applied, never overwrites variable/expression-wired values, returns patched HCL without writing to disk. This gives the agent a strong model of side effects and limitations.
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: three sentences front-load the core action and result, then add essential safety and return details. Every sentence adds value: input format, allowlist behavior, variable protection, and no-disk-write guarantee. No redundancy or 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 mutation tool with two parameters and no annotations, the description is complete: it specifies input format, the exact shape of fixes, safety filtering behavior, the skipped list with reasons, and the non-persisting return behavior. An output schema exists, so the return value description is sufficient. No critical operational detail 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 0%, so the description must compensate. It explains content as the file content and fixes as findings formatted as {check_id, resource_address}, which maps directly to the schema's array-of-objects property. It doesn't enumerate every edge case, but covers the essential meaning of both parameters.
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 precise verb and resource: 'Apply the mechanically-safe fixes from scan_terraform to Terraform source and return the patched HCL.' It clearly differentiates from sibling scan_terraform by focusing on applying fixes rather than scanning, and notes the non-destructive return behavior, making its role 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 gives clear context: use it with findings from scan_terraform and only for allowlisted, mechanically-safe fixes. It explains that unallowlisted findings are skipped and must be handled manually, but does not explicitly name an alternative tool for non-safe fixes, leaving that to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map Terraform findings to the compliance controls they speak to: SOC 2, ISO 27001, NIST 800-53, PCI-DSS, and the regulatory overlays DORA, NIS2, Saudi NCA Cloud Cybersecurity Controls and UAE NESA/SIA. Pass findings from scan_terraform, or files to scan and map in one call. Returns control mappings — evidence for an audit, never an attestation of compliance. Always relay the returned caveat to the user; do not present the result as a compliance verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | ||
| findings | No | ||
| frameworks | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It does this well by stating that returns are control mappings that are audit evidence, not an attestation of compliance, and by instructing to relay the caveat and avoid presenting as a compliance verdict. It could add read-only / side-effect disclosure, but nothing about the described behavior is hidden or contradictory.
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 the purpose front-loaded and no filler. The framework list is long but necessary for specificity, and the caveat instruction earns its place as a critical usage rule.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, both input paths, output semantics, and a user-facing caveat, while an output schema exists to document return values. The main remaining gap is precise parameter-level guidance for `frameworks` and the file input shape, but the tool can still be selected and invoked correctly from this description.
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 0%, so the description must compensate. It clarifies the intent of `findings` and `files`, and the first sentence implies what `frameworks` selects. However, it does not explain the format of the `files` object, the exact shape of `findings`, or whether `frameworks` is required / optional / defaults to all covered frameworks.
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 ('Map Terraform findings to the compliance controls they speak to') and enumerates the exact frameworks covered. It clearly distinguishes itself from scan_terraform by showing it maps existing findings or can accept files directly.
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?
Pass `findings` from scan_terraform, or `files` to scan and map in one call' gives explicit input modes and a clear when-to-use context. It does not explicitly name sibling alternatives like framework_coverage for when not to use this tool, but the guidance is specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full remediation for one finding from scan_terraform: what is wrong, the exact Terraform to fix it, and whether it is safe to apply mechanically. Call this for every finding you intend to fix instead of guessing the fix yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| check_id | Yes | ||
| resource_address | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It clearly describes what the tool returns and implies it is an explanatory, non-applying step, but it never explicitly states whether the tool has side effects, modifies state, or requires special permissions. This leaves some ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff: the first front-loads the tool's function and outputs, the second gives direct workflow guidance. Every sentence earns its place and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and the shape of its answer, but does not explain how to construct arguments for a specific finding. Since the schema provides no parameter descriptions and the tool has three parameters, this is a significant completeness gap despite the strong high-level explanation.
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 0%, and the description does not explain any of the three parameters beyond the bare name 'check_id.' It does not clarify how to reference a finding from scan_terraform, why title and resource_address are optional, or how they should be populated, so an agent is left to guess the parameter semantics.
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 ('Get') and resource ('full remediation for one finding from scan_terraform'), and enumerates the return content: what is wrong, the exact Terraform fix, and whether it is safe to apply mechanically. This is precise and distinguishes the tool from siblings like scan_terraform (which finds findings) and apply_fixes (which applies them).
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 for every finding you intend to fix instead of guessing the fix yourself,' giving a clear when-to-use instruction and warning against an alternative behavior. It does not explicitly list when not to use it or name sibling alternatives like apply_fixes, but the core usage context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For one regulatory framework (DORA, NIS2, NCA-CCC, NESA-IAS), list every article with whether automated configuration scanning can evidence it. Use this when the user asks how much of a regulation the tool covers — the not-evidenced articles are part of the honest answer and must be shown.
| Name | Required | Description | Default |
|---|---|---|---|
| framework | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses a key non-obvious behavior: 'the not-evidenced articles are part of the honest answer and must be shown'. It doesn't explicitly state side effects, but the list/report nature implies read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two terse sentences with no fluff. The core action is front-loaded and the usage trigger plus critical behavioral requirement each earn their 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 one-parameter reporting tool with an output schema, the description covers what it does, when to use it, and what the parameter values are. The output schema handles return structure, so nothing critical 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 schema provides no description or enums, but the description enumerates all valid framework values (DORA, NIS2, NCA-CCC, NESA-IAS). This fully compensates for the 0% schema coverage and tells the agent exactly what the single parameter accepts.
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 action: list every article for a regulatory framework with evidence status, and enumerates the four frameworks (DORA, NIS2, NCA-CCC, NESA-IAS). The title adds 'including what cannot be evidenced', making the scope explicit and distinguishing it from generic compliance check 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?
The description explicitly says to use it 'when the user asks how much of a regulation the tool covers', which is a clear usage trigger. It doesn't mention when-not-to-use or name alternatives, but the context is specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get this organization's own infrastructure policy requirements for a resource type — approved regions, required tags, mandatory settings — BEFORE writing the Terraform. Call this first whenever you are about to create a resource, so the code satisfies company policy on the first attempt rather than being corrected afterwards. Returns an empty, explanatory result when no organization policy is configured, which is normal and not an error.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | ||
| resource_type | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the behavioral disclosure burden. It discloses a non-obvious edge behavior: an empty explanatory result when no policy exists is normal, not an error. It also describes what the call returns conceptually. It could additionally state read-only/auth expectations, but the 'Get' semantics make these fairly inferable.
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 tightly packed sentences: purpose with examples, usage trigger with rationale, and edge-case behavior. The key verb and object appear in the first clause, and no sentence is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return shape, so the description need not restate it, and the empty-result behavior is well handled. Still, with no annotations and an undocumented 'provider' parameter, plus no sibling differentiation, the overall context is not fully complete for reliable tool selection and invocation.
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 0% description coverage, so the description must compensate for both parameters. It clarifies 'resource_type' indirectly through the phrase 'for a resource type' but never explains the 'provider' parameter, accepted values, or how the two parameters interact. This leaves a meaningful documentation gap.
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 and resource: 'Get this organization's own infrastructure policy requirements for a resource type' with concrete examples such as approved regions, required tags, and mandatory settings. The timing cue 'BEFORE writing the Terraform' also helps distinguish it from later-stage 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?
Explicitly directs when to use it: 'Call this first whenever you are about to create a resource' and explains the benefit of satisfying policy on the first attempt. However, it does not name alternatives or state when not to use this tool, so it falls just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report whether this install is applying an organization's custom policy or running built-in rules only, including the org name and rule count. Use it when the user asks which rules are in force, or why a company rule is not appearing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It conveys that this is a reporting/status operation and specifies the reported content, which implies non-mutating behavior, but it does not explicitly state edge cases, limitations, or what 'connected' means operationally. It is adequate but not rich.
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 with no filler. The core behavior is stated first, followed by concrete usage triggers. Everything 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?
Given the zero-parameter input, an output schema exists, and the description covers both the tool's behavior and when to invoke it, nothing essential is missing for correct selection and invocation.
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 and full schema coverage, so parameter-semantic burden is minimal. The description adds context about what the status output will contain, which is appropriate for a no-argument tool.
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 function: report whether the install applies an organization's custom policy or built-in rules, and identifies the included details (org name, rule count). It is clearly about policy status rather than scanning or fixing, though it does not explicitly name a sibling tool to differentiate itself from.
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 trigger conditions: use it when the user asks which rules are in force or why a company rule is not appearing. It does not mention alternatives or when not to use the tool, so it misses the full when/when-not contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan Terraform (HCL) for security misconfigurations and compliance failures. Call this after generating or editing any .tf content, before showing it to the user. Pass files (filename -> HCL content) to scan content that is not saved yet, or paths to scan .tf files and directories on disk. Runs locally; nothing is uploaded. Returns findings ordered by severity, each with a file, line, and whether an exact fix is available.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | ||
| paths | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and succeeds: it states 'Runs locally; nothing is uploaded' (privacy), describes the return as 'findings ordered by severity, each with a file, line, and whether an exact fix is available' (output shape), and implies a non-mutating scan. This goes beyond the schema and covers the main behavioral concerns an agent would have.
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 earning its place: purpose, when to call, parameter behavior, privacy, and return format. No filler or repetition 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?
For a two-parameter tool with no required fields and a stated output schema, the description provides the invocation trigger, parameter semantics, local execution guarantee, and result ordering in one compact block. Nothing necessary for correct use 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 coverage is 0%, yet the description defines both parameters operationally: `files` as 'filename -> HCL content' for unsaved content, and `paths` as 'scan .tf files and directories on disk.' This fully compensates for the empty schema and adds a decision criterion (saved vs unsaved).
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 'Scan Terraform (HCL) for security misconfigurations and compliance failures'—a specific verb, resource, and purpose. It further delimits scope by specifying .tf content and the two input modes, distinguishing it from human-oriented or fix-oriented siblings.
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 instructs 'Call this after generating or editing any .tf content, before showing it to the user,' giving a clear trigger condition and input choice between files and paths. It does not name sibling alternatives or exclusionary conditions, but the usage context is strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a security-hardened Terraform template for a resource type (for example 'aws_s3_bucket', 'aws_db_instance', 'aws_security_group', 'azurerm_storage_account', 'google_storage_bucket'). Prefer this over writing the resource from memory: provider defaults are frequently insecure, and every template here is test-verified to contain no Critical or High findings. Returns the Terraform plus notes on what deliberately still needs the user's input.
| Name | Required | Description | Default |
|---|---|---|---|
| resource_type | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states that templates are 'test-verified to contain no Critical or High findings' and that the tool returns Terraform plus notes on what still needs user input. This conveys safety, reliability, and limitations beyond the basic 'Get' action.
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 deliver purpose, usage guidance, and output expectation with no filler. The action and examples are front-loaded, and each 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?
The tool has a single parameter and an output schema, so the description does not need to detail return fields. It covers what the tool produces, why to use it, and what remains for the user to provide, which is sufficient for an agent to invoke 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?
The schema provides no description for resource_type, so the description must compensate. It clarifies the expected value with five concrete examples across AWS, Azure, and GCP, giving an agent enough grounding to populate the only parameter correctly.
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: 'Get a security-hardened Terraform template for a resource type,' with concrete examples such as 'aws_s3_bucket' and 'azurem_storage_account.' This makes the tool's purpose unmistakable and clearly distinguishes it from sibling tools like scan_ferraform or explain_finding, which address different tasks.
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 advises 'Prefer this over writing the resource from memory' and gives the rationale that provider defaults are frequently insecure. This is clear usage context, though it does not enumerate exclusions or explicitly compare against sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct output and role in the workflow, and the descriptions clarify boundaries well. The only mild overlap is check_compliance being able to scan files itself, which slightly overlaps scan_terraform, but the stated purposes remain clear.
Names mix imperative verb_noun patterns like scan_terraform, explain_finding, and apply_fixes with noun-phrase names like framework_coverage, org_requirements, and org_status. All names are readable and consistently snake_case, but there is no single predictable naming convention across the set.
Eight tools is a well-scoped count for this server's purpose. Each tool contributes to a clear workflow covering policy lookup, template generation, scanning, remediation, compliance mapping, and runtime status.
The tool surface covers the main Terraform security workflow end to end: plan, generate, scan, explain, fix, and map to compliance frameworks. Minor gaps exist, such as no way to enumerate supported secure_template resource types and framework_coverage only addressing four of the frameworks that check_compliance references.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Threat modeling, code/cloud/pipeline scanning, shadow-AI discovery, compliance checks and fixes.
Security reviews for coding agents: diffs checked against your org policy and live infrastructure.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
AI pentesting: run scans, triage vulnerabilities, review PRs, manage schedules and assets.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kraken222/sovereign-observer-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
