What can you do with this server?

obot-admin-mcp lets you manage a self-hosted obot MCP gateway directly from an MCP client, without needing to touch the admin UI or REST API manually. * List MCP servers — Retrieve all registered MCP servers with their ID, name, runtime, configured state, and connectURL. * Inspect a specific server — Fetch full details for a server by ID, including its manifest, environment variables, and any missing required env vars. * Add an npm/npx-based MCP server — Install a new stdio MCP server from an npm package, with optional env vars, sensitive key marking, alias, and description. * Register a remote MCP server — Point obot at an external HTTP/SSE MCP endpoint so obot proxies it, with optional alias and description. * Configure an existing MCP server — Set or update runtime environment variables to fill in missing required values. * Delete an MCP server — Permanently remove a registered MCP server from obot by its ID. * Browse the obot catalog — List available MCP catalog entries, with an optional substring filter to search by name or ID.

How do I use obot-admin-mcp?

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., "@obot-admin-mcp list all MCP servers in obot" 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.

de en es ja ko ru zh

obot-admin-mcp

by kiarashedraki

Overview Schema Related Servers Score Discussions

JavaScript

Remote

obot-admin-mcp

An MCP server that lets an MCP client (claude.ai, Claude Desktop, etc.) manage a self-hosted obot MCP gateway via its REST API. Use it to install, list, inspect, and remove MCP servers in obot from inside the chat client.

Why

obot exposes each registered MCP server as https://<obot-host>/mcp-connect/<id>. To install a new MCP server you normally hit obot's REST API or its admin UI. This package wraps the relevant endpoints as MCP tools, so once you register obot-admin-mcp in obot itself and wire its connectURL into claude.ai, you can ask Claude to "install the n8n MCP" or "list everything obot has" and it just works.

Related MCP server: mcp-uni

Tools

list_mcp_servers — id, name, runtime, configured-state, connectURL.
get_mcp_server(id) — full manifest, env, missing required vars.
add_npx_mcp(name, package, env?, sensitiveKeys?, shortDescription?, alias?) — install an npm-published stdio MCP. Auto-calls /configure if env is supplied.
add_remote_mcp(name, url, shortDescription?, alias?) — register a remote HTTP/SSE MCP.
delete_mcp_server(id) — remove an MCP from obot.
configure_mcp_server(id, env) — set runtime env values on an existing server (fills missingRequiredEnvVars).
list_catalog_entries(search?) — browse obot's catalog (default 81 entries).

Configuration

Two env vars:

Var	Required	Notes
`OBOT_URL`	yes	Base URL of your obot, e.g. `https://obot.example.com`
`OBOT_TOKEN`	yes	obot bootstrap or admin token

Run locally (Claude Desktop / dev)

Install direct from this repo (no npm publish required — built dist/ is committed):

{
  "mcpServers": {
    "obot-admin": {
      "command": "npx",
      "args": ["-y", "github:kiarashedraki/obot-admin-mcp"],
      "env": {
        "OBOT_URL": "https://obot.example.com",
        "OBOT_TOKEN": "<your-token>"
      }
    }
  }
}

Register inside obot (the meta loop)

curl -X POST "$OBOT_URL/api/mcp-servers" \
  -H "Authorization: Bearer $OBOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "manifest": {
      "name": "obot-admin",
      "shortDescription": "Manage obot itself",
      "runtime": "npx",
      "npxConfig": { "package": "github:kiarashedraki/obot-admin-mcp" },
      "env": [
        { "key": "OBOT_URL",   "value": "https://obot.example.com", "required": true,  "sensitive": false },
        { "key": "OBOT_TOKEN", "value": "<token>",                  "required": true,  "sensitive": true  }
      ]
    },
    "alias": "obot-admin"
  }'

The response includes connectURL — paste that into claude.ai → Settings → Connectors → Add custom connector.

Security

The bootstrap/admin token gives full control of obot, which mounts the host docker socket. Treat the token like a root credential. Do not register obot-admin-mcp on a shared/multi-tenant obot without an additional auth wall (e.g., Cloudflare Access in front of obot-connect/<id>).

License

MIT

Available Tools

6 tools

add_npx_mcpA

Install a new MCP server in obot that runs as npx <package> (stdio). Use this for npm-published MCP servers.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Display name shown in obot UI.
`package`	Yes	npm package name, e.g. n8n-mcp or @scope/foo.
`shortDescription`	No
`env`	No	Env vars passed to the MCP process. Keys go in manifest.env[]. Mark secrets via sensitiveKeys.
`sensitiveKeys`	No	Keys in `env` that should be marked sensitive (API keys, tokens).
`alias`	No	Optional short alias used in URLs/logs.

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It fails to disclose side effects like network access, system dependencies, or error behavior on missing packages. Only states the execution mechanism (npx + stdio).

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

