How do I use Stage0 Authorization MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Stage0 Authorization MCP Server Authorize action: publish report" 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.

Stage0 Authorization MCP Server

by Starlight143

Overview Schema Related Servers Score Discussions

TypeScript

Remote

MCP Server with Stage0 Authorization

A Model Context Protocol (MCP) server demonstrating how to guard tool calls with Stage0 runtime policy validation. This example shows how AI agents can be prevented from executing unauthorized actions before they happen.

Problem Scenario

AI agents can silently escalate from safe operations into dangerous ones:

Research → Publication: Agent researches a topic, then publishes findings without approval
Analysis → Deployment: Agent investigates an incident, then deploys changes autonomously
Drafting → Execution: Agent drafts content, then executes publication workflows
Investigation → Loop: Agent keeps retrying failing operations, consuming resources

Stage0 solves this by validating every execution intent before the action happens, returning an external verdict: ALLOW, DENY, or DEFER.

Related MCP server: mcp-governance-proxy

Where Stage0 Fits

┌─────────────────────────────────────────────────────────────────┐
│                     AI Agent Runtime                            │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐                  │
│  │  LLM     │───▶│  Tools   │───▶│ Actions  │                  │
│  └──────────┘    └──────────┘    └──────────┘                  │
│                       │                                         │
│                       ▼                                         │
│              ┌─────────────────┐                                │
│              │    Stage0       │  ◀── External Policy Authority │
│              │  (Guard Layer)  │                                │
│              └─────────────────┘                                │
│                       │                                         │
│                       ▼                                         │
│              ┌─────────────────┐                                │
│              │ ALLOW / DENY /  │                                │
│              │     DEFER       │                                │
│              └─────────────────┘                                │
└─────────────────────────────────────────────────────────────────┘

Stage0 sits between tool invocation and execution - it's NOT part of the agent. The agent cannot self-approve actions. All execution intent MUST be validated via Stage0 /check endpoint.

Why Server-Side Authorization?

A common mistake is to put authorization in the agent's prompt (e.g., "You are not allowed to deploy"). This approach has critical flaws:

Prompt-Based Authorization	Server-Side Authorization
Agent can ignore instructions	Agent cannot bypass server checks
No audit trail of decisions	Every check logged with `request_id`
Different agents = different behaviors	Consistent enforcement across all clients
Can be overridden by user prompts	Enforced by external policy authority
No cryptographic proof of policy	`policy_version` ensures reproducibility

The authorization boundary must be in the server-side tool handler, not in the prompt. This repository demonstrates exactly that pattern.

Quick Start

Prerequisites

Node.js 18+
npm or pnpm
(Optional) Stage0 API key from SignalPulse

Installation

# Clone the repository
git clone https://github.com/Starlight143/mcp-server-stage0-authorization.git
cd mcp-server-stage0-authorization

# Install dependencies
npm install

# Copy environment configuration
cp .env.example .env

# Build the TypeScript
npm run build

Configure API Key (Optional)

Edit .env and add your Stage0 API key:

STAGE0_API_KEY=your_api_key_here
STAGE0_BASE_URL=https://api.signalpulse.org

Note: Without an API key, the server uses simulated Stage0 responses. This is useful for testing the integration flow.

Run the Demo

# Demo 1: ALLOW scenario - research tool call
npm run demo:allow

# Demo 2: DENY scenario - publish tool call  
npm run demo:deny

# Demo 3: DEFER scenario - loop threshold exceeded
npm run demo:defer

Expected Output

ALLOW Example (Research)

======================================================================
DEMO: ALLOW Scenario - Research Tool Call
======================================================================

Scenario: An agent wants to research a topic and return
informational summary. This is a low-risk operation.

Calling Stage0 to check authorization...

Response from Stage0:
----------------------------------------------------------------------
Verdict:        ALLOW
Decision:       GO
Reason:         Informational operation with no high-risk side effects
Request ID:     a1b2c3d4-e5f6-7890-abcd-ef1234567890
Policy Version: simulated-v1.0.0
Risk Score:     15
High Risk:      false
----------------------------------------------------------------------

