Infraveil MCP server

Official

by infraveilhq

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool has a distinct purpose: policy evaluation, fleet status, trace retrieval, security events, truth graph, remediation proposal, and deploy request. No overlap in functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case, such as evaluate_deploy_gate, get_agent_status, and request_deploy.
Tool Count5/5
With 7 tools, the server is well-scoped for infrastructure management, covering monitoring, policy evaluation, and gated actions without being excessive.
Completeness4/5
The tools cover core workflows: status queries, policy checks, security findings, and action requests. Minor gaps exist (e.g., no cancel or direct management), but the set is comprehensive for a control plane.
Average 4.4/5 across 7 of 7 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on June 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.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?
Explicitly declares 'Read-only', which is a key behavioral trait. However, no mention of authorization needs, rate limits, or data freshness. With no annotations, the description carries full burden and is somewhat minimal.
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: first states purpose, second explains limit. No extraneous words, front-loaded with core information.
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?
For a simple tool with one parameter and an output schema (not shown), the description covers purpose, behavior, and parameter meaning. Could mention error handling or range validation, but overall sufficient.
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 only parameter 'limit' is well-described: 'max number of recent events to return (1-500)'. This adds meaning beyond the raw schema, which has 0% coverage and only specifies type and default.
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?
Clearly states it returns active security policy and recent security events (blocked IPs, threat scores, pipeline findings). Distinguishes from siblings like evaluate_deploy_gate or get_agent_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Lacks explicit when-to-use or when-not-to-use conditions.
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?
Explicitly states 'Read-only', clearly indicating no side effects. Though no annotations are provided, the description covers the key behavioral trait. Further context (authentication, rate limits) is not critical for a read-only status tool.
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 concise sentences with front-loaded key information. Every word is meaningful; no redundancy.
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?
Describes the main data fields and behavior. With an output schema available, the agent can rely on that for detailed return structure. The description is sufficiently complete for a no-parameter tool.
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?
No parameters exist, so schema coverage is 100%. The description confirms the tool requires no input, adding no additional parameter meaning, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the current runtime status of the fleet, listing specific data types (agents, hosts, states, metrics, deploy state). This distinguishes it from sibling tools like 'request_deploy' or 'remediate', which involve actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for monitoring fleet status but does not explicitly state when to use this tool versus alternatives, nor when not to use it. Given its simplicity, the implied usage is adequate.
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 full behavioral burden. It correctly labels the operation as 'read-only' and describes the contents of the traces (proxied, acted on, outcome). This is transparent, though it could mention any side effects or access requirements, but none are apparent.
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 concise: two sentences plus a parameter detail. The main purpose is front-loaded, and every sentence adds value. No redundancy or waste.
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?
Given the presence of an output schema, return values are covered. The description explains what traces contain. For a simple retrieval tool with one parameter, it is mostly complete. It could mention if ordering or other filters exist, but not necessary.
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 input schema has one parameter (limit) with no description. The tool's description adds significant meaning: 'max number of trace entries (1-200)', clarifying the range and purpose beyond the schema's default. It compensates for the 0% schema coverage.
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 clearly states the tool retrieves recent request/operation traces for client's agents, specifying what is included (proxied, acted on, outcome). The verb 'get' in the name and the contextual detail distinguish it from siblings like get_agent_status or get_security_findings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance for the 'limit' parameter (max 1-200), but does not specify when to use this tool versus alternatives or any prerequisites. No explicit when-to-use or when-not-to-use context is given.
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?
No annotations are provided, so the description carries the full burden. It clearly discloses that the tool enqueues a deploy request, requires human approval, and returns a request ID and approval URL. It does not discuss authorization, rate limits, or failure modes, but the core behavior is well described.
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 focused paragraphs: first explaining the tool's purpose and behavior, second listing the parameters. Every sentence adds value and is front-loaded with key information. No extraneous content.
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 an output schema (not shown but indicated), so return values do not need description. The description fully covers purpose, behavior (no deploy, enqueue, human approval), and both parameters. Given the tool's simplicity (2 params), the description is sufficiently complete for an AI agent to use 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?
Schema coverage is 0%, so the description must explain parameters. It describes 'summary' as a required short description of what to deploy/why, and 'details' as optional longer context for the human approver. This adds meaningful context beyond the schema's bare property names, though more detail on format or constraints would be helpful.
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 explicitly states it requests a deploy and does NOT deploy, enqueuing into a human-approval queue. It distinguishes itself from a direct deploy action, and the sibling tools (evaluate_deploy_gate, remediate, etc.) are clearly different in functionality.
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 clearly states that it does not deploy but enqueues for human approval, telling the agent when to use this tool (intent to request deploy) and when not (if immediate deploy is needed, a different tool would be required). However, it doesn't explicitly list alternative sibling tools for comparison.
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?
Description explicitly states 'Read-only' and 'WITHOUT requesting a deploy', which is clear about non-destructive behavior. With no annotations, this adequately conveys safety profile, though it could detail output structure more.
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 plus parameter note. Every sentence is purposeful and front-loaded with key information. No redundancy.
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?
Describes purpose, usage, and parameter well. With an output schema present, the description is sufficient for selection and basic invocation. Minor gap: no explicit mention of error handling or output fields, but context signals indicate output schema may cover this.
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 has 0% coverage for 'summary', but description adds 'optional human description of the intended change', clarifying its purpose beyond the schema's title and default. This adds value.
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?
Description clearly states verb ('evaluate') and resource ('deploy gate') with specific outcome ('returns whether a proposed change would pass policy, and which checks gate it'). It distinguishes from sibling 'request_deploy' by emphasizing read-only evaluation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'reason before calling request_deploy'. Also implies not to use when deploying directly. The summary parameter's optionality is explained.
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?
The description explicitly states 'Read-only' and 'snapshot', key behavioral traits. No annotations are present, so the description carries the full burden and meets it well, though it could mention potential size or frequency of updates.
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 well-structured sentences, front-loading the core functionality and adding usage guidance with no wasted words.
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 tool has no parameters and an output schema (not shown but indicated), the description covers all needed aspects: content, usage context, and read-only nature.
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 tool has zero parameters and 100% schema coverage, so the description does not need to add parameter info. It correctly focuses on describing the output and purpose.
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 clearly states the tool returns a snapshot of the runtime truth graph, listing its contents (hosts, agents, services, policies). It distinguishes from sibling tools which either query specific entities or trigger actions.
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 advises using the tool to reason before acting, providing clear context. However, it does not explicitly name alternatives or state when not to use it.
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 discloses key behavioral traits: it enqueues a proposal for approval, never auto-applies, and respects blocked_categories. It also indicates the output (proposal id and approval URL). It could add more about failure modes or state changes, but is fairly transparent.
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 concise (5 lines) and well-structured, with the purpose stated first. Every sentence adds value without repetition or fluff.
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 tool's simplicity (2 parameters, no nested objects, has output schema), the description covers purpose, parameters, behavioral constraints, and output. It is complete for an agent to use correctly without additional context.
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%, but the description thoroughly explains both parameters: 'finding: id or description of what to remediate (required)' and 'action: ''propose'' (default) to queue a proposal for approval.' This adds significant meaning beyond the schema's type-only definitions.
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 clearly states the tool's purpose: 'Request remediation of a security finding or incident.' It uses a specific verb ('request remediation') and resource ('security finding/incident'), and implicitly distinguishes from sibling tools like get_security_findings which are read-only.
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 explains that the tool respects blocked_categories, is human-approval-gated, enqueues a proposal, and never auto-applies. This provides clear when-to-use and when-not-to-use guidance, though it doesn't explicitly name alternative tools for auto-remediation.
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:

[![infraveil-mcp MCP server](https://glama.ai/mcp/servers/infraveilhq/infraveil-mcp/badges/card.svg)](https://glama.ai/mcp/servers/infraveilhq/infraveil-mcp)

Score Badge

Copy to your README.md:

[![infraveil-mcp MCP server](https://glama.ai/mcp/servers/infraveilhq/infraveil-mcp/badges/score.svg)](https://glama.ai/mcp/servers/infraveilhq/infraveil-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/infraveilhq/infraveil-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server