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.

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

This server cannot be installed

license - permissive license

quality - not tested

maintenance

How are these scores calculated?

Maintenance

–Maintainers

–Response time

–Release cycle

1Releases (12mo)

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.

Latest Blog Posts

Lightport: Open-Sourcing Glama's AI Gateway
By punkpeye on April 27, 2026.
open source
OpenAI
Tool Definition Quality Score (TDQS)
By punkpeye on April 3, 2026.
mcp
The Hackers Who Tracked My Sleep Cycle
By punkpeye on March 26, 2026.
security

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