✅ TOOL CALL ALLOWED

The agent can proceed to execute the research tool.
This is safe because:
- No side effects (publish, deploy, etc.)
- Informational operation only
- No guardrail violations

DENY Example (Publish)

======================================================================
DEMO: DENY Scenario - Publish Tool Call
======================================================================

Scenario: An agent attempts to publish content to a public
channel without proper authorization. This is a high-risk
operation that should be blocked.

Calling Stage0 to check authorization...

Response from Stage0:
----------------------------------------------------------------------
Verdict:        DENY
Decision:       NO_GO
Reason:         HIGH severity: SIDE_EFFECTS_NEED_GUARDRAILS - 'publish' 
                side effect requires approval guardrails
Request ID:     b2c3d4e5-f6a7-8901-bcde-f12345678901
Policy Version: simulated-v1.0.0
Risk Score:     85
High Risk:      true

Issues detected:
  [HIGH] SIDE_EFFECTS_NEED_GUARDRAILS: Side effects [publish] require 
         approval guardrails
----------------------------------------------------------------------

⛔ TOOL CALL BLOCKED

The agent is NOT allowed to execute this tool.
This is correct because:
- "publish" side effect requires approval guardrails
- No human approval was provided
- Publishing without review can cause trust/compliance issues

DEFER Example (Vague Request)

======================================================================
DEMO: DEFER Scenario - Unclear/Vague Request
======================================================================

Scenario: An agent receives a vague request without clear
success criteria or value proposition. Stage0 DEFERs to
request more context before proceeding.

Calling Stage0 to check authorization...

Response from Stage0:
----------------------------------------------------------------------
Verdict:        DEFER
Decision:       DEFER
Reason:         UNCLEAR_VALUE_SIGNAL: Task appears under-specified 
                for reliable value delivery.
Request ID:     c3d4e5f6-a7b8-9012-cdef-123456789012
Policy Version: simulated-v1.0.0
Risk Score:     35

Clarifying questions:
  ? What is the specific outcome you want to achieve?
  ? What constraints or requirements should be considered?
----------------------------------------------------------------------

⏸️ TOOL CALL DEFERRED

The agent should NOT proceed automatically.
Human review is required because:
- Request is too vague to evaluate value
- Success criteria are unclear
- More context is needed before execution

Note: The actual verdict depends on your Stage0 plan and policy configuration:

Pro plans may return DEFER for vague requests with clarifying_questions
Free/Starter plans may return ALLOW with clarifying questions or DENY depending on policy settings
The simulated response (without API key) demonstrates the expected DEFER behavior

Where `request_id` and `policy_version` Appear

Every Stage0 /check response includes:

Field	Description	Location
`request_id`	Unique identifier for this authorization request	Use for audit logs, debugging, and traceability
`policy_version`	Version of the policy pack used for evaluation	Use for compliance and reproducibility

These fields are returned in the API response:

{
  "verdict": "DENY",
  "decision": "NO_GO",
  "reason": "...",
  "request_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "policy_version": "v1.2.3",
  "risk_score": 85,
  "high_risk": true
}

Running as MCP Server

To use this as an MCP server with Claude Desktop or other MCP clients:

1. Build the server

npm run build

2. Add to Claude Desktop config

Edit the Claude Desktop config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "stage0-authorization": {
      "command": "node",
      "args": ["<REPO_PATH>/dist/index.js"],
      "env": {
        "STAGE0_API_KEY": "your_api_key_here",
        "STAGE0_BASE_URL": "https://api.signalpulse.org"
      }
    }
  }
}

Replace <REPO_PATH> with the actual path to your cloned repository.

3. Available Tools

Tool	Description	Risk Level	Context-Aware
`research-topic`	Research and summarize a topic	Low	No
`publish-content`	Publish content to a channel	High	No
`deploy-changes`	Deploy to environment	High	Yes (`actor_role`)
`managed-deploy`	Deploy with full authorization context	High	Yes (all fields)
`retry-workflow`	Retry a failing workflow	Medium	Yes (`retry_count`)
`check-authorization`	Check if action would be authorized	N/A	Optional

