One MCP server. Three policy engines. Zero context-switching.
PolicyPulse unifies OPA/Gatekeeper, Kyverno, and Azure Policy behind a single interface — so you can ask your AI assistant about your real compliance posture in plain English, from any MCP-compatible client.
Modern Kubernetes environments run multiple policy engines simultaneously:
OPA Gatekeeper — admission control, on-prem and hybrid
Kyverno — policy-as-code for AKS, EKS, and GKE
Azure Policy — compliance scanning across your entire Azure subscription
Each engine has its own API, its own violation format, and its own compliance framework mapping. Platform engineers switch between three dashboards, two CLIs, and the Azure Portal just to answer: "Are we compliant?"
Related MCP server: code-guard-ai
PolicyPulse normalizes all three engines into 7 MCP tools. Ask your AI assistant:
"What are my most critical violations across all engines?" "Check this deployment manifest before I push it." "Which violations map to PCI-DSS requirements?" "Explain this violation and tell me how to fix it."
MCP Clients (Claude, Cursor, GitHub Copilot, Cline, Windsurf, Continue.dev, Zed)
│
│ stdio (local) ──or── SSE over HTTPS (enterprise / Container Apps)
▼
┌───────────────────────────────────────┐
│ PolicyPulse MCP │
│ │
│ ┌─────────────────────────────────┐ │
│ │ Intelligence Layer │ │
│ │ risk summary · explain · │ │
│ │ prioritize · framework enrich │ │
│ └──────────┬──────────────────────┘ │
│ │ Violation / Policy │
│ ┌──────────┴──────────────────────┐ │
│ │ Normalized Schema │ │
│ └──┬───────────┬──────────────┬───┘ │
│ │ │ │ │
│ ┌──┴──┐ ┌─────┴──┐ ┌───────┴──┐ │
│ │ GK │ │Kyverno │ │ Azure │ │
│ │ │ │ │ │ Policy │ │
│ └──┬──┘ └────┬───┘ └────┬─────┘ │
└─────┼──────────┼───────────┼─────────┘
│ │ │
AKS/k8s AKS/k8s Azure Subscription
Constraints PolicyReports PolicyInsights APIThe control catalog is the single source of truth — it powers both runtime enrichment of live violations with CIS/PCI-DSS/NIST/SOC 2 references, and the pre-deployment static gate that checks YAML manifests with no cluster required.
Tool | What it does |
| Which engines are connected; fleet overview with auth mode per cluster; credential type |
| All policies across engines; filter by engine |
| All violations enriched with framework refs; filter by namespace / engine / severity / cluster |
| Cross-engine risk summary with regulatory impact |
| Plain English explanation + framework mapping + remediation steps for one violation |
| Pre-deploy static gate — paste YAML, get violations, no cluster needed |
| Full 9-control catalog with CIS / PCI-DSS / NIST 800-53 / SOC 2 mappings |
No cluster or Azure credentials needed:
git clone https://github.com/raviteja-pegata/policy-pulse-mcp
cd policy-pulse-mcp
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
POLICYPULSE_DEMO=true policy-pulse-mcp# Kyverno
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
helm install kyverno kyverno/kyverno -n kyverno --create-namespace
# OPA Gatekeeper
helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm install gatekeeper/gatekeeper --name-template=gatekeeper \
-n gatekeeper-system --create-namespace
# Apply demo policies and workloads (wait 2-3 min for audit reports)
kubectl apply -f demo-cluster/kyverno-policies.yaml
kubectl apply -f demo-cluster/gatekeeper-policies.yaml
kubectl apply -f demo-cluster/non-compliant-workloads.yamlpip install -e ".[all]"
az aks get-credentials --resource-group <rg> --name <cluster>
AZURE_SUBSCRIPTION_ID=<sub-id> \
AZURE_CREDENTIAL_TYPE=cli \
policy-pulse-mcpPolicyPulse can query multiple clusters in a single session. Every violation includes a cluster field so you can filter by cluster when querying.
There are two ways to specify clusters depending on where you're hosting PolicyPulse:
Mode | Context format | When to use |
Kubeconfig |
| Local dev, or kubeconfig mounted into the pod |
Workload Identity |
| Hosted on Container Apps or AKS — no kubeconfig file needed |
Pull credentials for each cluster, then point PolicyPulse at multiple contexts in a single kubeconfig:
az aks get-credentials --resource-group rg-prod --name aks-prod
az aks get-credentials --resource-group rg-staging --name aks-staging
POLICYPULSE_CLUSTERS=prod:aks-prod,staging:aks-staging \
AZURE_SUBSCRIPTION_ID=<sub-id> \
policy-pulse-mcpThe context name (aks-prod, aks-staging) must match a context in your ~/.kube/config.
Use the resourceGroup/clusterName format. PolicyPulse calls the Azure management API to fetch each cluster's API server URL and CA certificate, then authenticates using a managed identity token — no kubeconfig file is needed anywhere.
POLICYPULSE_CLUSTERS=prod:rg-prod/aks-prod,staging:rg-staging/aks-staging \
AZURE_SUBSCRIPTION_ID=<sub-id> \
AZURE_CREDENTIAL_TYPE=managed_identity \
policy-pulse-mcpFull setup for this is in the Workload Identity Setup section below.
For enterprise deployments, run PolicyPulse as an SSE server on Azure Container Apps. This lets multiple teams and tools connect to one centrally managed compliance server over HTTPS.
stdio | SSE | |
Transport | Local pipe | HTTP / HTTPS |
Clients | One (local process only) | Many (concurrent) |
Auth | None | Bearer token / Azure AD |
Hosting | Developer laptop only | Container Apps, AKS, any cloud |
Best for | Local dev, Claude Desktop | Enterprise, CI/CD, multi-team |
docker build -t policypulse-mcp:latest .
az acr login --name <your-acr>
docker tag policypulse-mcp:latest <your-acr>.azurecr.io/policypulse-mcp:latest
docker push <your-acr>.azurecr.io/policypulse-mcp:latestaz containerapp create \
--name policy-pulse-mcp \
--resource-group <your-rg> \
--environment <your-aca-environment> \
--image <your-acr>.azurecr.io/policypulse-mcp:latest \
--target-port 8000 \
--ingress external \
--env-vars \
POLICYPULSE_TRANSPORT=sse \
AZURE_SUBSCRIPTION_ID=<sub-id> \
AZURE_CREDENTIAL_TYPE=managed_identity \
POLICYPULSE_CLUSTERS=prod:rg-prod/aks-prod,staging:rg-staging/aks-stagingUsing
resourceGroup/clusterNameformat forPOLICYPULSE_CLUSTERSactivates Workload Identity mode — no kubeconfig file is needed in the container.
az containerapp identity assign \
--name policy-pulse-mcp \
--resource-group <your-rg> \
--system-assigned
PRINCIPAL_ID=$(az containerapp identity show \
--name policy-pulse-mcp \
--resource-group <your-rg> \
--query principalId -o tsv)Then follow the Workload Identity Setup section to grant the identity access to each AKS cluster.
PolicyPulse needs to reach each AKS API server from Container Apps:
# Option A: VNet integration (recommended for production)
# Create the Container Apps environment on the same VNet as your AKS clusters.
az containerapp env create \
--name policy-pulse-env \
--resource-group <your-rg> \
--location eastus \
--infrastructure-subnet-resource-id <subnet-id>
# Option B: Public AKS — whitelist the Container App outbound IP
ACA_IP=$(az containerapp show \
--name policy-pulse-mcp \
--resource-group <your-rg> \
--query properties.outboundIpAddresses[0] -o tsv)
az aks update \
--name aks-prod \
--resource-group rg-prod \
--api-server-authorized-ip-ranges $ACA_IPYour SSE endpoint will be:
https://policy-pulse-mcp.<unique-id>.eastus.azurecontainerapps.io/sseThis section covers everything needed for the resourceGroup/clusterName cluster format — the recommended approach for Container Apps and AKS-hosted deployments.
When PolicyPulse sees POLICYPULSE_CLUSTERS=prod:rg-prod/aks-prod, it:
Calls the Azure management API with a management-plane token to fetch the cluster's API server URL and CA certificate.
Gets a second token scoped to the AKS AAD server application (audience 6dae42f8-4368-4678-94ff-3960e28e3630).
Builds the Kubernetes client from those two pieces — no kubeconfig file anywhere.
PolicyPulse (Container App or AKS pod)
│
│ managed identity token
▼
Azure AD
│
├──► management.azure.com → listClusterUserCredential
│ (gets API server URL + CA cert)
│
└──► AKS API server (each cluster)
"I am identity X — is my token valid?"
"Yes — you have view access — here are your violations"Each target AKS cluster must have AAD integration enabled. This is the default for clusters created from 2021 onwards. To verify:
az aks show --resource-group rg-prod --name aks-prod \
--query "aadProfile" -o json
# Should return a non-null objectThe managed identity needs permissions at two levels: the Azure management plane (to fetch cluster credentials) and inside each Kubernetes cluster (to read policy resources).
The identity needs to be able to call listClusterUserCredential on each target cluster, and to read Azure Policy compliance state.
PRINCIPAL_ID=<principal-id-of-your-managed-identity>
SUB_ID=<your-subscription-id>
# Azure Policy — read compliance state across the subscription
az role assignment create \
--assignee $PRINCIPAL_ID \
--role "Policy Insights Data Reader (Preview)" \
--scope /subscriptions/$SUB_ID
# AKS — fetch cluster credentials (repeat for each target cluster)
az role assignment create \
--assignee $PRINCIPAL_ID \
--role "Azure Kubernetes Service Cluster User Role" \
--scope /subscriptions/$SUB_ID/resourceGroups/rg-prod/providers/Microsoft.ContainerService/managedClusters/aks-prod
az role assignment create \
--assignee $PRINCIPAL_ID \
--role "Azure Kubernetes Service Cluster User Role" \
--scope /subscriptions/$SUB_ID/resourceGroups/rg-staging/providers/Microsoft.ContainerService/managedClusters/aks-stagingOnce the management-plane token gets PolicyPulse into the API server, Kubernetes still checks its own RBAC. The approach depends on whether your cluster uses Azure RBAC or local RBAC.
Check which mode your cluster uses:
az aks show --resource-group rg-prod --name aks-prod \
--query "aadProfile.enableAzureRbac" -o tsv
# true = Azure RBAC mode, false/null = local RBAC modeAzure RBAC mode (recommended for new clusters):
Azure RBAC roles map directly to Kubernetes RBAC — no kubectl commands needed inside the cluster.
# Grant read access to Gatekeeper and Kyverno resources (repeat per cluster)
az role assignment create \
--assignee $PRINCIPAL_ID \
--role "Azure Kubernetes Service RBAC Reader" \
--scope /subscriptions/$SUB_ID/resourceGroups/rg-prod/providers/Microsoft.ContainerService/managedClusters/aks-prod
az role assignment create \
--assignee $PRINCIPAL_ID \
--role "Azure Kubernetes Service RBAC Reader" \
--scope /subscriptions/$SUB_ID/resourceGroups/rg-staging/providers/Microsoft.ContainerService/managedClusters/aks-stagingLocal RBAC mode (older clusters):
You need to create a ClusterRoleBinding inside each cluster using the identity's client ID (not the principal/object ID).
# Get the client ID of the managed identity
CLIENT_ID=$(az identity show \
--name <your-managed-identity-name> \
--resource-group <your-rg> \
--query clientId -o tsv)
# Run this for each target cluster
az aks get-credentials --resource-group rg-prod --name aks-prod
kubectl create clusterrolebinding policypulse-reader \
--clusterrole=view \
--user="$CLIENT_ID"The
viewClusterRole gives read-only access to most resources including the custom resources that Gatekeeper and Kyverno write their violations to.
Set these environment variables on your Container App or pod:
AZURE_SUBSCRIPTION_ID = <your-subscription-id>
AZURE_CREDENTIAL_TYPE = managed_identity
POLICYPULSE_CLUSTERS = prod:rg-prod/aks-prod,staging:rg-staging/aks-stagingFor a user-assigned managed identity, also set:
AZURE_CLIENT_ID = <client-id-of-the-user-assigned-identity>Once the server is running, call cluster_status. The response shows the auth mode for each cluster:
{
"fleet": [
{ "label": "prod", "context": "rg-prod/aks-prod", "auth": "workload_identity" },
{ "label": "staging", "context": "rg-staging/aks-staging", "auth": "workload_identity" }
]
}If "auth" shows "workload_identity" and the cluster appears in connected_engines, the setup is complete.
Symptom | Likely cause | Fix |
| Missing env var | Set |
| Missing | Run Step 1 role assignments |
| Missing k8s RBAC | Run Step 2 for the cluster |
| AAD integration not enabled | Enable with |
| Kubeconfig returned no CA | Check cluster health; fallback uses unverified TLS |
~/Library/Application Support/Claude/claude_desktop_config.json (macOS)
%APPDATA%\Claude\claude_desktop_config.json (Windows)
{
"mcpServers": {
"policy-pulse": {
"command": "/path/to/.venv/bin/python",
"args": ["-m", "policy_pulse_mcp.server"],
"env": {
"AZURE_SUBSCRIPTION_ID": "your-sub-id",
"AZURE_CREDENTIAL_TYPE": "cli"
}
}
}
}{
"mcpServers": {
"policy-pulse": {
"url": "https://policy-pulse-mcp.<unique-id>.eastus.azurecontainerapps.io/sse"
}
}
}Open Settings → MCP → Add Server:
{
"policy-pulse": {
"command": "python",
"args": ["-m", "policy_pulse_mcp.server"],
"env": { "AZURE_SUBSCRIPTION_ID": "your-sub-id" }
}
}For enterprise SSE: { "url": "https://..." }
Add to .vscode/mcp.json in your workspace:
{
"servers": {
"policy-pulse": {
"type": "sse",
"url": "https://policy-pulse-mcp.<unique-id>.eastus.azurecontainerapps.io/sse"
}
}
}For local stdio:
{
"servers": {
"policy-pulse": {
"type": "stdio",
"command": "python",
"args": ["-m", "policy_pulse_mcp.server"],
"env": { "AZURE_SUBSCRIPTION_ID": "your-sub-id" }
}
}
}~/.continue/config.json:
{
"mcpServers": [
{
"name": "policy-pulse",
"command": "python",
"args": ["-m", "policy_pulse_mcp.server"],
"env": { "AZURE_SUBSCRIPTION_ID": "your-sub-id" }
}
]
}Cline extension → MCP Servers → Add:
{
"policy-pulse": {
"command": "python",
"args": ["-m", "policy_pulse_mcp.server"],
"env": { "AZURE_SUBSCRIPTION_ID": "your-sub-id" }
}
}Windsurf Settings → MCP → Add server:
{
"policy-pulse": {
"serverType": "stdio",
"command": "python",
"args": ["-m", "policy_pulse_mcp.server"],
"env": { "AZURE_SUBSCRIPTION_ID": "your-sub-id" }
}
}~/.config/zed/settings.json:
{
"context_servers": {
"policy-pulse": {
"command": {
"path": "python",
"args": ["-m", "policy_pulse_mcp.server"],
"env": { "AZURE_SUBSCRIPTION_ID": "your-sub-id" }
}
}
}
}Variable | Default | Description |
|
|
|
|
|
|
|
| SSE server bind address |
|
| SSE server port (also accepts |
|
| Log level ( |
Variable | Default | Description |
|
| Path to kubeconfig file (used in kubeconfig mode only) |
| (single cluster) | Comma-separated list. Two formats supported: |
Variable | Required | Description |
| For Azure Policy and workload identity | Subscription to query for policy compliance |
| No (default: |
|
| For | Azure AD tenant ID |
| For | Client or identity ID |
| For | Client secret |
Local development:
az login
AZURE_CREDENTIAL_TYPE=cli policy-pulse-mcpCI/CD — service principal:
AZURE_CREDENTIAL_TYPE=service_principal \
AZURE_TENANT_ID=<tenant-id> \
AZURE_CLIENT_ID=<client-id> \
AZURE_CLIENT_SECRET=<secret> \
policy-pulse-mcpProduction on Container Apps / AKS — managed identity:
AZURE_CREDENTIAL_TYPE=managed_identity policy-pulse-mcpRequired Azure roles for the managed identity:
Role | Scope | Purpose |
| Subscription | Read Azure Policy compliance state |
| Each AKS cluster | Fetch cluster credentials via management API |
| Each AKS cluster | Read Gatekeeper/Kyverno resources (Azure RBAC clusters) |
For clusters using local RBAC instead of Azure RBAC, see Step 2 of Workload Identity Setup.
pip install policy-pulse-mcp # core only (demo + static gate)
pip install "policy-pulse-mcp[kubernetes]" # + Gatekeeper + Kyverno
pip install "policy-pulse-mcp[azure]" # + Azure Policy
pip install "policy-pulse-mcp[all]" # everythingFrom source:
git clone https://github.com/raviteja-pegata/policy-pulse-mcp
cd policy-pulse-mcp
python -m venv .venv && source .venv/bin/activate
pip install -e ".[all]"git clone https://github.com/raviteja-pegata/policy-pulse-mcp
cd policy-pulse-mcp
python -m venv .venv && source .venv/bin/activate
pip install -e ".[all,dev]"
make test # 87 tests, fully offline, ~0.3s
make demo-server # POLICYPULSE_DEMO=true
make lint
make fmtget_violation_history — compliance drift over time
check_resource_compliance — point query for a specific Azure resource
Multi-subscription Azure support
Helm chart for in-cluster deployment
PyPI publish
YAML-driven catalog extensions — add controls without writing Python
search_catalog tool
GitHub Actions pre-deploy gate example
generate_remediation_manifest
create_exemption_request
trigger_azure_remediation_task
MIT — see LICENSE.
Static policy check for a Kubernetes manifest (YAML or JSON) — no cluster needed.
| Name | Required | Description | Default |
|---|---|---|---|
| manifest | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states it's a 'static policy check' without explaining what policies are checked, whether it is read-only, or any side effects. This is insufficient for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every word adds value.
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 single parameter and no output schema, the description should hint at the return value (e.g., compliance report). It does not, leaving the agent uncertain about output format.
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%, but the description adds meaning by specifying acceptable formats (YAML or JSON) for the manifest parameter, compensating partially. However, no examples or constraints are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'check' and the resource 'Kubernetes manifest (YAML or JSON)', with the qualifier 'static policy check' and 'no cluster needed', which distinguishes it from sibling tools like cluster_status.
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 implies offline use by saying 'no cluster needed', but does not explicitly state when to use this tool versus alternatives like list_controls or get_violations. It provides some context but lacks clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which policy engines are connected and whether demo mode is active.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 implies a read-only operation but does not explicitly state side effects, permissions, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, precise sentence with no unnecessary words, making it highly concise.
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 zero-parameter status tool, the description adequately informs the agent about the output content. However, lacking an output schema, a bit more detail on the response format would be beneficial.
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?
There are no parameters, and schema coverage is 100%. The description adds no parameter information, which is appropriate for a zero-parameter 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 clearly states that the tool returns which policy engines are connected and whether demo mode is active. It distinguishes itself from sibling tools focused on compliance and policies.
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 provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plain-English explanation of one violation with framework mapping and remediation.
| Name | Required | Description | Default |
|---|---|---|---|
| violation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states what the tool returns (explanation, framework mapping, remediation) but does not disclose idempotency, side effects, authentication needs, or error behavior. For a read tool, more context on output format or limitations is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of 10 words, front-loading the key action. It contains no wasted words. However, it could be slightly improved by incorporating the parameter or using structured text, but it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description is minimal. It does not clarify what 'framework mapping' or 'remediation' entails, nor the output structure. The agent lacks sufficient information to fully understand the tool's behavior without calling it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter violation_id. The tool description does not add any meaning beyond the schema; it fails to explain format, source, or expected values. The agent must infer from the parameter name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'Plain-English explanation of one violation with framework mapping and remediation.' It specifies the verb 'explain', the resource 'violation', and details the content. This distinguishes it from siblings like get_violations (list) and get_compliance_risk_summary (summary).
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 implies use for detailed explanation of a single violation, but it does not explicitly state when to use it versus alternatives such as get_violations or get_compliance_risk_summary. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cross-engine risk summary: severity breakdown, top risks, and regulatory impact.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states the tool's output content (severity breakdown, top risks, regulatory impact) but does not disclose read-only nature, authentication needs, rate limits, or any side effects. Minimal disclosure.
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?
A single sentence that directly conveys the tool's purpose and key outputs. No redundancy or extraneous information. Front-loaded and efficient.
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?
Without an output schema, the description provides a reasonable expectation of the returned content. It mentions three key aspects. However, it could be more precise (e.g., format, aggregation level) but is adequate for a zero-parameter summary tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. The description adds value by explicitly listing the summary components (severity breakdown, top risks, regulatory impact), giving meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'cross-engine risk summary' with components like severity breakdown, top risks, and regulatory impact. It implies a aggregated view, differentiating from siblings like get_violations (individual violations) and list_controls (controls). However, it doesn't explicitly distinguish from cluster_status which might also be a summary.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention scenarios, prerequisites, or exclusions. Siblings exist but no comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All active violations enriched with compliance framework refs.
namespace: restrict to a specific Kubernetes namespace. engine: one of gatekeeper, kyverno, azure_policy. min_severity: only return violations at or above this level (critical → info). cluster: restrict to a specific cluster label (multi-cluster mode only).
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | ||
| engine | No | ||
| min_severity | No | ||
| cluster | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states the result type ('enriched active violations') and parameter effects, but omits traits like read-only nature, rate limits, or authentication requirements.
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 extremely concise: one sentence explaining the output, followed by a bullet list of parameters. No redundant information, and the key purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 optional parameters, no output schema, and no annotations, the description adequately covers the tool's purpose and parameter semantics. It could mention potential result limits but is otherwise sufficient for a filtered-list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description adds essential meaning: it explains 'namespace' as a Kubernetes namespace, 'engine' lists valid string values (gatekeeper, kyverno, azure_policy), 'min_severity' defines ordering (critical to info), and 'cluster' clarifies multi-cluster usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'all active violations enriched with compliance framework refs', specifying the resource and scope. It is distinct from sibling tools like 'explain_violation' or 'get_compliance_risk_summary', which handle different aspects.
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 does not provide guidance on when to use this tool versus its siblings, such as for a summary vs. detailed list. No context on typical use cases or alternatives is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full compliance control catalog with framework mappings and remediation guidance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or side effects. It only states what the tool contains, not how it behaves (e.g., whether it fetches live data or cached).
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?
Single sentence, no filler, front-loaded with the core purpose. Every word is relevant and informative.
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 tool with no parameters and no output schema, the description is minimally adequate. It explains the resource type and content, but misses context like whether results are paginated, sorted, or filtered. Could mention if it returns all controls or supports querying.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description bears no burden for parameter explanations. Baseline score of 4 is appropriate as the description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'full compliance control catalog' with 'framework mappings and remediation guidance,' specifying the resource and additional content. However, it does not explicitly distinguish from sibling tools like 'list_policies' or 'get_compliance_risk_summary', though the focus on controls is unique.
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?
No guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, filters, or scenarios where this tool is preferred. Siblings like 'check_manifest_compliance' or 'get_violations' suggest different use cases, but no explicit direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all policies across connected engines, optionally filtered by engine name.
| Name | Required | Description | Default |
|---|---|---|---|
| engine | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It implies a read-only list operation but does not describe pagination, performance, or return format. The lack of output schema exacerbates this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 12 words, front-loading the core action and resource. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low complexity (1 optional param), the description is minimally adequate. It defines purpose and parameter but lacks output details (e.g., structure of policy objects) and filtering behavior.
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 description adds meaning to the single parameter 'engine' by stating it is an optional filter by engine name. Since schema coverage is 0%, this is valuable. However, it does not specify valid engine name format or values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'policies', and the scope 'across connected engines'. It distinguishes from sibling tools like list_controls or cluster_status by focusing on policies.
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?
No guidance on when to use this tool vs alternatives like list_controls or explain_violation. The description only implies use when listing policies, without exclusion criteria or context.
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 clearly distinct purpose: static manifest check, cluster status, violation explanation, risk summary, violation listing, control catalog listing, and policy listing. No overlapping responsibilities.
Most tools follow a verb_noun pattern (check, explain, get, list). 'cluster_status' deviates by using a noun_noun form without a verb, but it remains clear and snake_case consistent.
7 tools is well-scoped for a policy compliance server, covering static checks, violation retrieval, explanation, summary, and catalog listing without being excessive or insufficient.
Covers core read and analysis operations (check, list, get, explain, summary, status). Minor gaps exist (no detailed policy view, no write operations) but these are likely out of scope for a read-focused compliance tool.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Fail-closed policy guardrails for AI agents running kubectl, terraform, helm, and argocd.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
Security gateway for AI agents: policy, approval, and audited execution, no secrets shared.
Threat modeling, code/cloud/pipeline scanning, shadow-AI discovery, compliance checks and fixes.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/raviteja-pegata/policy-pulse-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