Conciseness5/5

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

Two sentences with no extraneous text. Action verb 'Install' is front-loaded. Efficient and to the point.

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?

Given 6 parameters, no output schema, and no annotations, the description is minimal. It does not explain the installation process, prerequisites, or what 'obot' is. Adequate but could be more complete for a tool with this complexity.

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 83%, setting a baseline of 3. The description adds no parameter-specific information beyond the schema. While the schema already describes parameters well, the description does not enhance understanding of how they affect behavior.

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 it installs a new MCP server running as `npx <package>` via stdio. It is distinct from siblings like add_remote_mcp, which likely handles remote servers.

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?

Specifies 'Use this for npm-published MCP servers,' providing clear context. Does not explicitly state when not to use, but the sibling tool add_remote_mcp covers other cases, making usage boundaries implicit.

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

add_remote_mcpA

ParametersJSON Schema

Name	Required	Description
`name`	Yes
`url`	Yes	Remote MCP endpoint URL.
`shortDescription`	No
`alias`	No

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It mentions proxy behavior but lacks details on side effects, authentication, rate limits, or what happens on failure. Insufficient for a registration tool.

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

Conciseness5/5

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

Extremely concise two sentences with no waste. Front-loaded with purpose and use case.

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?

With 4 parameters, no output schema, and no annotations, description is too minimal. Lacks info on return values, validation, error handling, or any guarantees about the proxy behavior.

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

Parameters2/5

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

Only 25% of parameters have descriptions in schema (url only). Description adds no further parameter details, leaving agents to guess semantics for name, shortDescription, alias.

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 it registers a remote MCP server URL for proxying, and specifies use case for HTTP/SSE MCPs, differentiating it from siblings like add_npx_mcp.

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

Usage Guidelines4/5

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

Explicitly states to use for HTTP/SSE MCPs hosted elsewhere, providing clear context. However, no explicit when-not-to-use or alternative tools mentioned beyond the context.

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

delete_mcp_serverA

Delete an MCP server from obot by id. Irreversible.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

Despite no annotations, the description highlights irreversibility, which is a key behavioral trait. However, it does not disclose permissions, effects on dependent resources, or error scenarios, leaving 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?

Two short sentences, front-loaded with the primary action. Every word earns its place, no superfluous content.

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 delete tool with one required parameter and no output schema, the description covers purpose and irreversibility. Lacks but not critical: indication of expected response.

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

Parameters2/5

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

The single parameter 'id' has no description in the schema (coverage 0%) and the tool description does not explain what the ID represents. This leaves ambiguity for the agent.

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?

Clear verb 'Delete' and specific resource 'MCP server from obot by id'. It distinctly describes the tool's action and differentiates from sibling tools like add, get, list.

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. The description only notes irreversibility but lacks context on prerequisites or when other tools are more appropriate.

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

get_mcp_serverA

Get full details of one MCP server by id (including manifest, env, missingRequiredEnvVars).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	MCP server id, e.g. ms1mwrmr

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description effectively communicates the tool's read-only nature by listing returned fields; however, it does not disclose potential side effects or rate limits, which is acceptable for a simple retrieval tool.

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

Conciseness5/5

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

Single sentence front-loads the action and key details, with no redundant words; ideal conciseness for quick understanding.

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

Completeness5/5

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

Given the simple input (single required parameter) and no output schema, the description adequately informs the agent of what is returned, including specific fields, making it complete.

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%; the description adds no extra meaning beyond the schema's id parameter description, meeting the baseline without additional value.

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 concisely states the tool retrieves full details of one MCP server by ID, specifying key fields (manifest, env, missingRequiredEnvVars), and clearly distinguishes from sibling tools like list_mcp_servers.

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 to use this tool versus alternatives; the context implies usage when a specific server ID is known, but lacks when-not scenarios or explicit comparison to list_mcp_servers.

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

list_catalog_entriesB

List MCP catalog entries available in obot's default catalog. Optional substring filter on name/id.

ParametersJSON Schema

Name	Required	Description	Default
`search`	No

TDQS

B3.2/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 disclose behavior. It correctly implies a read operation but does not mention potential behavior like pagination, rate limits, or what happens when the catalog is empty. The description is too sparse for a tool with no other behavioral cues.

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 efficiently conveys the action and the optional filter. It is front-loaded with the primary purpose and wastes no words.

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?

Given the tool has one optional parameter and no output schema, the description adequately covers the basic operation. However, it does not specify the return format (e.g., list of entry IDs, full entry objects) or any constraints (e.g., maximum results), which would be helpful for an agent to process the results correctly.

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