Authorization Context

The managed-deploy tool demonstrates the four critical context fields that should be passed from upstream:

Field	Description	Example Values
`actor_role`	Role of the entity performing the action	`admin`, `developer`, `viewer`
`approval_status`	Whether the action has been approved	`approved`, `pending`, `none`
`environment`	Target environment	`production`, `staging`, `development`
`resource_scope`	Scope of resources affected	`all`, `team-a`, `service-x`

Example: Role-Based Deployment Control

const context: Stage0Context = {
  actor_role: 'developer',      // Who is performing the action
  approval_status: 'pending',   // Has this been approved?
  environment: 'production',    // Where is this deploying?
  resource_scope: 'team-a',     // What resources are affected?
};

const response = await stage0.checkGoal(
  'Deploy authentication service to production',
  {
    sideEffects: ['deploy'],
    context,
    successCriteria: ['Deployment completes successfully'],
  }
);

This context enables policy rules like:

viewer role → DENY all deployments
developer role → ALLOW staging, DENY production without approval
admin role → ALLOW all with approval_status: approved

Integration Guide

To add Stage0 authorization to your MCP server:

Basic Pattern

import { Stage0Client, Stage0Context } from './stage0-client.js';

const stage0 = new Stage0Client();

server.tool('my-tool', 'Description', schema, async (params) => {
  // 1. Check authorization before execution
  const response = await stage0.checkGoal(
    'Description of what this tool does',
    {
      sideEffects: ['publish'],
      successCriteria: ['Task completes successfully'],
      constraints: ['approval_required'],
    }
  );

  // 2. Handle the verdict
  if (response.verdict === 'DENY') {
    return {
      content: [{ type: 'text', text: `Blocked: ${response.reason}` }],
    };
  }

  if (response.verdict === 'DEFER') {
    return {
      content: [{ type: 'text', text: `Deferred: ${response.reason}` }],
    };
  }

  // 3. Execute only if ALLOWED
  const result = await doSomething(params);
  return {
    content: [{ type: 'text', text: result }],
  };
});

With Authorization Context

For privileged operations, pass context from upstream:

server.tool('deploy-service', 'Deploy a service', {
  serviceName: z.string(),
  environment: z.enum(['staging', 'production']),
  actorRole: z.enum(['admin', 'developer', 'viewer']),
}, async ({ serviceName, environment, actorRole }) => {
  const context: Stage0Context = {
    actor_role: actorRole,
    environment,
    approval_status: 'none', // Would come from your approval system
  };

  const response = await stage0.checkGoal(
    `Deploy ${serviceName} to ${environment}`,
    {
      sideEffects: ['deploy'],
      context,
      successCriteria: ['Deployment succeeds'],
    }
  );

  if (response.verdict !== 'ALLOW') {
    return {
      content: [{ 
        type: 'text', 
        text: `⛔ ${response.verdict}: ${response.reason}\n\nRequest ID: ${response.request_id}` 
      }],
    };
  }

  // Execute deployment
  return executeDeployment(serviceName, environment);
});

Why This Matters

Without Stage0	With Stage0
Agent executes every planned step	Agent validates before execution
Silent escalation to dangerous actions	External authority checks intent
Self-approved publication/deployment	Human approval required
Runaway retry loops	Loop thresholds enforced
Post-hoc detection only	Prevention before execution

Running Tests

This repository includes comprehensive smoke tests:

# Run all tests (uses simulated mode without API key)
npm test

# Run tests with real API
STAGE0_API_KEY=your_api_key npm test

# Run tests in watch mode
npm run test:watch

Tests cover:

ALLOW/DENY/DEFER verdict scenarios
Context propagation (actor_role, environment, etc.)
Error handling and edge cases
Real API integration (when API key provided)

This example is part of the SignalPulse framework quickstart collection:

OpenAI Agents SDK - github.com/Starlight143/openai-agents-stage0
LangGraph - github.com/Starlight143/langgraph-stage0
MCP Server - github.com/Starlight143/mcp-server-stage0-authorization (this repo)

License

