PolicyGuard

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a distinct and clearly defined purpose: create_policy defines policies, get_audit_log retrieves logs, get_compliance_status provides reports, register_agent manages agents, report_incident logs incidents, and validate_action checks permissions. There is no overlap or ambiguity in their functions.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., create_policy, get_audit_log, register_agent). The verbs are appropriate and descriptive, and there are no deviations or mixed conventions, making the set highly predictable.
Tool Count5/5
With 6 tools, the server is well-scoped for agent governance and security policy management. Each tool serves a clear role in the lifecycle (e.g., policy creation, agent registration, action validation, incident reporting, auditing, and compliance), with no redundant or missing tools.
Completeness5/5
The tool set provides complete coverage for the security policy domain: create_policy for policy management, validate_action for enforcement, get_audit_log and get_compliance_status for monitoring, register_agent for agent setup, and report_incident for incident handling. There are no obvious gaps, enabling full agent governance workflows.
Average 4.3/5 across 6 of 6 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool retrieves (audit log entries with specific filters) and includes return format details, which is helpful. However, it lacks critical behavioral traits: it doesn't mention whether this is a read-only operation, if it requires specific permissions, rate limits, pagination behavior beyond the 'limit' parameter, or error conditions. The description adds value but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose statement, parameter documentation, return format, and examples. It's appropriately sized for a 5-parameter tool with output details. While efficient, the initial purpose sentence could be more front-loaded with key distinguishing information, and some sections (like the Returns block) are slightly verbose but still valuable.
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 tool's moderate complexity (5 parameters, no annotations, but has output schema), the description is reasonably complete. It fully documents parameters and return format, and the output schema reduces the need to explain return values in detail. However, it lacks behavioral context (permissions, safety, rate limits) and sibling differentiation, which are important gaps for a compliance/investigation tool.
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 description coverage is 0%, so the description must fully compensate. It does this excellently: it documents all 5 parameters with clear semantics, optional/default status, allowed values (e.g., time_range options, status values), and practical examples. The description adds substantial meaning beyond what the bare schema provides, making parameters fully understandable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve audit log entries for compliance and investigation.' It specifies the verb ('Retrieve') and resource ('audit log entries'), and mentions the system context ('Guardian Agent'). However, it doesn't explicitly differentiate from sibling tools like 'get_compliance_status' or 'report_incident', which might have overlapping compliance/investigation domains.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_compliance_status' or 'validate_action', nor does it specify prerequisites, exclusions, or typical use cases beyond generic 'compliance and investigation'. The examples show how to call it, but not when it's the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a write operation ('Create or update') and describes the policy structure, but doesn't mention important behavioral aspects like authentication requirements, rate limits, idempotency, or what happens when updating existing policies versus creating new ones. The example helps but doesn't cover all 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, args, returns, example) and front-loads the core purpose. While comprehensive, some sentences could be more concise (e.g., the rules explanation is detailed but necessary given complexity). No wasted text, though the formatting with line breaks could be optimized for pure conciseness.
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 6-parameter mutation tool with no annotations, the description provides substantial context including parameter details, return format, and a complete example. The presence of an output schema reduces the need to fully document return values. The main gap is lack of behavioral context around permissions, side effects, and error conditions, but overall it's quite complete for the tool's complexity.
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?
Given 0% schema description coverage, the description provides excellent parameter semantics that fully compensate. It documents all 6 parameters with clear explanations, including detailed breakdown of the complex 'rules' parameter structure with its nested condition and action components. Default values for 'priority' and 'enabled' are explicitly stated, and the example demonstrates proper usage.
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 with specific verbs ('Create or update') and resource ('security policy for agent governance'). It distinguishes itself from sibling tools like get_audit_log or report_incident by focusing on policy creation/update rather than retrieval or reporting functions.
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 context through the explanation of what policies do ('define rules that control what agents can do'), but doesn't explicitly state when to use this tool versus alternatives. No guidance is provided about prerequisites, dependencies, or specific scenarios where this tool should be selected over other policy-related tools (though none appear in the sibling list).
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 carries full burden and does well by disclosing key behavioral traits: it's a read-only operation (implied by 'Get' and 'Generates'), describes the report content structure, mentions default values for parameters, and provides example usage patterns. However, it doesn't mention potential limitations like rate limits, authentication requirements, or data freshness constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, args, returns, examples) and appropriately sized. Every sentence adds value, though the example section could be slightly more concise. The information is front-loaded with the core purpose stated first, followed by supporting details.
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 complexity (3 parameters, no annotations, but has output schema), the description is complete enough. It explains the purpose, parameters, return structure, and provides usage examples. The output schema existence means the description doesn't need to exhaustively document return values, and it provides adequate context for an agent to understand and use the tool effectively.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation in the 'Args' section, including all 3 parameters with their purposes, acceptable values, and defaults. It adds substantial meaning beyond what the bare schema provides, explaining what each parameter controls in the compliance report generation.
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 with specific verbs ('Get compliance status and security health metrics', 'Generates a compliance report') and resources ('policy violations, security incidents, overall governance health'). It distinguishes from siblings like 'get_audit_log' or 'report_incident' by focusing on comprehensive compliance assessment rather than logging or incident reporting.
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 through the example scenarios ('Get daily compliance status', 'Get weekly report with all details'), but doesn't explicitly state when to use this tool versus alternatives like 'get_audit_log' or 'validate_action'. It provides context about time periods and detail levels but lacks explicit guidance on tool selection among siblings.
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 carries the full burden of behavioral disclosure. It effectively describes key behaviors: this is a registration/mutation operation (implied by 'register'), it affects trust levels and tool permissions, and it returns a structured JSON result. It doesn't mention authentication requirements, rate limits, or error conditions, but provides substantial operational context beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose statement, parameter explanations, return format, and example. While somewhat lengthy, every sentence adds value. The front-loaded purpose statement is strong, though the detailed parameter explanations could be more concise while maintaining clarity.
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 complexity (7 parameters, mutation operation), no annotations, and the presence of an output schema, the description provides comprehensive context. It explains the tool's purpose, all parameters with semantics, the return format, and includes a practical example. The output schema means the description doesn't need to detail return values, and it adequately covers what's needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must fully compensate. It provides detailed semantic explanations for all 7 parameters, including examples, format requirements (e.g., 'JSON array', 'JSON object'), and allowed values for 'trust_level'. This adds significant value beyond the bare schema, making parameter usage clear and actionable.
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: 'Register a new agent with Guardian for security policy evaluation.' It specifies the verb ('register'), resource ('agent'), and context ('Guardian for security policy evaluation'), distinguishing it from sibling tools like 'create_policy' or 'get_audit_log' which handle different security functions.
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 provides clear context for when to use this tool: to register agents for security policy evaluation, with implications about trust levels and tool permissions. It mentions that 'Unregistered agents are treated as 'low' trust,' which helps understand the consequences of not using it. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it logs incidents for investigation and tracking, and the 'Returns' section details outcomes like incident ID generation, success status, and potential agent suspension. This covers key behavioral aspects without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, usage, arguments, returns, and an example. It is appropriately sized for a 6-parameter tool, though it could be slightly more concise by integrating the example more tightly. Every sentence adds value, such as clarifying parameter options and output format.
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 complexity (6 parameters, no annotations, but with an output schema), the description is highly complete. It explains the tool's purpose, usage, all parameters in detail, return values, and includes a practical example. The output schema is referenced in the 'Returns' section, making the description comprehensive for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate fully. It does so by providing detailed semantics for all 6 parameters, including enumerated values for 'incident_type' and 'severity', and clear explanations for others like 'description' and 'evidence'. This adds significant value beyond the basic schema.
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: 'Report a security incident for investigation and tracking.' It specifies the verb ('report') and resource ('security incident'), and distinguishes it from siblings like 'create_policy' or 'get_audit_log' by focusing on incident reporting rather than policy management or log retrieval.
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 provides clear context for when to use the tool: 'Use this tool to log security incidents such as policy violations, suspicious agent behavior, or potential security threats.' It lists specific incident types, giving practical guidance. However, it does not explicitly state when not to use it or name alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates this is a security validation tool that returns structured decisions (allowed/require_approval) and generates audit correlation IDs. However, it doesn't mention potential side effects like audit logging, rate limits, or authentication requirements that might be relevant for security tools.
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 well-structured and front-loaded with the core purpose and usage guidance, followed by organized parameter documentation and a complete example. Every sentence adds value: the security gate positioning, the workflow guidance, parameter explanations, return format details, and illustrative example all serve distinct purposes without redundancy.
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 security-critical nature, 5 parameters with 0% schema coverage, and no annotations, the description provides comprehensive context. It explains the tool's role in the security workflow, documents all parameters with examples, details the return format (though an output schema exists), and includes a complete usage example. This fully compensates for the lack of structured metadata.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter explanations with examples for all 5 parameters. Each parameter gets clear semantic meaning beyond the basic schema types (e.g., action_type examples like 'tool_call', 'resource_access'; target examples like 'tool name', 'resource URI'; parameters as 'JSON string of action-specific parameters').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('validate whether an agent can perform a specific action') and distinguishes it from siblings by emphasizing it's the 'PRIMARY security gate' for pre-action compliance checks. It explicitly differentiates from audit/logging tools like get_audit_log and policy management tools like create_policy.
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?
The description provides explicit guidance on when to use this tool ('BEFORE performing any sensitive action') and why ('to ensure compliance with security policies'). It establishes a clear workflow relationship with other tools by positioning this as a prerequisite gatekeeper function.
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:

[![policyguard MCP server](https://glama.ai/mcp/servers/PrateekKumar1709/policyguard/badges/card.svg)](https://glama.ai/mcp/servers/PrateekKumar1709/policyguard)

Score Badge

Copy to your README.md:

[![policyguard MCP server](https://glama.ai/mcp/servers/PrateekKumar1709/policyguard/badges/score.svg)](https://glama.ai/mcp/servers/PrateekKumar1709/policyguard)

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/PrateekKumar1709/policyguard'

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