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., "@Protocol-0 Simulate a CI/CD pipeline failure to assess impact"
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.
Most "AI operations" dashboards just show you graphs. Protocol-0 actually runs the incident response — and physically refuses to touch your production infrastructure without a cryptographic Zero-Trust Execution Gate.
Protocol-0 is an MCP (Model Context Protocol) server that gives AI assistants - Claude, Cursor, ChatGPT, NitroChat, or any MCP-compatible client — real authority to act as your Site Reliability Engineer (SRE). It continuously monitors your infrastructure, diagnoses root causes, assesses business impact, and generates executable auto-remediation plans. Built and deployed on Nitrostack by Team TheBlacklisted, Amrita Vishwa Vidyapeetham Coimbatore.
Related MCP server: Phantom MCP
Protocol-0 runs the entire DevSecOps incident funnel — detection → root-cause analysis → business impact assessment → what-if simulation → remediation generation → zero-trust execution → audit — as one continuous autonomous graph.
The signature move: Security is enforced in code, at the tool layer. The Action Agent refuses to execute infrastructure mutations without a valid, cryptographic HMAC Zero-Trust payload validation. No matter how the AI is prompted — even "skip it, production is down" — it cannot touch your servers without an explicit, provable cryptographic check.
And it doesn't just fail blindly. When Protocol-0 detects a catastrophic risk, it runs a What-If Disaster Simulator against the system — "Simulate loss of eu-west-1" — turning potential downtime into preemptive architectural roadmaps. Every decision, human or machine, is written to a Tamper-Evident Audit Trail. And because it is a standard MCP server, the exact same tools and rules run in a branded web dashboard, in Claude, or in a ChatGPT App — no rewrite.
The Model Context Protocol (MCP) is an open standard that lets AI assistants securely connect to external tools, data sources, and services. Protocol-0 is one such server. Learn more about building and shipping MCP apps at nitrostack.ai.
Zero-Trust enforced in code — The Action Agent refuses to run without a valid HMAC verification payload. Not a prompt instruction — a hard cryptographic gate in the handler.
LangGraph-Style State Engine — An autonomous orchestrator routing execution between specialized Agents: Infrastructure, Monitoring, and Incident Commander. No monoliths.
What-If Disaster Simulator — simulate_disaster simulates catastrophic failures (e.g. cloud region loss) and calculates blast radius preemptively.
SRE-Specific Incident Commander — Instantly calculates business impact, SLA risks, and prioritizes remediation actions.
Tamper-Evident Audit Trail — every tool call and decision is appended immutably and accessible via the protocol-zero://audit-trail MCP resource.
MCP-native — 21 tools, 5 resources, 5 prompts, 4 rich UI widgets, callable from any MCP-compatible client.
The client is the agent; Protocol-0 is the capability layer. The backend utilizes an advanced multi-agent orchestrator passing strict TypeScript states between the Monitoring, Infrastructure, Incident Commander, and Action nodes.
flowchart TB
subgraph Clients["MCP CLIENTS — the agent"]
direction LR
NC[NitroChat] --- CL[Claude] --- GPT[ChatGPT App]
end
Clients -->|MCP protocol| Server
subgraph Server["PROTOCOL-0 MCP SERVER — on Nitrostack"]
direction LR
T[21 Tools] --- R[5 Resources] --- P[5 Prompts] --- CG[["Zero-Trust Gate"]] --- AU[Tamper-Evident Audit]
end
Server -->|Deterministic Mocks| Adapters
subgraph Adapters["ENTERPRISE INTEGRATIONS"]
direction LR
BU[Datadog] --- AA[Jira] --- KY[GitHub] --- DE[PagerDuty] --- DO[Kubernetes]
end
classDef sig fill:#3a2a00,stroke:#f5a623,stroke-width:2px,color:#fff;
class CG sig;Point your MCP client at the endpoint (once deployed to NitroCloud) and try it instantly. Ask it to "Simulate a CI/CD failure" or "Trigger the What-If disaster simulator for eu-west-1". Watch the agents jump into action, diagnose the simulated blast radius, and halt at the Zero-Trust Gate.
Node.js 20.18+
An MCP-compatible client (Claude Desktop, Cursor, NitroStudio)
git clone https://github.com/priyansh-narang2308/TheBlacklisted-NitroStack.git
cd TheBlacklisted-NitroStack
npm installCopy the example environment file:
cp .env.example .env
# Set your HMAC verification key in .env
ZERO_TRUST_SECRET=your_long_random_secret_herenpm run devnpm run seed:demo
npm run regressAdd this server to your MCP client configuration:
{
"mcpServers": {
"protocol-0": {
"url": "https://protocol-0.app.nitrocloud.ai/mcp"
}
}
}Enterprise AI · SRE · DevSecOps · MCP · Model Context Protocol · MCP server · Incident Response · Zero Trust · LangGraph · AI agents · Claude MCP · Nitrostack
MIT © 2026 Team TheBlacklisted
Built using the Model Context Protocol on Nitrostack.
Action Agent: approve and execute a recommended action through its designated MCP server.
| Name | Required | Description | Default |
|---|---|---|---|
| recommendationId | Yes | Recommendation ID, e.g. REC-1 | |
| zero_trust_token | Yes | Cryptographic HMAC validation token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It states 'execute' implying side effects, but lacks details on security, reversibility, or error handling. The mention of 'designated MCP server' hints at delegation but is vague.
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 no unnecessary words. It front-loads the purpose and is easily scannable.
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 simple tool with 2 params and no output schema, the description provides adequate context for basic use. However, it omits return behavior, token acquisition, and prerequisites like recommendation validity. Siblings provide some context but not enough for full completeness.
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 100%, with clear descriptions for both 'recommendationId' and 'zero_trust_token'. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
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 'approve and execute' and identifies the resource as 'recommended action'. It distinguishes itself from the sibling 'rejectRecommendation', which is its opposite.
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 usage when an agent has a recommendation to approve, but it does not explicitly state when not to use it or mention alternatives like 'rejectRecommendation'. No prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executive Copilot: Ask natural-language operational questions like "Why is engineering health low?", "Summarize today's risks", etc.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Operational question |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks any behavioral traits (e.g., whether it's read-only, modifies state, or has latency). The description carries full burden but omits crucial context about side effects or safety.
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 with examples, 21 words. No redundant information; front-loaded with identity and examples.
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?
Adequate for a simple one-parameter tool, but lacks output format information (free text, structured?), behavioral traits, and limitations. Missing clarity on whether it aggregates data or directly retrieves 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 'question' parameter is described as 'Operational question' in schema, and description adds valuable examples (e.g., 'Why is engineering health low?') that clarify the expected input beyond the schema. Schema coverage is 100%, but description enhances meaning.
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?
Description clearly states 'Executive Copilot' for natural-language operational questions, with concrete examples ('Why is engineering health low?', 'Summarize today's risks'). Distinct from sibling tools like getEngineeringHealth which return specific data points.
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 explicit guidance on when to use this tool vs siblings. While the description implies use for broad queries, it doesn't clarify boundaries like 'for specific metrics use the dedicated tool'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Legacy alias for getAgentActivity.
| 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 must disclose behavioral traits. It merely states it's an alias, offering no information about side effects, permissions, or what the tool does when invoked.
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 at three words, but conciseness is undermined by the lack of substantive content. It is front-loaded but fails to earn its place due to vagueness.
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 must fully cover its behavior. 'Legacy alias' is insufficient; the agent needs to know what 'getAgentActivity' does, which is not explained.
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?
With zero parameters, the description should clarify the tool's purpose, but it fails to add meaning beyond the empty schema. The description adds no value, resulting in a low score despite the baseline of 4 for zero parameters.
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 'Legacy alias for getAgentActivity' is a tautology, restating the name without specifying what the tool does. It provides no verb or resource, leaving the agent unable to determine the tool's actual function.
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 that this is a legacy alias, suggesting the preferred tool is getAgentActivity, but it offers no explicit guidance on when to use this alias versus alternatives, nor any context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the live multi-agent execution pipeline (Monitoring -> Infrastructure -> Incident Commander -> Action) and agent logs.
| 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 full burden. It states 'live' implying real-time data but does not disclose whether it is polling, streaming, or snapshot-based. No mention of permissions, performance impact, or data volume. For a monitoring tool, this is insufficient.
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 covering main purpose with pipeline stages listed. Efficient but could be more structured (e.g., bullet points). No wasted words.
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 output schema and no annotations, the description is the only source. It provides a high-level view but lacks details on return format, log content, or how 'live' data is handled. Could specify output type or behavior for completeness.
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?
No parameters in schema (baseline 4). The description adds value by explaining what the tool shows (pipeline stages and logs), meeting the need for parameter context.
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 shows a 'live multi-agent execution pipeline' and 'agent logs', specifying the resource and action. However, it does not distinguish from sibling tools like 'get_agent_activity' (possibly identical) or 'getMonitoringStatus', slightly reducing clarity.
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. No prerequisites, exclusions, or tips provided. The agent has no context for choosing this over similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Legacy alias for getCompanyHealth.
| 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 offers no behavioral details such as side effects, required permissions, or return format. It only states it's an alias, which is insufficient.
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 very concise: a single sentence. However, it sacrifices clarity for brevity. It earns its place but could be slightly more informative without becoming verbose.
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 output schema and no annotations, the description should compensate with more detail about what the tool does and returns. It only says it's an alias, leaving the agent to infer behavior from the sibling getCompanyHealth.
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 zero parameters and the schema fully covers them. The description's mention of 'legacy alias' adds no additional meaning, but the baseline is 4 for zero-parameter tools with complete schema coverage.
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 merely states it's a legacy alias for getCompanyHealth, without explicitly describing what the tool does. The purpose is implied by the name and the reference, but it's vague and relies on the agent knowing getCompanyHealth.
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 backward compatibility but doesn't specify when to use this tool versus getCompanyHealth or other siblings. No guidance on preferred alternative or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the live Protocol-0 dashboard: overall system health score, per-subsystem health, open incidents, and top recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates a 'live' read-only operation but lacks details on potential latency, caching, or authentication requirements. Adequate but not rich.
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 wasted words, directly states purpose and scope. Front-loaded with action and resource.
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 zero parameters and no output schema, description covers the main outputs. Could be enhanced with output format hints, but sufficient for a simple read 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?
Zero parameters with 100% schema coverage. Description adds no parameter info, but none needed. Baseline score of 4 applies.
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?
Verb 'Get' and resource 'live Protocol-0 dashboard' are specific. Description lists exact outputs (health score, per-subsystem, incidents, recommendations), distinguishing it from siblings like getEngineeringHealth and getSecurityAuditLogs.
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?
Implies usage for overall health dashboard but does not explicitly state when to use vs alternatives or provide any exclusions. No guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the detailed engineering health report computed from weighted metrics (Deployment Success 25%, CI/CD Success 20%, Sprint Health 20%, Issue Rate 15%, Infrastructure 20%).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the weighted metrics and their percentages, offering insight into computation. However, with no annotations, it misses behavioral details like read-only nature, data freshness, or permissions.
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?
One sentence that is front-loaded with the primary purpose and includes all essential information about weighting. No wasted words.
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?
No output schema; description does not detail the return format or structure of the report. While the metrics are listed, an agent might need more context to interpret the output. Adequate but not fully complete.
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?
No parameters exist, so baseline is 4. The description adds no parameter info, which is appropriate.
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 retrieves a detailed engineering health report and lists the specific weighted metrics with percentages. This distinguishes it from sibling tools like getCompanyHealth.
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 explicit when/when-not guidance is provided. The name implies it's for engineering health, but alternatives are not mentioned; an agent might confuse it with getCompanyHealth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Legacy alias for getIncidentReport.
| Name | Required | Description | Default |
|---|---|---|---|
| incidentId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it is an alias, without disclosing behavioral traits such as read-only nature, authentication requirements, or return format.
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 that directly conveys the key information. Though very short, it earns its place without verbosity.
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?
With no output schema and no description of return values or behavior, the description is not self-sufficient. It relies entirely on external knowledge of getIncidentReport.
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%, and the description adds no information about the incidentId parameter. The parameter's role is only implied by the tool name, which is insufficient.
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 it is a legacy alias for getIncidentReport, specifying the verb 'get' and the resource 'incident report'. This distinguishes it from siblings by pointing to the primary tool.
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 explicitly says it is a legacy alias, implying that getIncidentReport should be preferred. This provides clear context for when to use this tool, though no detailed exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete analysis for one incident: timeline, root cause, confidence, affected systems, business impact and recommendations. Renders the incident detail view.
| Name | Required | Description | Default |
|---|---|---|---|
| incidentId | Yes | Incident ID, e.g. INC-1001 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It implies a read-only operation but does not disclose authentication needs, error behavior, or whether the tool is safe to call repeatedly. Adequate but not detailed.
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?
Two sentences, front-loaded with purpose and listing contents. No unnecessary words; every sentence 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 one parameter and no output schema, the description sufficiently explains what the tool returns. Could add details about output format (e.g., structured vs text) but is complete enough for typical use.
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 covers the only parameter (incidentId) with 100% coverage. The description adds no additional meaning beyond the schema's example, so baseline 3 is appropriate.
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 'Get' and the resource 'complete analysis for one incident', listing specific components like timeline, root cause, confidence, etc. This distinguishes it from sibling tools like get_incident by specifying the depth of information.
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 explicit guidance on when to use this tool versus alternatives like get_incident or getRecommendations. Does not mention prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches the current live state of the Kubernetes production clusters, identifying failing pods (CrashLoopBackOff, OOMKilled).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions fetching and identifying failing pods but does not disclose read-only nature, permissions needed, or other behavioral traits like latency or scope.
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 that is front-loaded and efficient, containing no superfluous information. Every word earns its place.
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?
No output schema exists, so description should clarify what the returned state contains. It gives examples of pod failures but does not specify the format (e.g., list of clusters, pods, or aggregated summary). Adequate but not fully complete.
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?
Tool has 0 parameters, so no parameter documentation needed. Baseline of 4 applies as per guidelines; description adds no parameter info but none is required.
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?
Description clearly states it fetches current live state of Kubernetes production clusters and identifies failing pods with specific statuses (CrashLoopBackOff, OOMKilled). This distinguishes it from sibling tools like getEngineeringHealth or getCompanyHealth.
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?
While the purpose is clear, there is no explicit guidance on when to use this tool versus alternatives. It implies usage for cluster health checks but lacks differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the active status of SaaS polling, last run timestamp, and recent Gmail/Slack alerts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description indicates it is a read operation by listing returned data, which is sufficient for a simple status check. However, it does not disclose any potential side effects, authentication needs, or rate limits. Since no annotations are provided, the description carries full burden; a 3 is appropriate as it adds some context but leaves gaps.
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 that is front-loaded with the purpose, no extraneous words, and all information is relevant.
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 output schema, the description adequately summarizes the returned data (status, timestamp, recent alerts). It could be more detailed about formatting or structure, but for a simple monitoring tool, it is sufficient. Slight deduction for lack of specificity on alert details.
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?
No parameters exist, and schema coverage is 100% trivially. Per guidelines, 0 parameters earns a baseline of 4. Description adds no parameter info because none are 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?
Description clearly states the tool returns active status, last run timestamp, and recent Gmail/Slack alerts. It specifies three concrete pieces of data, distinguishing it clearly from sibling tools like startMonitoring or getSecurityAuditLogs.
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. For example, it could be used before starting monitoring, but the description does not explicitly state such context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches the active on-call PagerDuty incidents and alerts across all engineering escalation policies.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read-only operation ('fetches') and adds context about the scope (active on-call, across escalation policies). Though it could explicitly state side-effect-freeness or permissions, the verb 'fetches' strongly implies safe read behavior.
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 no wasted words. It front-loads the primary action and resource, making it easy to parse.
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 no parameters and no output schema, the description covers the essential purpose and scope. It is complete for a simple fetch operation, though it does not describe the return format (e.g., list of objects).
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 zero parameters, so the baseline is 4. The description adds no parameter details because none exist. Schema coverage is 100% vacuously, and no additional meaning 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 uses a specific verb ('fetches') and resource ('active on-call PagerDuty incidents and alerts') with clear scoping ('across all engineering escalation policies'). It distinguishes from siblings like 'list_incidents' and 'get_incident' which likely cover non-on-call incidents.
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 usage for active on-call incidents but does not explicitly state when to use this tool over alternatives like 'list_incidents' or 'get_incident'. 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.
Get prioritized AI recommendations (high/medium/low). Optionally scoped to one incident. Exposes Approve/Reject actions.
| Name | Required | Description | Default |
|---|---|---|---|
| incidentId | No | Optional incident ID to scope recommendations, e.g. INC-1001 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not explicitly state read-only behavior, and the phrase 'Exposes Approve/Reject actions' is ambiguous (could suggest this tool performs those actions). No mention of permissions, side effects, or what happens when no incidentId is given.
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?
Two sentences, front-loaded with key data (prioritized, high/medium/low). No fluff, every part 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?
Adequate for a simple read tool with one optional parameter. Describes output (prioritized recommendations) and optional scoping. However, lacks details on return format/behaviors (e.g., what happens with no incidentId, pagination) and could clarify relationship to approve/reject actions.
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 100% with a good description for incidentId. The description repeats 'Optionally scoped to one incident' but adds no extra meaning beyond the schema. The mention of 'high/medium/low' is about output, not parameter semantics.
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?
Clearly states 'Get prioritized AI recommendations' with priority levels, and optional scoping to an incident. The verb 'Get' and resource 'AI recommendations' are specific. It distinguishes from siblings like 'approveRecommendation' which are action-oriented.
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?
Implies usage for viewing before taking actions by mentioning 'Exposes Approve/Reject actions' and optional scoping. No explicit when-not-to-use or alternatives, but the context with siblings provides clear differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches recent security audit logs, including IAM role modifications, Zero-Trust Gate executions, and unauthorized access attempts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior fully. It mentions 'recent' without defining the time window, omits read-only status, pagination, or rate limits, leaving significant gaps for a parameterless 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?
Single sentence with no wasted words; front-loaded verb and resource, efficient and clear.
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?
Adequate for a simple fetch tool with no parameters, but lacks details on time range (e.g., how recent) and output format, leaving some ambiguity about what the agent receives.
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?
No parameters exist, so description doesn't need to add parameter details. Baseline score of 4 applies as per guidelines for 0-param tools.
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 'Fetches' and resource 'security audit logs', with specific examples of included log types, distinguishing it from sibling tools that handle incidents or monitoring.
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?
Implied usage for security audit logs, but no explicit when-to-use or alternatives compared to siblings like getIncidentReport or getKubernetesState, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active incidents.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose whether the tool is read-only, requires authentication, or has any pagination or filtering behavior. 'List active incidents' provides no behavioral context beyond the name.
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, efficient sentence with no wasted words.
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 simple, zero-parameter list tool with no output schema, the description is minimally adequate. However, it lacks details about the format or scope of returned incidents, which could be necessary for proper usage.
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 100% (0 parameters), so baseline is 3. No additional parameter info is needed or provided.
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' and resource 'active incidents', which distinguishes it from sibling tools like get_incident (singular) and getIncidentReport.
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 such as triggerIncident, simulate_disaster, or get_incident. The agent must infer from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Action Agent: reject a recommended action, marking it as rejected in the timeline.
| Name | Required | Description | Default |
|---|---|---|---|
| recommendationId | Yes | Recommendation ID, e.g. REC-1 | |
| zero_trust_token | Yes | Cryptographic HMAC validation token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it marks as rejected in the timeline, but does not disclose side effects, security implications despite the zero_trust_token parameter, or reversibility.
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, 13 words, no fluff. Efficiently communicates the core action.
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 mutation tool with no output schema, the description lacks details on outcome, confirmation, or impact on related data. It is too minimal given the complexity of the action.
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 100%, so the baseline is 3. The description adds no extra parameter information beyond what the schema already provides.
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 specifies the verb 'reject' and the resource 'recommended action', and distinguishes from the sibling 'approveRecommendation' by stating it marks as rejected in the timeline.
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 like 'approveRecommendation' or 'getRecommendations'. No prerequisites or conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What-If Disaster Simulator: Simulate the catastrophic failure of a specific sub-system or cloud region to test auto-remediation and cascading impacts.
| Name | Required | Description | Default |
|---|---|---|---|
| targetNode | Yes | The sub-system or region to simulate failure for (e.g., 'eu-west-1', 'auth-service', 'k8s-cluster-1') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It communicates that the tool is a simulator (non-destructive), but does not disclose potential side effects, idempotency, rate limits, or whether results persist. It meets a baseline but could add more behavioral details.
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 a colon separating the title from the explanation. It is concise and contains no superfluous words, earning its place.
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 simple tool with one parameter and no output schema, the description effectively covers the tool's purpose and usage. It could be more complete by mentioning what the output or result type is, but overall it provides sufficient context.
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 100% for the sole parameter 'targetNode'. The description adds value by providing examples ('eu-west-1', 'auth-service', 'k8s-cluster-1') and clarifying the scope, which goes beyond the schema's type and brief description.
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 uses the verb 'simulate' and specifies the resource ('catastrophic failure of a specific sub-system or cloud region'). It clearly states the purpose: 'test auto-remediation and cascading impacts.' This distinguishes it from sibling tools like 'triggerIncident', which likely triggers real incidents.
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 usage for simulation and testing, but does not explicitly state when not to use this tool versus alternatives. No exclusions or prerequisites are mentioned, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start continuous live polling of enterprise SaaS systems (GitHub, Jira, Datadog, Calendar) every 30 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses polling interval (30 seconds) and systems involved, but lacks details on side effects (e.g., resource usage, persistence, overlapping sessions), prerequisites, or how to stop (implied via sibling stopMonitoring). No annotations to supplement.
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 that is front-loaded with purpose, action, and key details. No wasted words.
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 output schema, the description should explain what the tool returns or its effect (e.g., starts a background process, returns status). It mentions polling but not the output or state behavior. Adequate but incomplete without further context on lifecycle.
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?
No parameters in schema, so description is not expected to elaborate. Baseline 4 for zero parameters; no additional meaning required.
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?
Clearly states the action (start continuous live polling), specifies the resource (enterprise SaaS systems with examples), and the frequency (every 30 seconds). Distinguishes from siblings like stopMonitoring and getMonitoringStatus.
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?
Implied usage: to begin polling. No explicit guidance on when to use vs alternatives like getMonitoringStatus, or when not to use (e.g., if already polling). No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop continuous live polling of enterprise SaaS systems.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It states it stops polling, but does not disclose side effects, error states, or prerequisites. Adequate but minimal.
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 wasted words, front-loaded with action and resource.
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?
No output schema or annotations, but for a simple stop operation with no parameters, the description is sufficient. Could mention confirmation or return value.
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?
No parameters in schema (coverage 100%), so description adds no param info. Baseline for 0 parameters is 4.
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?
Description clearly states action 'stop', resource 'continuous live polling', and context 'enterprise SaaS systems'. Distinguishes from siblings like startMonitoring.
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 explicit when-to-use or alternatives provided. Usage is implied by the tool's name and description as the counterpart to startMonitoring, but no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hackathon Simulator: Trigger one of the 10 supported incident scenarios to observe how the LangGraph multi-agent pipeline reasons and mitigates in real-time.
| Name | Required | Description | Default |
|---|---|---|---|
| incidentType | Yes | The specific scenario to simulate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry this burden. It mentions 'Hackathon Simulator' implying non-production use, but does not disclose behavioral traits like side effects, duration, or whether it mutates real data. The description lacks transparency about what happens after triggering.
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, front-loaded with key context ('Hackathon Simulator'), no redundant information. Extremely concise and well-structured.
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 simple tool with one parameter and no output schema, the description is adequate but lacks information about return values, real-time effects, or post-trigger behavior. It is minimally complete for a hackathon scenario but could be more informative.
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 100% with a single parameter fully defined by enum. The description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.
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 'Trigger' and the resource 'incident scenarios', and specifies it's for a hackathon simulator. It distinguishes itself by mentioning '10 supported incident scenarios' and the LangGraph multi-agent pipeline, but does not explicitly differentiate from the sibling 'simulate_disaster' tool.
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, such as 'simulate_disaster' or other monitoring tools. It only states purpose, not usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0approveRecommendationexecutiveChatget_agent_activityget_company_healthget_incidentgetAgentActivitygetCompanyHealthgetEngineeringHealthgetIncidentReportgetKubernetesStategetMonitoringStatusgetPagerDutyIncidentsgetRecommendationsgetSecurityAuditLogslist_incidentsrejectRecommendationsimulate_disasterstartMonitoringstopMonitoringtriggerIncidentMost tools have distinct purposes, but there are three legacy alias pairs (get_incident/getIncidentReport, get_company_health/getCompanyHealth, get_agent_activity/getAgentActivity) that create direct overlap, causing potential confusion for an agent.
The toolset mixes camelCase (e.g., triggerIncident, startMonitoring) and snake_case (e.g., simulate_disaster, list_incidents) inconsistently, with no clear pattern or rationale for the variation.
20 tools is on the higher side for a typical server, but the broad scope (simulation, monitoring, incident management, actions) could justify it, though the presence of three duplicate aliases makes the count feel slightly bloated.
The toolset covers a wide range of incident and monitoring operations: simulation, monitoring, security, health reports, incident details, recommendations, and approvals. Minor gaps exist (e.g., no manual incident creation or update), but the surface is largely sufficient for its domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent-native security, trust, reliability, data and procurement tools for AI workflows.
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
AI agent run monitoring with incident replay and SLA receipts.
AI agent infrastructure for discovery, authorization, execution, identity, and signed receipts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/paarthureddy/TheBlacklisted-NitroStack'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