MIT

Available Tools

6 tools

check-authorizationA

Check if an action would be authorized by Stage0 (does NOT execute the action)

ParametersJSON Schema

Name	Required	Description
`goal`	Yes	The goal/action to check
`retryCount`	No	Current retry count (for loop scenarios, must be >= 0)
`sideEffects`	Yes	List of side effects (e.g., "publish", "deploy", "loop")
`successCriteria`	No	List of success criteria

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses the most important behavioral trait: the action is not executed, implying a read-only safety profile. However, it does not mention other behaviors such as return value format or potential side effects like logging, so it's not fully transparent.

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

Conciseness5/5

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

The description is a single, front-loaded sentence that conveys the purpose and a critical caveat without any wasted words. It is concise and well-structured.

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 simple nature and full schema coverage, the description covers the essential purpose and non-execution behavior. It lacks a statement about the return value (e.g., whether it returns a boolean or an authorization decision), which would be helpful since no output schema is present. Overall, it is reasonably complete but not exhaustive.

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 coverage is 100%, with all 4 parameters described in the input schema. The description does not add parameter-level detail, but the baseline of 3 is appropriate since the schema already fully documents each parameter's 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 uses a specific verb 'Check' with a clear resource ('whether an action would be authorized by Stage0') and explicitly states the tool does NOT execute the action. This clearly distinguishes it from sibling tools like publish-content and deploy-changes that actually perform actions.

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 implies usage as a pre-flight authorization check and the 'does NOT execute' caveat contrasts with execution tools, giving a clear when-to-use context. However, it does not explicitly name alternatives or provide explicit when-not-to-use scenarios beyond the non-execution statement.

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

deploy-changesB

Deploy changes to an environment. Context-aware: requires appropriate actor_role for production deployments.

ParametersJSON Schema

Name	Required	Description
`changes`	Yes	Description of changes
`actorRole`	No	Role of the actor performing deployment
`environment`	Yes	Target environment
`serviceName`	Yes	The service to deploy

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description carries full burden for disclosing behavior. It only vaguely notes 'Context-aware: requires appropriate actor_role for production deployments' without specifying roles, error behavior, or side effects. This is minimal and incomplete for a deployment action.

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 two concise sentences: first states purpose, second adds key context. No unnecessary words or repetition; every sentence earns its place.

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

Completeness2/5

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

The tool is a deployment operation with no output schema and no annotations. The description lacks detail on return values, failure modes, authorization specifics, or rollback behavior. It is under-specified for the complexity and importance of this action.

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 coverage is 100% with descriptions for all four parameters. The description adds no extra parameter details 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Deploy changes to an environment', identifying the verb and resource. However, it does not differentiate from sibling tools like 'managed-deploy', so it lacks sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions 'requires appropriate actor_role for production deployments', providing some context-specific usage guidance. However, it does not explicitly state when to use this tool over alternatives like 'managed-deploy', nor does it give exclusions.

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

managed-deployC

Deploy with full authorization context. Demonstrates actor_role, approval_status, environment, and resource_scope usage.

ParametersJSON Schema

Name	Required	Description
`changes`	Yes	Description of changes
`actorRole`	Yes	Role of the actor (admin, developer, viewer)
`environment`	Yes	Target environment
`serviceName`	Yes	The service to deploy
`resourceScope`	No	Resource scope (e.g., "team-a", "all", "service-x")
`approvalStatus`	Yes	Approval status for this deployment

TDQS

C2.6/5.0

Behavior2/5

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

No annotations exist, so the description must disclose behavior. It only says 'deploy with full authorization context' without explaining side effects, permission requirements, reversibility, or that it might be a demonstration. This leaves the agent without knowledge of potential destructive consequences.

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

Conciseness4/5

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

The description is brief and front-loaded with the core action, but the second sentence about 'Demonstrates... usage' is low-value filler that could confuse rather than inform.

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

Completeness2/5

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

This is a deployment tool with no annotations, no output schema, and six parameters. The description does not address when to deploy, what 'full authorization context' means, how approval status affects the deployment, or what success/failure looks like. The tool appears to be complex, so more context is needed.

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

