Which integrations are available for this server?

Optional integration for server-side natural language processing to transform natural language security requirements into Cerbos YAML policies using OpenAI GPT models.

How do I use GlassTape Policy Builder?

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., "@GlassTape Policy Builder create a policy for customer data access with role-based controls and audit logging" 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.

GlassTape Policy Builder

Official

by GlassTape

Overview Schema Related Servers Score Discussions

Python

Local

🧩 GlassTape Policy Builder MCP Server

License MCP Python

Transform natural language into production-ready AI governance policies.

GlassTape Policy Builder is an open-source MCP server that converts natural-language security requirements into Cerbos YAML policies with automated validation, testing, and red-teaming.
It enables security and engineering teams to integrate AI agents and applications with policy-as-code frameworks—bringing zero-trust guardrails to tool-call interception, data access, and model workflows.

🚀 Features

⚙️ Natural-Language to Policy – Generate Cerbos policies from plain English using Claude or AWS Q
🧠 Automated Validation – Uses the Cerbos CLI (cerbos compile, cerbos test) for syntax and logic checks
🧪 Red-Team Analysis – 6-point security analysis with automatic improvement suggestions
🧩 MCP Integration – Works natively in IDEs like Cursor, Zed, and Claude Desktop
🔒 Air-Gapped Operation – Local-first design with no external dependencies
🏷️ Topic-Based Governance – 40+ content topics with safety categorization
🧾 Compliance Templates – Built-in templates for SOX, HIPAA, PCI-DSS, and EU AI Act

Related MCP server: agent-sudo-mcp

🚀 Quick Start

1. Prerequisites

Install Cerbos CLI (required for policy validation):

# macOS
brew install cerbos/tap/cerbos

# Linux
curl -L https://github.com/cerbos/cerbos/releases/latest/download/cerbos_Linux_x86_64 \
  -o /usr/local/bin/cerbos && chmod +x /usr/local/bin/cerbos

# Verify installation
cerbos --version

2. Install from Source

# Clone the repository
git clone https://github.com/glasstape/glasstape-policy-builder-mcp.git
cd glasstape-policy-builder-mcp/agent-policy-builder-mcp

# Basic installation
pip install -e .

# With optional LLM support (for server-side natural language parsing)
pip install -e ".[anthropic]"  # Anthropic Claude
pip install -e ".[openai]"     # OpenAI GPT
pip install -e ".[llm]"        # All LLM providers

# Development installation
pip install -e ".[dev]"

3. Configure Your MCP Client

Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "glasstape-policy-builder": {
      "command": "glasstape-policy-builder-mcp"
    }
  }
}

Cursor/Zed: Add similar configuration in your IDE's MCP settings.

Optional: Server-side LLM (for natural language processing):

{
  "mcpServers": {
    "glasstape-policy-builder": {
      "command": "glasstape-policy-builder-mcp",
      "env": {
        "LLM_PROVIDER": "anthropic",
        "ANTHROPIC_API_KEY": "sk-ant-your-key"
      }
    }
  }
}

4. Usage Examples

Generate a Policy (in Claude Desktop or MCP-enabled IDE):

Create a payment policy for AI agents:
- Allow payments up to $50
- Block sanctioned entities
- Limit to 5 transactions per 5 minutes

List Available Templates:

list_templates

Validate a Policy:

validate_policy with policy_yaml: "<your-cerbos-yaml>"

5. Troubleshooting

Cerbos CLI not found:

Ensure Cerbos CLI is installed and in your PATH
Run cerbos --version to verify installation (note: --version not version)

MCP server not connecting:

Check your MCP client configuration
Restart your IDE after configuration changes
Verify the command path is correct: which glasstape-policy-builder-mcp

Installation fails with "Unable to determine which files to ship":

This is a known hatch build issue - ensure you're in the correct directory
The pyproject.toml should include [tool.hatch.build.targets.wheel] configuration

Import errors with MCP:

Ensure you have the correct MCP imports: from mcp.server import Server
Try reinstalling: pip install -e . --force-reinstall

Policy validation fails:

Check YAML syntax in generated policy
Ensure Cerbos CLI is working: cerbos compile --help
Review error messages for specific issues

Command not found after installation:

Ensure you have Python 3.10 or higher
Check that the entry point is correctly configured in pyproject.toml

🦭 Available Tools

When connected via MCP, you can use these tools in Claude or your IDE:

Tool	What it does
`generate_policy`	Transform natural language → validated Cerbos YAML with topic governance
`validate_policy`	Check policy syntax with `cerbos compile`
`test_policy`	Run test suites against policies with `cerbos compile`
`suggest_improvements`	6-point security analysis with automatic improvement suggestions
`list_templates`	Browse built-in templates (finance, healthcare, AI safety)

Example workflow:

1. "Generate a payment policy for AI agents with $50 limit..."
   → Claude calls generate_policy
   
2. "Show me available financial templates"
   → Claude calls list_templates
   
3. "Test this policy with the test suite"
   → Claude calls test_policy
   
4. "Analyze this policy for security issues"
   → Claude calls suggest_improvements
   
5. "Validate the policy syntax"
   → Claude calls validate_policy

🧪 Example Output

Input:

"Allow AI agents to execute payments up to $50. Block sanctioned entities. 
Limit cumulative hourly amount to $50. Maximum 5 transactions per 5 minutes."

Generated Policy with Topic Governance:

# policies/payment_policy.yaml
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: "1.0.0"
  resource: "payment"
  rules:
    - actions: ["execute"]
      effect: EFFECT_ALLOW
      condition:
        match:
          expr: >
            request.resource.attr.amount > 0 &&
            request.resource.attr.amount <= 50 &&
            !(request.resource.attr.recipient in request.resource.attr.sanctioned_entities) &&
            (request.resource.attr.cumulative_amount_last_hour + request.resource.attr.amount) <= 50 &&
            request.resource.attr.agent_txn_count_5m < 5 &&
            has(request.resource.attr.topics) &&
            "payment" in request.resource.attr.topics &&
            !("adult" in request.resource.attr.topics)
    - actions: ["*"]
      effect: EFFECT_DENY

Plus:

✅ Topic-based governance (payment, pii detection)
✅ Safety categorization (G/PG/PG_13/R/adult_content)
✅ 15+ automated test cases
✅ Validated by cerbos compile
✅ 6-point security analysis
✅ Ready-to-deploy bundle

📋 Complete Examples

Category	Example	Description
Finance	payment_policy.md	Payment execution with limits
Healthcare	phi_access_policy.md	HIPAA-compliant PHI access
AI Safety	ai_model_invocation_policy.md	Model invocation with guardrails
Data Access	pii_export_policy.md	GDPR-compliant PII export control
System	admin_access_policy.md	Admin access with MFA

See examples/README.md for complete examples.

🧱 Architecture

flowchart TD
  A["Natural-language policy request"] --> B["GlassTape MCP Server"]
  B --> C["Intermediate Canonical Policy - JSON"]
  C --> D["Cerbos YAML policy generation"]
  D --> E["Cerbos CLI validation + testing"]
  E --> F["Ready-to-deploy policy bundle"]

Key Innovation: ICP (Intermediate Canonical Policy) serves as a language-agnostic intermediate representation, enabling deterministic generation, policy portability, and formal verification.

🧪 Development

# Clone and setup
git clone https://github.com/glasstape/glasstape-policy-builder-mcp.git
cd glasstape-policy-builder-mcp
pip install -e ".[dev]"

# Run tests
pytest

# Format code
black src/ tests/

🤝 Contributing

We welcome contributions! See CONTRIBUTING.md for guidelines.

Quick Links:

💪 License

💡 Links

Built with ❤️ by GlassTape — Making AI agents secure by default.

Available Tools

5 tools

generate_policyA

Convert natural language guardrails into enterprise-grade Cerbos YAML policies

ParametersJSON Schema

Name	Required	Description	Default
`nl_requirements`	No	Plain English description of AI guardrail or security policy
`icp`	No	Structured policy JSON (for automation workflows)

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose error handling, rate limits, authentication needs, or what 'enterprise-grade' entails. The description adds minimal behavioral context beyond the basic function.

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?

Single sentence, zero waste, front-loaded with the core purpose. Every word earns its place without redundancy or unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 2 parameters, 100% schema coverage, but no annotations or output schema, the description is adequate but has gaps. It explains the transformation purpose but lacks details on behavioral traits, error cases, or output format, which would be helpful given the complexity of policy generation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are documented in the schema. The description doesn't add meaning beyond what the schema provides about 'nl_requirements' or 'icp'. Baseline 3 is appropriate when schema does the heavy lifting.

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 verb ('Convert') and resource ('natural language guardrails into enterprise-grade Cerbos YAML policies'). It distinguishes itself from siblings by focusing on generation rather than listing, suggesting, testing, or validating policies.

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 converting natural language to YAML policies, but doesn't explicitly state when to use this vs. alternatives like 'suggest_improvements' or 'test_policy'. No guidance on prerequisites or exclusions is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_templatesC

