A
licenseB
qualityF
maintenanceA lightweight bridge that wraps OpenAI's built-in tools (like web search and code interpreter) as Model Context Protocol servers, enabling their use with Claude and other MCP-compatible models.
4
12
MIT
Correctover MCP Server
Officialby Correctover
The Correctover MCP Server acts as an intelligent intermediary that validates LLM responses in real-time across six dimensions and automatically self-heals through retries or failover to ensure reliable AI outputs.
Core Validation (6 Dimensions): Structure (JSON/YAML well-formedness, required fields), Schema (type correctness, enum compliance), Latency (SLA thresholds), Cost (token usage/budget), Identity (model/provider match), and Integrity (content tampering, hash verification).
Tools:
chat— Send messages to LLMs with automatic 6-dimension validation and failover. Supports specifying provider, model, temperature, max tokens, and system prompts; returns a detailed validation report.health— Check availability and status of all configured LLM providers before use.providers— View supported providers (OpenAI, Anthropic, DeepSeek, Groq, Alibaba Qwen, Zhipu/GLM, SiliconFlow, Together, Moonshot/Kimi, etc.) with default models, base URLs, and configuration status.stats— Review session metrics: total API calls, validation pass rate, failover count, active providers, and server version.validation_history— Paginate through up to 500 recent validation records (newest first), each showing provider, model, latency, pass/fail status, score, and failure reasons.
Prompts: Pre-built prompts for verifying AI output (verify-output), comparing providers (compare-providers), and running reliability audits (reliability-audit).
BYOK (Bring Your Own Key): API keys stay on your machine — no proxying or data collection.
Provides integration with OpenAI's API for chat completion with automatic verification and self-healing.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Correctover MCP Serververify the AI output for correctness and completeness"
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.
Correctover — MCP Runtime Security
The runtime security layer for the MCP ecosystem.
We build the runtime security layer for AI agent ecosystems. Correctover enforces security conformance on every MCP tool call — validating LLM outputs, blocking injection attacks, preventing credential hijacking, and auto-recovering from failures at 22μs P50 latency.
What We Do
Layer | What | Where |
Runtime Verification | 6-dimension output validation (structure, schema, latency, cost, identity, integrity) + auto-failover |
|
Agent Governance SDK | Synchronous interceptor-based governance — fail-closed by design |
|
Security Audits | MCP protocol vulnerability research — CVE-class findings across 50+ implementations | |
Conformance Standard | CCS v1.0 — formal standard for agentic runtime verification | |
Fault Taxonomy | 215 fault types, 19 CVEs, 561 fault variants cataloged | Internal knowledge base |
Related MCP server: Kluster.ai Verify MCP
Real Data — Not Benchmarks
We don't simulate. We collect real API responses from production MCP servers and verify them.
20,000 Verified API Traces
Dataset | Records | Size | Format |
CCS 20K Verification Subset | 20,000 | 18 MB | JSONL (download) |
Collection methodology:
43.6 minutes of continuous collection at 13.7 API calls/second
68.88% conformance rate (13,776 conformant / 6,224 non-conformant)
30% fault injection rate for stress testing
Every record includes: request, response, latency, validation result, fault classification
Third-party independent verification: 120,426 conformance re-calculations by @babyblueviper1 — full consistency confirmed.
The complete 20K dataset is in ./data/ — download, verify, fork, do whatever you want. No gatekeeping.
Research & Publications
CCS v1.0 — Runtime Security Conformance Standard
The first formal conformance standard defining how agent runtimes should validate tool execution results at runtime.
Key findings from 20K real traces:
P50 validation latency: 22μs
Self-heal rate: 97.4% (engine auto-retries/fails over on failed validation, then re-validates)
Rule coverage: 88 detection rules (64 high-confidence)
561 distinct fault variants cataloged across all major LLM providers
Fault Taxonomy
We maintain a living fault taxonomy derived from real-world MCP server failures:
215 distinct fault types classified across 7 severity levels
19 CVE-class vulnerabilities identified across MCP implementations
Categories: RCE, SSRF, cloud credential hijacking, path traversal, output injection, privilege escalation
Upstream PR Contributions
We don't just report — we fix. Our contributions go directly into major agent frameworks:
PR | Framework | Status | What |
Ferro Labs | OPEN | Runtime validation integration | |
CrewAI | 10 commits | GuardrailProvider — runtime governance protocol | |
CrewAI | Discussion | Defining runtime verification authority | |
Microsoft | Under review | Runtime threat scanner — recursive nested-arg scanning, SSRF gaps, credential redaction, path boundary fixes |
Community Validation
Real researchers using our work in production:
Researcher | Framework | Contribution |
@pshkv (AutoGen maintainer) | AutoGen | Adopted Required(τ)⊆Supported(τ) framework for tool governance |
CrewAI | Testing two-layer governance structure | |
CrewAI | Implemented GuardrailProvider based on our design (10 commits) | |
Independent | 120,426 independent conformance re-calculations | |
PHI-OMEGA | ICLR paper collaboration on runtime verification | |
CrewAI | Idempotency analysis and interaction |
MCP Server — Product
The runtime verification engine packaged as an MCP server for your AI tools.
Quick Start
npm install -g correctover-mcp-serverAdd to your mcp.json (Cursor, Claude Desktop, Windsurf):
{
"mcpServers": {
"correctover": {
"command": "correctover-mcp-server",
"env": {
"OPENAI_API_KEY": "sk-...",
"ANTHROPIC_API_KEY": "sk-ant-..."
}
}
}
}BYOK — your keys stay on your machine. No proxy, no data collection.
How It Works
Your AI Tool (Cursor / Claude Desktop / Windsurf)
│
▼
┌─────────────────────────────┐
│ Correctover MCP Server │
│ ┌───────────────────────┐ │
│ │ 6-Dim Validator │ │
│ │ ├─ Structure │ │
│ │ ├─ Schema │ │
│ │ ├─ Latency │ │
│ │ ├─ Cost │ │
│ │ ├─ Identity │ │
│ │ └─ Integrity │ │
│ └───────────────────────┘ │
│ │ │
│ ┌──────▼──────┐ │
│ │ Failover │ │
│ │ Engine │ │
│ └──────┬──────┘ │
└──────────┼──────────────────┘
│
┌──────┼──────┬──────────┐
▼ ▼ ▼ ▼
OpenAI Anthropic DeepSeek Qwen ...Supported Providers
Provider | Models | Env Variable |
OpenAI | GPT-4o, GPT-4o-mini, o1 |
|
Anthropic | Claude 3.5 Sonnet, Haiku, Opus |
|
DeepSeek | DeepSeek-V3, DeepSeek-R1 |
|
Moonshot/Kimi | Moonshot-v1 |
|
Alibaba Qwen | Qwen-Max, Qwen-Plus |
|
Groq | Llama, Mixtral |
|
Together | Llama, Mistral |
|
Tools
Tool | Description |
| Verified chat — 6-dim validation + auto-failover |
| Check provider status |
| Detailed provider configuration |
| Session metrics: calls, pass rate, failover count |
| Query recent validation results (ring buffer, 500 records) |
Ecosystem Adoption
Real download numbers from public package registries (last 30 days):
Package | Registry | Monthly Downloads |
correctover-mcp-server | npm | 1,564 |
correctover | npm | 1,034 |
correctover-ccs | npm | 400 |
correctover | PyPI | 1,436 |
Total | 4,434/month |
All organic growth — no paid promotion. CCS standard package seeing highest growth rate (tens of thousands percent increase from baseline).
CCS SDK — Agent Governance
Python SDK for embedding governance into agent frameworks. Fail-closed by design.
pip install correctover-ccsfrom ccs import govern
@govern(policy="default")
def my_tool(args: dict) -> str:
return "result"
# Governance evaluates BEFORE function runs
# If denied → PermissionError, function never executesSupported frameworks: CrewAI, AutoGen, LangGraph/LangChain
Observer hooks (default): governance_crash → tool EXECUTES ❌
CCS decorators (ours): governance_crash → tool BLOCKED ✅Security Audit Reports
We publish detailed security audits of MCP server implementations:
Methodology: Source code analysis → fault injection → runtime verification → CVE classification
Findings to date: 506 security findings across 3 major repositories, 5 vulnerability types confirmed cross-repo.
Ecosystem & Links
Resource | Link |
CCS Standard (paper) | |
CCS Standard (GitHub) | |
MCP Server (npm) | |
CCS SDK (PyPI) | |
Security Audits | |
Agent Governance | Correctover/agent-governance-toolkit (fork with PRs) |
Glama | |
Protocol Spec | |
Website |
Contact
Security reports: wangguigui@correctover.com
BD / Enterprise: wangguigui@correctover.com
GitHub: @Correctover
License
Apache 2.0 © Correctover
Available Tools
5 toolschatARead-only
Send a chat message to an LLM with automatic output verification. Routes through the best available provider, validates the response across 6 dimensions (structure, schema, latency, cost, identity, integrity), and auto-heals on failure by retrying or failing over to another provider. Returns the response text plus a validation report showing which dimensions passed or failed.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name or 'auto' for automatic provider selection. Examples: 'gpt-4o-mini', 'claude-3-haiku-20240307', 'deepseek-chat'. Default: 'auto'. | |
| messages | Yes | Conversation messages in OpenAI format: [{role: 'user', content: '...'}, ...]. Each message must have 'role' (system/user/assistant) and 'content' (string). | |
| provider | No | Force a specific provider: 'openai', 'anthropic', 'deepseek', 'moonshot', 'zhipu', 'qwen', 'siliconflow', 'groq', 'together'. If omitted, auto-selects by priority and health. | |
| max_tokens | No | Maximum tokens in response. Limits output length to control cost and latency. | |
| temperature | No | Sampling temperature (0.0-2.0). Lower values for more deterministic output. Default: provider-specific. | |
| system_prompt | No | System prompt to prepend to the conversation. Useful for setting context, role, or output format requirements. |
TDQS
A3.6/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotation readOnlyHint=true by stating it sends a chat message, which is a write operation. Despite providing additional behavioral details like auto-healing, the contradiction reduces transparency score to 1 per rules.
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 three sentences long, front-loads the main action, and every sentence adds value without redundancy. It is highly efficient.
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?
The description covers key aspects: what it does, routing, validation, auto-heal, and return type. However, it lacks details on error handling and the exact structure of the validation report. Given no output schema, slightly more detail would improve completeness.
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?
With 100% schema description coverage, the baseline is 3. The description does not add new meaning beyond the schema; it only summarizes the tool's behavior. No per-parameter elaboration.
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: sending a chat message with automatic output verification. It distinguishes itself from sibling tools (health, providers, stats, validation_history) which serve different 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 explains when to use the tool (for chat with verification) but lacks explicit guidance on when not to use it or alternatives. The context is clear, but no exclusions or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthARead-onlyIdempotent
Check health and availability of all configured LLM providers. Returns a list of active providers with their default models and session statistics. Call this first to verify your configuration before using the chat tool.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, destructiveHint; the description adds return info (list of active providers, models, session stats) but no additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second provides usage guidance. No redundant information, front-loaded and efficient.
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?
For a parameterless tool with comprehensive annotations, the description fully explains what the tool returns and when to use it. No gaps given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters defined, so baseline is 4 per guidelines. Description does not need to add parameter meaning.
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 verb 'Check' and the resource 'health and availability of all configured LLM providers', differentiating from siblings like 'providers' which might list all providers without health status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to 'Call this first to verify your configuration before using the chat tool', providing a clear when-to-use recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
providersARead-onlyIdempotent
List all supported LLM providers with their configuration details, default models, base URLs, and current status. Use this to see which providers are available, what model each uses by default, and whether custom base URLs are configured for proxy or mirror setups.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds no behavioral traits beyond listing contents; it doesn't disclose authentication needs or rate limits, but these are not critical for a read-only listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines the tool's output, second explains usage. No redundant information. Front-loaded with purpose.
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?
Despite no output schema, the description enumerates the returned items: configuration details, default models, base URLs, and current status. This is sufficient for an agent to understand the tool's return value. With zero parameters and good annotations, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters are defined (0 params), and schema coverage is 100% by absence. The description correctly avoids parameter details. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all supported LLM providers with specific details like configuration, default models, base URLs, and status. The verb 'List' and resource 'supported LLM providers' are unambiguous, and it differentiates from siblings like chat, health, stats, and validation_history.
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 explicitly tells when to use the tool: to see provider availability, default models, and custom base URLs for proxy/mirror setups. While it doesn't mention when not to use it, the context is clear and sufficient given the tool's simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
statsARead-onlyIdempotent
Show Correctover session statistics including total API calls, validation pass rate, failover count, active providers, and server version. Use this after a working session to review reliability metrics and see how many self-healing events occurred.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true, so the description adds value by explaining the specific statistics returned, including self-healing events, which implies the tool reports on automated recovery actions. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence clearly states the purpose and outputs, the second gives usage guidance. Every sentence earns its place.
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?
With no parameters, no output schema, and rich annotations, the description sufficiently explains what the tool returns (specific stats) and when to use it. Could mention if a session must be active, but the guidance 'after a working session' implies it works post-session, so adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% trivially. Per guidelines, baseline is 4 for no parameters. The description appropriately focuses on what the tool returns.
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 uses a specific verb 'Show' and resource 'Correctover session statistics', listing the included metrics. It clearly distinguishes itself from sibling tools like chat, health, providers, and validation_history by focusing on aggregate session-level statistics.
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 explicitly states to use the tool 'after a working session to review reliability metrics and see how many self-healing events occurred', providing clear context for when to invoke it. However, it does not mention when not to use it or compare with alternatives like the health tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validation_historyARead-onlyIdempotent
Query recent validation results with pagination. Returns the most recent LLM call validation records, newest first. Each record includes provider, model, latency, pass/fail status, validation score, and failure reasons. Use limit and offset to paginate through results. Default returns the 20 most recent records. Maximum 100 per page. The buffer holds up to 500 records; older entries are automatically overwritten.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of records to return (1-100). Default: 20. | |
| offset | No | Number of records to skip from the most recent. Use for pagination. Default: 0. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. Description adds that buffer holds 500 records and older entries are automatically overwritten, providing valuable behavioral context beyond annotations.
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?
Three sentences with no waste: first sentence states purpose and ordering, second lists return fields, third explains pagination. Front-loaded with key action.
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 simplicity (pagination, no output schema), the description covers return fields, pagination details, and buffer limit. Annotations handle safety. Complete enough for an agent to use correctly.
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 descriptions already cover limit and offset fully (100% coverage). The description reiterates defaults and max but adds minimal new meaning (e.g., offset for skipping from most recent). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries recent validation results with pagination, returns newest first, and lists specific fields. It distinguishes from sibling tools (chat, health, providers, stats) by focusing on validation history.
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?
Explicitly mentions using limit and offset for pagination, default 20, max 100. Does not state when not to use, but sibling tools are unrelated, so guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
5 tool updates
v1.0.4- First observed
chat - First observed
health - First observed
providers - First observed
stats - First observed
validation_history
TDQS
A4.3/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: chat for sending validated messages, health for checking provider availability, providers for listing all supported providers, stats for session statistics, and validation_history for reviewing past validation results. There is no overlap in functionality.
Naming Consistency5/5
All tool names follow a consistent pattern: single words or compound words with underscores (e.g., validation_history). They are all lowercase and descriptive of their function, making them easy to understand and predict.
Tool Count5/5
With 5 tools, the server is well-scoped for its purpose of managing LLM chat with validation and monitoring. Each tool covers a core aspect without being overly specialized or too sparse.
Completeness5/5
The tool surface covers the full lifecycle of interacting with LLM providers: checking configuration (health, providers), sending messages (chat), reviewing performance (stats), and auditing (validation_history). No obvious gaps are present for the stated purpose.
Maintenance
ActivityMaintained
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Fact-checks generated content against your sources of truth showing what to trust, change, & verify.
Preflight QA for AI-agent deliverables with structured verdicts and repair guidance.
Deterministic validation for AI-generated artifacts: JSON Schema, OpenAPI response, SQL syntax.
Real-time fact-check, citation verification, and source-freshness for AI agents.
Related MCP Servers
Kluster.ai Verify MCPofficial
AlicenseNot gradedqualityNot gradedmaintenanceEnables fact-checking of AI responses against reliable sources and validation of responses against document content to ensure accuracy and reliability.-- AlicenseNot gradedqualityDmaintenanceProvides real-time content security for large language models by identifying and intercepting risks across compliance, ethics, and safety dimensions. It enables secure input and output monitoring through a customizable policy engine using an SSE-based interface.1MIT
Arkheia Hallucinationofficial
AlicenseNot gradedqualityBmaintenanceDetect fabrication and hallucination in any LLM output. Score responses from GPT-4o, Claude, Gemini, Llama and 30+ models. Free tier included.1MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Correctover/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server