Parameters4/5

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

The schema has one parameter 'search' with no description. The tool description adds that it is an 'optional substring filter on name/id', which provides meaningful semantic context. However, it doesn't clarify case sensitivity or wildcard behavior, so it's not fully exhaustive.

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 it lists MCP catalog entries from a specific source (obot's default catalog). The verb 'list' is unambiguous, and the optional filter is mentioned. However, it does not explicitly distinguish this from the sibling tool list_mcp_servers, which might confuse agents about which list to use.

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 provides no guidance on when to use this tool versus its siblings. It doesn't specify that this is for browsing predefined entries versus the list_mcp_servers tool which lists added servers. An agent would have to infer the distinction from tool names alone.

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

list_mcp_serversA

List MCP servers currently registered in obot. Returns id, name, runtime, configured-state, and the connectURL you'd hand to claude.ai.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/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 compensate. It lists return fields, suggesting a read operation, but does not explicitly state it's non-destructive, mention authentication needs, or describe any side effects. Basic transparency is achieved, but more detail on behavior (e.g., ordering, pagination) is missing.

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 states the purpose and key details. Every word adds value; there is no redundancy or wasted space.

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

Completeness4/5

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

The description lists all return fields, compensating for the lack of an output schema. For a zero-parameter list tool, it provides sufficient context. However, it does not explain field content (e.g., what 'configured-state' means) or any limitations, leaving minor gaps.

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?

There are 0 parameters and schema coverage is 100%. The description correctly adds no parameter info, as none are needed. For zero-parameter tools, the baseline score is 4, and this description meets that standard.

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 MCP servers and specifies the returned fields (id, name, runtime, configured-state, connectURL). It distinguishes from sibling tools like add_npx_mcp, delete_mcp_server, etc., which are for creating, deleting, or retrieving individual servers.

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 when you need to view registered MCP servers. While it doesn't explicitly list when not to use or name alternatives, the sibling tool names provide context, and the straightforward list operation needs minimal guidance.

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 updatesv0.1.0May 5, 2026
- First observedadd_npx_mcp
- First observedadd_remote_mcp
- First observeddelete_mcp_server
- First observedget_mcp_server
- First observedlist_catalog_entries
- First observedlist_mcp_servers

Install Server

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

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct operation: adding (two types), deleting, getting details, listing servers, and listing catalog. No overlap in purpose.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., add_npx_mcp, delete_mcp_server, list_mcp_servers).

Tool Count5/5

6 tools cover the essential CRUD and listing operations for an MCP admin server without being excessive or insufficient.

Completeness4/5

Covers create, read, delete operations but lacks an update/modify tool (e.g., to change environment variables or configuration).

Maintenance

ActivityInactive

ResponsivenessNo issues

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

mcp-serverOAuth
com.pdfgate
MCP server for the PDFGate API. Generate PDFs, manage documents and handle e-signatures.
Documentation Access File Systems
1
postman-mcp-server
com.postman
A basic MCP server to operate on the Postman API.
API Testing Developer Tools App Automation
3311
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
mcp AOAuth
com.mux
The official MCP Server for the Mux API
Multimedia Processing Entertainment & Media API Testing
22168

Related MCP Servers

OBS MCP Server
App Automation Multimedia Processing
royshil
A
license
B
quality
D
maintenance
A server that provides tools to control OBS Studio remotely via the OBS WebSocket protocol, enabling management of scenes, sources, streaming, and recording through an MCP client interface.
Updated a year ago (2025-08-26 17:22 UTC)
100
170
122
GPL 2.0
mcp-uni
Developer Tools Agent Orchestration
iHeyTang
A
license
Not graded
quality
C
maintenance
A universal MCP server that acts as a unified gateway for dynamically connecting and managing multiple MCP servers via a single HTTP endpoint.
Updated a year ago (2025-08-26 07:48 UTC)
24
6
MIT
mcpwrap
Developer Tools API Testing
m4cd4r4
F
license
Not graded
quality
C
maintenance
MCP server that wraps any REST API with an OpenAPI spec, dynamically creating MCP tools at runtime without code generation.
Updated 6 months ago (2026-03-12 12:44 UTC)
12
-
uni-mcp-gateway
Agent Orchestration Developer Tools Security
dropoutsanta
A
license
Not graded
quality
D
maintenance
A unified MCP gateway that aggregates multiple MCP servers and API plugins behind a single endpoint with authentication, rate limiting, audit logging, REST API bridge, and web dashboard.
Updated 4 months ago (2026-04-27 09:25 UTC)
8
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/kiarashedraki/obot-admin-mcp'

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