Parameters3/5

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

The input schema covers all parameter descriptions (100% coverage), so baseline is 3. The description mentions actor_role, approval_status, environment, and resource_scope but adds no detail beyond schema definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool deploys with an authorization context, but the second sentence framing 'Demonstrates... usage' suggests it may be a demonstration rather than a production tool. It does not distinguish from the sibling 'deploy-changes', leaving ambiguity about when to use this vs that.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives like 'deploy-changes'. The description gives no context, prerequisites, or exclusions.

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

publish-contentA

Publish content to a public channel (HIGH RISK - typically DENIED)

ParametersJSON Schema

Name	Required	Description	Default
`channel`	Yes	The target channel (e.g., "blog", "social", "docs")
`content`	Yes	The content to publish

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations provided, the description carries full transparency burden. It discloses that the operation is high risk and typically denied, which is critical behavioral context beyond the schema. However, it does not elaborate on what denial means or the consequences of publishing.

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

Conciseness5/5

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

The description is a single, front-loaded sentence that immediately communicates the action and risk. Every word earns its place with no filler.

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

Completeness4/5

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

For a simple 2-parameter tool with no output schema, the description covers purpose and risk adequately. It lacks return value details, but those are not required. The risk warning compensates for missing behavioral depth, though a bit more on consequences would round it out.

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

Parameters3/5

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

Schema description coverage is 100%, with both 'content' and 'channel' clearly described in the schema. The tool description adds no additional parameter-specific meaning, so the baseline of 3 applies.

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 action (publish) and the target (content to a public channel), which distinguishes it from sibling tools like research-topic and deploy-changes. The added risk warning provides extra specificity about the tool's nature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites like check-authorization. The risk warning implies caution but does not explain when publishing is appropriate or how to handle denials.

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

research-topicA

Research a topic and return informational summary (LOW RISK - typically ALLOWED)

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes	The topic to research

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It discloses a behavioral trait ('LOW RISK - typically ALLOWED') and indicates an informational summary output, but it lacks depth on side effects, data sources, or limitations. This is 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.

Conciseness5/5

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

The description is one concise sentence, front-loaded with the action and resource. It contains no filler and is appropriately sized for a simple tool.

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

Completeness4/5

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

For a tool with one parameter, no output schema, and no annotations, the description covers purpose, risk, and output type. It is mostly complete, though it could benefit from a brief note about when not to use it or what kind of summary to expect.

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 coverage is 100% and the topic parameter already has a clear description ('The topic to research'). The tool description adds no extra parameter context, so it does not exceed the baseline for high schema coverage.

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 states a specific verb ('Research') and resource ('a topic') with an outcome ('return informational summary'). It clearly distinguishes itself from sibling tools like publish-content and deploy-changes, 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies when to use this tool (for research/information) without needing to compare to alternatives. The 'LOW RISK - typically ALLOWED' note provides context on safety, though it does not explicitly exclude deployment or publish scenarios.

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

retry-workflowA

Retry a failing workflow (MEDIUM RISK - may DEFER if loop threshold exceeded)

ParametersJSON Schema

Name	Required	Description	Default
`retryCount`	Yes	Current retry count (must be >= 0)
`workflowId`	Yes	The workflow ID to retry

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It adds a 'MEDIUM RISK' warning and the 'may DEFER if loop threshold exceeded' caveat, which are valuable. However, it does not explain what deferral means, potential side effects, or how retryCount affects behavior, leaving significant gaps.

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

Conciseness5/5

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

The description is a single sentence that front-loads the core action and adds a succinct risk qualifier. Every word earns its place, and there is no redundancy or filler.

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

Completeness3/5

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

For a simple two-parameter tool with a well-documented schema, the description is minimally viable. However, it omits important operational context such as what happens on success/failure, how loop thresholds are determined, or what 'DEFER' entails, making it incomplete for an agent needing full behavioral understanding.

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

Parameters3/5

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

