How do I use Claude-Code MCP Runner?

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., "@Claude-Code MCP Runner Run the SEO audit agent on example.com" 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.

Claude-Code MCP Runner

by DeamonDev888

Overview Schema Related Servers Score Discussions

TypeScript

Local

🤖 Claude-Code MCP Runner (Package Edition)

Le Pilote Automatique pour vos Agents IA, désormais modulaire et réutilisable.

Architecture du projet

👋 C'est quoi ?

Il s'agit d'une véritable télécommande universelle pour Claude-Code et d'autres outils CLI similaires. Ce projet est désormais structuré comme une bibliothèque (package) moderne, permettant non seulement de lancer un serveur MCP autonome, mais aussi d'intégrer les capacités de pilotage d'agents directement dans vos propres applications Node.js.

C'est la passerelle ultime pour transformer Claude Code en une flotte d'agents spécialisés, pilotables par API ou par MCP.

Related MCP server: cc-agent

✨ Ce que ça fait

🔌 Contrôle Total : Lancez des missions complexes via MCP ou directement via le code.
🏗️ Architecture Pro : Basé sur des services (AgentManager, ClaudeRunner, PromptManager) pour une stabilité maximale.
🛠️ Capacités Étendues : L'agent piloté peut utiliser VOS outils (Base de données, Scrapers, etc.).
🤖 Multi-Agents : Créez, configurez et gérez des personnalités d'agents isolées (Prompts & Settings dédiés).
📦 Prêt pour l'Intégration : Importable comme un module NPM dans vos autres projets.

🚀 Commencer (Guide Facile)

1. Installation

# Installe les dépendances
pnpm install

# Build le projet (Génère les types TS et le code JS)
pnpm run build

2. Configuration MCP

Pour que l'agent puisse voir vos autres serveurs MCP, copiez le fichier d'exemple :

cp .mcp.json.example .mcp.json

3. Lancer le Serveur Standalone

Le serveur peut être lancé via le CLI dédié :

# Lancement standard
pnpm start

# Ou via le binaire directement
node dist/bin/cli.js

📦 Utilisation comme Bibliothèque

Vous pouvez désormais importer le moteur du runner dans vos propres scripts :

import { createServer, AgentManager, ClaudeRunner } from 'claude-code-runner';

// 1. Gérer les agents programmatiquement
const manager = new AgentManager();
await manager.createAgent('expert-seo', 'Tu es un expert SEO...', 'claude-3-5-sonnet');

// 2. Lancer une exécution sans passer par MCP
const runner = new ClaudeRunner();
const result = await runner.runAgent({
  agentName: 'expert-seo',
  prompt: 'Analyse le site example.com',
  autoResume: true,
});

console.log(result.result);

🛠️ Configuration MCP (Client)

Pour connecter ce runner à un client (Cursor, Claude Desktop, etc.), pointez vers le nouvel entrypoint CLI :

{
  "mcpServers": {
    "claude-runner": {
      "command": "node",
      "args": ["/CHEMIN_VERS_PROJET/dist/bin/cli.js"]
    }
  }
}

📂 Structure du Projet

src/services/ : Le cœur du système (Logique métier isolée en services).
src/tools/ : Les outils MCP qui appellent les services.
src/bin/cli.ts : Le point d'entrée exécutable pour le terminal.
src/server.ts : La définition du serveur FastMCP.
src/index.ts : Les exports publics (API de la bibliothèque).
.claude/ : Stockage des agents (Prompts .md et Settings .json).

Aperçu du Terminal

Projet propulsé par DeaMoN888 - 2026

Available Tools

7 tools

create_agentB

Crée un nouvel agent (Prompt + Config) compatible avec ce runner

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Nom de l'agent (ex: agent_finance). Sera utilisé pour les noms de fichiers.
`model`	No	Modèle à utiliser. Supporte tous les modèles compatibles avec Claude Code (Anthropic, OpenAI, DeepSeek, Glm, Minimax, etc.). Ex: claude-sonnet-4-5, gpt-4, deepseek-chat	claude-sonnet-4-5
`prompt`	Yes	Le prompt système (instructions) de l'agent.
`copyEnvFrom`	No	Chemin vers un settings.json existant pour copier les variables d'environnement (ex: .claude/settingsM.json)

TDQS

B3.4/5.0

Behavior2/5

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

Aucune annotation n'est fournie, donc la description porte toute la charge de transparence. Elle ne précise pas les effets secondaires (création de fichiers, écrasement potentiel), les prérequis ou le comportement en cas d'erreur.

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?

Une phrase concise et frontale qui résume l'action, sans verbiage inutile. Tous les mots sont utiles.

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?

Pour un outil de création avec 4 paramètres, 2 obligatoires, sans schéma de sortie ni annotations, la description ne couvre pas suffisamment le comportement attendu (retour, effets, contraintes).

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?

La couverture du schéma est de 100 %, chaque paramètre ayant une description. La description de l'outil n'ajoute pas de sens supplémentaire au-delà du schéma, ce qui correspond à la note de base de 3.

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?

