sovereign

by kraken222

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation4/5
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.
Naming Consistency3/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.3/5 across 8 of 8 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![sovereign-observer-mcp MCP server](https://glama.ai/mcp/servers/kraken222/sovereign-observer-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kraken222/sovereign-observer-mcp)

Score Badge

Copy to your README.md:

[![sovereign-observer-mcp MCP server](https://glama.ai/mcp/servers/kraken222/sovereign-observer-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kraken222/sovereign-observer-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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