The input schema already provides descriptions for both parameters, with 100% coverage. The tool description adds no additional parameter-level information, but the high schema coverage means the baseline of 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 action ('Retry') and the resource ('a failing workflow'), making the tool's purpose immediately obvious. It also distinguishes this from siblings like research-topic or deploy-changes, which involve different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit guidance on when to use this tool versus alternatives. It implies use for failing workflows but doesn't state prerequisites, exclusions, or mention that retrying might not be appropriate in certain conditions beyond the vague 'may DEFER' note.

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.

6 tool updatesv1.0.0Aug 7, 2026
- First observedcheck-authorization
- First observeddeploy-changes
- First observedmanaged-deploy
- First observedpublish-content
- First observedresearch-topic
- First observedretry-workflow

Install Server

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

TDQS

B3.4/5.0

Disambiguation3/5

Deploy-changes and managed-deploy both handle deployments with context, creating potential confusion about which to use. Other tools (research-topic, publish-content, retry-workflow, check-authorization) are clearly distinct.

Naming Consistency4/5

Most tools follow a consistent verb-noun pattern (e.g., research-topic, publish-content, retry-workflow), but managed-deploy deviates by using an adjective-noun form, breaking the pattern.

Tool Count5/5

Six tools is a well-scoped count for an authorization and workflow server, with each tool serving a clear role and no excessive overlap in the overall set.

Completeness3/5

The set covers key operations like research, publish, deploy, retry, and authorization checks, but lacks status or rollback capabilities and the redundancy between deploy tools leaves potential gaps in lifecycle coverage.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

gatewayOAuth
ai.sealgate
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
Security Agent Orchestration
1
Sunaiva Gate — Agent Rule Enforcement A
io.sunaivacore
MCP enforcement layer that intercepts AI agent actions and blocks rule violations before execution.
Security Autonomous Agents
162
IdentArk Gateway
io.identark
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Security Agent Orchestration
29
agentguard A
io.tooloracle
AgentGuard — 20-tool AI safety MCP: policy preflight, risk scoring, audit logging, rate limits.
Security Monitoring
2

Related MCP Servers

gov-mcp
Security Autonomous Agents
liuhaotian2024-prog
A
license
Not graded
quality
C
maintenance
An MCP server that enforces runtime governance on AI agent actions — file access, command execution, delegation chains, and permission escalation.
Updated 4 months ago (2026-05-08 00:25 UTC)
MIT
mcp-governance-proxy
Security Agent Orchestration
andreas-altamirano
A
license
Not graded
quality
D
maintenance
An MCP server that acts as a governance proxy for AI agents, evaluating each tool call against policies before execution, enabling secure and controlled access to systems like Slack, GitHub, and AWS without exposing credentials to the agent.
Updated 3 months ago (2026-06-18 00:43 UTC)
Apache 2.0
AISentinel
Security Observability
Kabzhanov
A
license
Not graded
quality
A
maintenance
An open-source MCP server that protects AI agents at runtime by evaluating every tool call against YAML policies and generating audit trails.
Updated 2 months ago (2026-07-10 07:29 UTC)
1
Apache 2.0
Oakallow MCP Serverofficial
oakallow
A
license
Not graded
quality
C
maintenance
Runtime permission, approval, and audit governance for AI agent tool execution, enabling human oversight of risky actions via an MCP server.
Updated 2 months ago (2026-06-24 16:26 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Starlight143/mcp-server-stage0-authorization'

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

MCP Server with Stage0 Authorization

Problem Scenario

Where Stage0 Fits

Why Server-Side Authorization?

Quick Start

Prerequisites

Installation

Configure API Key (Optional)

Run the Demo

Expected Output

ALLOW Example (Research)

DENY Example (Publish)

DEFER Example (Vague Request)

Where request_id and policy_version Appear

Running as MCP Server

1. Build the server

2. Add to Claude Desktop config

3. Available Tools

Authorization Context

Example: Role-Based Deployment Control

Integration Guide

Basic Pattern

With Authorization Context

Why This Matters

Running Tests

Related Examples

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Oakallow MCP Serverofficial

Latest Blog Posts

MCP directory API

Where `request_id` and `policy_version` Appear