La description indique clairement que l'outil crée un agent avec prompt et configuration, ce qui le distingue des outils frères comme 'create_prompt' (création de prompt uniquement) ou 'update_agent_config' (modification de configuration).

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?

La description n'offre pas de directives explicites sur quand utiliser cet outil par rapport à ses alternatives ni prérequis. L'utilisation est implicite via le nom et le contexte des outils frères.

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

create_promptA

Crée ou écrase un fichier prompt Markdown (Persona)

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Nom du fichier prompt (sans extension). Ex: 'analyse_financiere'
`content`	Yes	Contenu Markdown du prompt

TDQS

A3.5/5.0

Behavior4/5

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

The description explicitly mentions the overwrite behavior ('écrase'), which is a destructive action. Since no annotations are provided, this disclosure is important for an agent to understand the potential side effect.

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

Conciseness4/5

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

The description is a single concise sentence that is front-loaded with the action and resource. It avoids unnecessary words.

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 description lacks context about when to use the tool, success indications, error conditions, or how it differs from edit_prompt. For a tool with no output schema and no annotations, this is insufficient for an agent to fully understand its behavior.

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 provides full descriptions for both parameters (name and content), achieving 100% coverage. The tool description adds no additional parameter-specific meaning beyond the schema, so a score 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 tool creates or overwrites a prompt Markdown file (Persona), using the verb 'crée ou écrase' and specifying the resource. This distinguishes it from siblings like create_agent or edit_prompt.

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 on when to use this tool versus alternatives, such as edit_prompt. The description does not mention prerequisites or situations where overwriting is appropriate.

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

delete_agentA

Supprime définitivement un agent (Prompt et Config)

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Nom de l'agent à supprimer (ex: agent_finance)

TDQS

A4/5.0

Behavior4/5

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

Discloses that deletion is permanent, a key behavioral trait. No annotations exist, so description carries full burden. Could mention cascading effects or required permissions, but is adequate for a simple delete.

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

Conciseness5/5

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

Single sentence that is front-loaded and contains no filler. Every word is necessary and clear.

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 low complexity (one parameter, no output schema), the description is sufficient to understand the tool's function and input. Missing return value details are not an issue here.

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

Parameters3/5

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

Schema description coverage is 100%, so the parameter is well-documented in the schema. The description adds no new information about the parameter beyond its existence.

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?

Description clearly states the tool permanently deletes an agent, including its Prompt and Config. Verb and resource are specific and distinct from sibling tools like create_agent or list_agents.

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?

No explicit guidance on when or when not to use this tool versus alternatives. However, the context of sibling tools implies its use for deletion only.

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

edit_promptC

Modifie un prompt existant en remplaçant un bloc de texte spécifique

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Nom du fichier prompt à modifier (ex: 'agent_news')
`search`	Yes	Le texte exact à rechercher et remplacer
`replace`	Yes	Le nouveau texte de remplacement

TDQS

C2.8/5.0

Behavior2/5

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

No annotations provided; description only says 'replaces a specific text block' but does not disclose side effects, whether it modifies the file in place, or if the operation is reversible. Insufficient for a mutation tool.

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

Conciseness3/5

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

Single sentence is concise but lacks detail. Could include usage notes or examples without being verbose.

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?

Description is too brief for a tool with 3 required parameters. It doesn't specify behavior like exact match replacement, case sensitivity, or return value. Incomplete for effective use.

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 clear parameter descriptions. The tool description adds no additional meaning beyond the schema, meeting baseline.

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?

Description clearly states the verb 'modifie' (modify) and resource 'prompt existant' with specific action 'remplaçant un bloc de texte spécifique'. It distinguishes from sibling 'create_prompt' which is for creating new prompts.

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 vs alternatives. Lacks context about prerequisites or scenarios where editing is preferred over creating a new prompt.

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

list_agentsA

Liste tous les agents disponibles. Option 'details=true' pour voir la config complète.

ParametersJSON Schema

Name	Required	Description	Default
`details`	No	Si true, affiche les détails complets (modèle, config) de chaque agent.

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavior. It indicates a read-only list operation without side effects, but does not explicitly confirm non-destructiveness or mention any response details.

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

Conciseness5/5

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

Two concise sentences with no redundancy. Every word adds value. The structure is front-loaded with the main purpose.

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 list tool with one optional parameter and no output schema, the description is complete enough. It could mention that it returns agent names, but the core functionality is clear.

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 a clear description for the 'details' parameter. The description adds a brief mention of the option, but does not significantly enhance the schema'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 clearly states the tool lists all agents, with an option for full config. The verb 'list' and resource 'agents' are explicit. It distinguishes from siblings like create_agent or run_agent.

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

Usage Guidelines3/5

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

The description implies usage by listing agents, but does not explicitly state when to use this tool versus alternatives. No when-not or prerequisites are mentioned, though it's the only list tool.

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

run_agentB

Exécute une commande sur l'agent Claude configuré via CLI

ParametersJSON Schema

Name	Required	Description
`prompt`	Yes	Le prompt à envoyer à l'agent
`agentName`	No	Nom de l'agent (pour logging/monitoring et persistance)
`sessionId`	No	ID de session pour continuer une conversation (manuel)
`autoResume`	No	Si true (et agentName fourni), reprend automatiquement la dernière conversation de cet agent

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only states it executes a command, omitting side effects (e.g., conversation persistence, logging, rate limits, authentication requirements).

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

