How do I use Infraveil MCP server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Infraveil MCP server Show my active security findings" 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.

Infraveil MCP server

Official

by infraveilhq

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

Infraveil MCP server

A hardened, self-hosted Model Context Protocol server that lets your own AI agent query and govern your Infraveil control plane in-loop — read the governed state of your backend, and file deploy and remediation requests that always pass through human approval.

It is built on the same principle as the rest of Infraveil: trust by inspection, not assertion. This server adds no new authority and no new auth surface. It signs every request with the token your agent already holds, and it verifies the control plane's signed responses in return — so neither side can be forged on the wire. You can read every line here and diff the signing code against the published agent source; they are the same scheme.

Why this exists

The MCP ecosystem's security is, bluntly, bad — most public MCP servers require no auth at all. An MCP server that hands an AI agent operational reach into your backend is exactly the thing that should not be unauthenticated. This one:

Signs both directions (HMAC-SHA256 over a canonical request/response, keyed by your per-agent token; nonce + timestamp replay protection).
Cannot apply a change by itself. request_deploy and remediate enqueue a request into the control plane's human-approval queue and return the approval URL. There is no code path here that mutates your infrastructure.
Is least-privilege. The token is scoped to one client/agent; tenancy is enforced by the control plane. This process holds no more authority than the agent already running on the host.

Related MCP server: ops-copilot-mcp

Install

pip install infraveil-mcp

Configure

The server reuses your existing Infraveil agent identity — it never mints credentials. Either set the environment variables:

export INFRAVEIL_BASE_URL=https://api.infraveil.com
export INFRAVEIL_CLIENT_ID=...
export INFRAVEIL_AGENT_ID=...
export INFRAVEIL_AGENT_TOKEN=...        # your agent's existing token

…or point it at your rendered agent source and let it read the ids and token straight out of the file you can already inspect:

export INFRAVEIL_AGENT_FILE=/opt/infraveil/agent.py

Claude Desktop / Claude Code

{
  "mcpServers": {
    "infraveil": {
      "command": "infraveil-mcp",
      "env": {
        "INFRAVEIL_BASE_URL": "https://api.infraveil.com",
        "INFRAVEIL_CLIENT_ID": "...",
        "INFRAVEIL_AGENT_ID": "...",
        "INFRAVEIL_AGENT_TOKEN": "..."
      }
    }
  }
}

Tools

Read (no side effects):

Tool	What it returns
`get_agent_status`	Fleet/agent state: online/offline, heartbeats, CPU/mem/disk, deploy state
`get_security_findings`	Active security policy + recent security events
`get_request_trace`	Recent request/operation traces and outcomes
`query_runtime_truth_graph`	Authoritative host ↔ agent ↔ service ↔ policy snapshot

Governed (enqueue for human approval — never auto-applied):

Tool	What it does
`evaluate_deploy_gate`	Reports whether a proposed change would pass policy. Read-only.
`request_deploy`	Files a deploy request into the approval queue; returns request id + approval URL
`remediate`	Files a remediation proposal (respects your blocked categories); returns id + approval URL

Verify it yourself

Read infraveil_mcp/client.py. The request-signing and response-verification code is plain stdlib hmac/hashlib.
Diff it against the published Infraveil agent source (_signed_headers, verify_response_signature). They implement the same protocol.
Run the test suite: pytest tests/. It transcribes the server's verifier and asserts this client's signatures are accepted and tampering is rejected.

License

AGPL-3.0-or-later. The control plane (central authority graph, multi-tenant policy, audit/evidence store) is the commercial product; the code that runs on your machine is open because you should never have to trust code you can't read.

Available Tools

7 tools

evaluate_deploy_gateA

Evaluate the deploy gate WITHOUT requesting a deploy: returns whether a proposed change would pass policy, and which checks gate it. Read-only — use this to reason before calling request_deploy.

summary: optional human description of the intended change.

ParametersJSON Schema

Name	Required	Description	Default
`summary`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

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.

get_agent_statusA

Current runtime status of this client's fleet: agents, launcher hosts, online/offline state, recent heartbeats, CPU/memory/disk, and deploy state. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

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.

get_request_traceA

Recent request/operation traces the control plane recorded for this client's agents — what was proxied, what was acted on, and the outcome. Read-only.

limit: max number of trace entries (1-200).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

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.

get_security_findingsA

Active security policy plus the most recent security events (blocked IPs, threat scores, pipeline findings) for this client. Read-only.

limit: max number of recent events to return (1-500).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

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.

query_runtime_truth_graphA

A snapshot of the runtime truth graph: the authoritative relationships between hosts, agents, deployed services, and the policies governing them. This is the governed reality your agent should reason about before acting. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

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.

remediateA

Request remediation of a security finding or incident. Respects the client's blocked_categories and is human-approval-gated: it enqueues a remediation proposal, never auto-applies. Returns the proposal id and approval URL.

finding: id or description of what to remediate (required). action: 'propose' (default) to queue a proposal for approval.

ParametersJSON Schema

Name	Required	Description	Default
`finding`	Yes
`action`	No		propose

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

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.

request_deployA

Request a deploy. This does NOT deploy — it enqueues a deploy request into the control plane's human-approval queue and returns a request id plus the approval URL a human must visit to approve. This server cannot apply a deploy on its own.

summary: short description of what to deploy / why (required). details: optional longer context for the human approver.

ParametersJSON Schema

Name	Required	Description	Default
`summary`	Yes
`details`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.1.1Jun 19, 2026
- First observedevaluate_deploy_gate
- First observedget_agent_status
- First observedget_request_trace
- First observedget_security_findings
- First observedquery_runtime_truth_graph
- First observedremediate
- First observedrequest_deploy

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

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.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
IdentArk Gateway
io.identark
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Security Agent Orchestration
29
PlanWrightOAuth
tools.planwright
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
Project Management Autonomous Agents
27
Elicitly Pro AOAuth
ai.elicitly
Human-in-the-loop for AI agents over MCP: durable approvals with a hosted review page & audit trail
Agent Orchestration Developer Tools Workplace & Productivity
121

Related MCP Servers

gov-mcp
Security Autonomous Agents
liuhaotian2024-prog
A
license
Not graded
quality
C
maintenance
An MCP server that enforces runtime governance on AI agent actions — file access, command execution, delegation chains, and permission escalation.
Updated 4 months ago (2026-05-08 00:25 UTC)
MIT
ops-copilot-mcp
Virtualization Command Line
mariuszbyahoo
F
license
A
quality
B
maintenance
A self-hosted MCP server providing a governed interface for AI agents to interact with local Docker infrastructure, featuring a two-phase confirm protocol for state-changing operations and append-only audit logging.
Updated 2 months ago (2026-06-28 10:32 UTC)
4
-
GitHub Flow MCP
Version Control CI/CD & DevOps Developer Tools
thiagorchaves
A
license
C
quality
B
maintenance
A policy-aware MCP server for GitHub and GitHub Actions that enables safe AI-assisted infrastructure workflows—inspecting repositories, preparing branches and pull requests, and constrained remote mutations behind explicit preview-bound approval tokens.
Updated 22 days ago (2026-08-17 00:15 UTC)
18
MIT
MCP Control Plane
Cloud Platforms Security Agent Orchestration
tusharporwal1092-wq
F
license
Not graded
quality
C
maintenance
A hardened MCP gateway that lets AI agents securely call infrastructure APIs like Kubernetes, Terraform, and Jenkins, with authentication, rate limiting, and OPA policy enforcement.
Updated 18 days ago (2026-08-21 17:42 UTC)
-

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