List available policy templates

ParametersJSON Schema

Name	Required	Description	Default
`category`	No

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action but doesn't describe what 'list' entails (e.g., format, pagination, sorting), whether it's read-only or has side effects, or any constraints like rate limits or authentication needs. This leaves significant gaps for a tool that likely returns data.

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 a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly, which is ideal for conciseness in tool descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain return values, behavioral traits, or parameter usage, leaving the agent with insufficient information to use the tool effectively beyond its basic purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 1 parameter with 0% description coverage, so the description must compensate. It mentions 'available policy templates' but doesn't explain the optional 'category' parameter or how filtering works. This adds minimal value beyond the schema's structure, failing to address the coverage gap adequately.

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 verb ('List') and resource ('available policy templates'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling operations like 'generate_policy' or 'test_policy' beyond the basic action, which prevents a perfect score.

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 like 'generate_policy' or 'validate_policy'. There's no mention of prerequisites, typical use cases, or exclusions, leaving the agent to infer usage context entirely from the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

suggest_improvementsC

Analyze policy for security issues and suggest improvements

ParametersJSON Schema

Name	Required	Description	Default
`policy_yaml`	Yes
`icp`	No	Optional ICP for enhanced analysis

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions analysis and suggestions but doesn't describe what the analysis entails, how suggestions are generated, whether it's read-only or has side effects, or any performance/rate limit considerations. This leaves significant gaps for a tool that analyzes security policies.

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 a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a tool with 2 parameters, though it could be more structured with separate purpose and usage sections.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a security analysis tool with 2 parameters (one complex nested object), no annotations, and no output schema, the description is inadequate. It doesn't explain what security issues are analyzed, what format improvements are suggested in, or how the optional 'icp' enhances analysis. More context is needed given the complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% (only 'icp' has a description), so the description should compensate but doesn't. It mentions 'policy' analysis but doesn't explain what 'policy_yaml' should contain or what 'icp' represents beyond the schema's 'Optional ICP for enhanced analysis'. The description adds minimal value beyond the schema.

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 with specific verbs ('analyze', 'suggest') and resource ('policy for security issues'), making it easy to understand what it does. However, it doesn't differentiate from sibling tools like 'validate_policy' or 'test_policy', which likely have overlapping security analysis functions.

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 like 'validate_policy' or 'test_policy'. It doesn't mention prerequisites, exclusions, or specific contexts where this analysis is preferred over other policy-related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

test_policyC

Run cerbos test on policy and test suite

ParametersJSON Schema

Name	Required	Description	Default
`policy_yaml`	Yes	Cerbos policy YAML content
`test_yaml`	Yes	Cerbos test suite YAML content

TDQS

C2.9/5.0

Behavior2/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 mentions 'Run cerbos test' but doesn't explain what this entails—e.g., whether it's a read-only operation, if it modifies data, what the output looks like, or any error conditions. This leaves significant gaps in understanding the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and target, making it easy to parse quickly without unnecessary details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of testing policies (which could involve validation, execution, or reporting), the description is incomplete. With no annotations and no output schema, it fails to explain what the tool returns (e.g., test results, errors) or behavioral traits like side effects. This makes it inadequate for an agent to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, clearly documenting both parameters as YAML content for policy and test suite. The description adds no additional meaning beyond this, as it doesn't elaborate on parameter formats, constraints, or examples. Baseline 3 is appropriate since the schema does the heavy lifting.

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 action ('Run cerbos test') and the target ('on policy and test suite'), which is specific and understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'validate_policy' or 'suggest_improvements', which might have overlapping purposes in the Cerbos policy testing domain.

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 like 'validate_policy' or 'suggest_improvements'. It lacks context about prerequisites, such as needing valid YAML content, or exclusions, leaving the agent to infer usage based on the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_policyC

Validate policy syntax using cerbos compile

ParametersJSON Schema

Name	Required	Description	Default
`policy_yaml`	Yes

TDQS

C2.8/5.0

Behavior2/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 mentions the validation action but fails to describe key traits such as whether it's read-only or destructive, what the output format is (e.g., success/failure, error details), or any rate limits or authentication needs. This leaves significant gaps for a tool that likely returns validation results.

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 a single, efficient sentence that directly states the tool's purpose without any fluff. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a validation tool with no annotations, no output schema, and low parameter coverage, the description is incomplete. It lacks information on behavioral traits, parameter details, and expected outputs, which are crucial for an agent to use the tool effectively in context with siblings like test_policy.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate for the undocumented parameter. It only implies that 'policy_yaml' is related to policy syntax validation but adds no details about the parameter's format, constraints, or examples (e.g., YAML structure, required fields). This is insufficient given the low coverage.

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 as validating policy syntax using a specific method (cerbos compile). It specifies the verb 'validate' and the resource 'policy syntax', though it doesn't explicitly differentiate from siblings like test_policy or suggest_improvements, which might have overlapping validation aspects.

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 such as test_policy or suggest_improvements. It lacks any context about prerequisites, typical use cases, or exclusions, leaving the agent to infer usage from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

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

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: generate_policy creates policies, list_templates shows templates, suggest_improvements analyzes policies, test_policy runs tests, and validate_policy checks syntax. The descriptions make it easy to differentiate between creation, listing, analysis, testing, and validation functions.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case (e.g., generate_policy, list_templates, suggest_improvements). The naming is predictable and readable throughout the set, with no deviations in style or convention.

Tool Count5/5

With 5 tools, the count is well-scoped for a policy builder domain, covering key operations like generation, templating, analysis, testing, and validation. Each tool earns its place without feeling excessive or insufficient for the server's purpose.

Completeness4/5

The tool set provides strong coverage for the policy lifecycle, including creation, validation, testing, and improvement suggestions. A minor gap exists in update or delete operations for policies, but agents can likely work around this by regenerating or modifying policies through other means.

Maintenance

ActivityInactive

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

Evidra
io.github.vitas
Fail-closed policy guardrails for AI agents running kubectl, terraform, helm, and argocd.
Autonomous Agents Security Cloud Platforms
2
agentlock
io.github.Olum289
Security gateway for AI agents: policy, approval, and audited execution, no secrets shared.
Security Agent Orchestration
2
AxioRank: Zero-Trust for AI Agents A
com.axiorank
Zero-trust gateway for AI agents: score tool calls, verify agent cards, enforce policy, audit.
Security Observability
222
boundaryai
ai.boundaryai
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
Security AI & Machine Learning Agent Orchestration
2

Related MCP Servers

aegis
Agent Orchestration Autonomous Agents Security
Acacian
A
license
A
quality
A
maintenance
Policy-based governance for AI agent tool calls. YAML policies, approval gates, risk assessment, and audit logging across LangChain, OpenAI, Anthropic, and MCP.
Updated 5 days ago (2026-08-29 14:36 UTC)
5
15
MIT
agent-sudo-mcp
Security Autonomous Agents
Kisyntra
A
license
A
quality
A
maintenance
Local zero-trust permission gateway for AI agents. Enforces policy-based tool authorization, human approvals, scoped permissions, and cryptographically verifiable audit logs.
Updated 24 days ago (2026-08-10 11:23 UTC)
4
5
Apache 2.0
Vaikora Guard MCPofficial
Data443
A
license
Not graded
quality
D
maintenance
Enforces deterministic policies on AI agent tool calls, evaluating actions against compliance modules (SOC 2, HIPAA, GDPR, etc.) and returning ALLOW, BLOCK, or CONSTRAIN decisions with an audit trail.
Updated 3 months ago (2026-05-26 17:12 UTC)
MIT
Phantom MCP
Penetration Testing Security
mokhalifa83
F
license
Not graded
quality
D
maintenance
Enables authorized compliance verification and security auditing through natural language, bridging AI assistants with industry-standard security tools for enterprise audits.
Updated 8 months ago (2026-01-16 02:02 UTC)
24

Appeared in Searches

Kyverno policy examples and documentation

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/GlassTape/agent-policy-builder-mcp'

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

🧩 GlassTape Policy Builder MCP Server

🚀 Features

🚀 Quick Start

1. Prerequisites

2. Install from Source

3. Configure Your MCP Client

4. Usage Examples

5. Troubleshooting

🦭 Available Tools

🧪 Example Output

📋 Complete Examples

🧱 Architecture

🧪 Development

🤝 Contributing

💪 License

💡 Links

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Vaikora Guard MCPofficial

Appeared in Searches

Latest Blog Posts

MCP directory API