Conciseness4/5

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

The description is a single, concise sentence (10 words) that front-loads the core purpose. However, it could be slightly more descriptive without becoming verbose.

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

Completeness2/5

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

For a tool with 4 parameters, no output schema, and no annotations, the description lacks completeness. It does not mention return values, how to resume sessions, or error handling, leaving the agent uncertain.

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

Parameters4/5

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

Schema coverage is 100% with clear parameter descriptions. The prompt and agentName descriptions add context beyond naming (e.g., 'pour logging/monitoring et persistance'). The baseline is 3 due to high coverage, but the parameter descriptions are helpful.

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 'Exécute une commande sur l'agent Claude configuré via CLI' clearly states it runs a command on a Claude agent, distinguishing it from sibling tools that manage agents/prompts. However, 'commande' is slightly vague; 'prompt' would be more precise.

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 on when to use this tool versus alternatives (e.g., create_agent first) or prerequisites. The description does not indicate that the agent must be configured or that this is the primary execution tool.

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

update_agent_configB

Modifie la configuration technique d'un agent (Modèle, Serveurs MCP, Variables d'environnement)

ParametersJSON Schema

Name	Required	Description
`env`	No	Variables d'environnement supplémentaires à définir ou écraser (ex: { 'API_KEY': '123' })
`name`	Yes	Nom de l'agent à modifier
`model`	No	Nouveau modèle à utiliser. Supporte tous les modèles compatibles avec Claude Code (Anthropic, OpenAI, DeepSeek, Glm, Minimax, etc.). Ex: claude-sonnet-4-5, gpt-4, deepseek-chat
`mcpServers`	No	Liste complète des serveurs MCP à activer (remplace la liste existante). Ex: ['postgresql', 'news']

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 must disclose behavioral traits. It only says 'modifies configuration' without explaining mutation details, idempotency, error behavior, or prerequisites beyond the schema.

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?

A single, front-loaded sentence that efficiently conveys the purpose without extraneous words.

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

Completeness2/5

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

Given 4 parameters, no output schema, and no annotations, the description lacks completeness. Missing return value, error scenarios, and update semantics (partial vs full replacement).

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description adds minimal value beyond listing the parameter categories already evident from the schema names.

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

Purpose5/5

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

The description clearly states the tool modifies an agent's technical configuration, listing the specific aspects (Model, MCP Servers, Environment Variables). It distinguishes from siblings like create_agent and delete_agent.

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 on when to use this tool versus alternatives like create_agent or run_agent. Sibling tools are not referenced, and no context for decision-making is provided.

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.

7 tool updatesv1.0.0Jul 6, 2026
- First observedcreate_agent
- First observedcreate_prompt
- First observeddelete_agent
- First observededit_prompt
- First observedlist_agents
- First observedrun_agent
- First observedupdate_agent_config

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct operation: agent creation vs prompt creation, agent deletion, prompt editing, listing agents, running agents, and config updating. The descriptions clearly differentiate them, so no ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_agent, edit_prompt, run_agent), making them predictable and easy to understand.

Tool Count5/5

With 7 tools, the server covers the essential operations for managing and running agents without being overly narrow or bloated. The number fits the scope well.

Completeness4/5

The tool set covers create, read, update, delete for agents and prompts, plus execution. A minor gap is the lack of a dedicated get_agent tool (though list_agents with details=true partly covers it), but overall the surface is solid.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

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

microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
supportsheep
io.github.pooriaarab
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Customer Support Content Management Systems Marketing
1

Related MCP Servers

SafeFlo
Knowledge & Memory Agent Orchestration Autonomous Agents
G1ngercy
A
license
Not graded
quality
C
maintenance
Local MCP server for Claude Code providing persistent memory, task planning, and agent coordination with full transparency and no network calls.
Updated 24 days ago (2026-08-12 20:42 UTC)
2
MIT
cc-agent
Autonomous Agents Coding Agents Version Control
Gonzih
A
license
A
quality
B
maintenance
MCP server that spawns autonomous Claude Code agents in GitHub repos, enabling task delegation with persistent state, multi-step workflows, and job monitoring.
Updated 2 months ago (2026-06-21 20:37 UTC)
47
94
2
Apache 2.0
cc-tap
Agent Orchestration Developer Tools
es617
A
license
A
quality
D
maintenance
An MCP server that bridges Claude Desktop and Claude Code by letting Desktop read and interact with Claude Code Remote Control sessions, enabling cross-agent coordination.
Updated 5 months ago (2026-04-16 15:52 UTC)
6
3
MIT
Claude Code MCP Server
Code Execution File Systems Command Line
trickv
A
license
Not graded
quality
D
maintenance
An MCP server that allows Claude Desktop to remotely control Claude Code instances for executing commands and managing files.
Updated a year ago (2025-10-21 01:40 UTC)
30
GPL 3.0

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/DeamonDev888/-SIMPLE-CLAUDE-API-RUNNER-'

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