unraid-code-mode-mcp
Allows interaction with the Unraid API via GraphQL, enabling AI agents to query and manage Unraid server resources such as shares, VMs, Docker containers, array, and more.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@unraid-code-mode-mcpWhat's the current array status and list shares?"
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.
unraid-code-mode-mcp
A code-mode MCP server for the Unraid 7.2+ GraphQL API. Exposes two MCP tools — search and execute — that let an LLM agent introspect and call any Unraid GraphQL field by writing JavaScript that runs inside a sandboxed QuickJS WASM context.
Built as the GraphQL-flavoured sibling of unifi-code-mode-mcp and fortimanager-code-mode-mcp. Same architecture, same sandbox model, adapted to GraphQL introspection instead of OpenAPI.
Project status
This is a public beta. Install from source. Not on npm yet.
The server boots, both tools work, and the test suite is green (56/56 unit + integration tests across spec loader, dispatcher, sandbox, HTTP client, multi-tenant context, and server transports). A standalone
npm run test:sandboxscript exercises the QuickJS sync + Promise-callback host bridge with 25 sequential awaits, a 10-wayPromise.all, mixed sequential/parallel patterns, and error propagation — these are the patterns LLMs actually emit, and they are the regression bar for the bridge.Verified live against a single real Unraid 7.2 box (the maintainer's homelab) via
scripts/mcp-call.mjsdriving the stdio transport directly:info,array,shares,vms,docker, andonlinereads succeed; the VMSHUTOFF → RUNNING → SHUTOFFcycle viavmStart/vmStopmutations succeeds; sequential awaits andPromise.allboth work end-to-end with real GraphQL latency; and the bundled SDL fallback path (introspection disabled) returns a human-readable diagnostic with a remediation hint instead of an opaqueHTTP 400. The bundled SDL is pinned to a taggedunraid/apirelease (currentlyv4.33.0, nomain-drift) and the introspection-disabled fallback is exercised by unit tests.End-to-end LLM-mediated invocation is verified through two clients against the same Unraid 7.2 box:
Client
Model
Status
Transcript
cursor-agentv2026.05.05Claude Sonnet 4.6 (
claude-4.6-sonnet-medium)VERIFIED — 3 prompts including a full live
info/array/shares/vms/docker/onlineoverview rendered to a Markdown table; error-path prompt handled correctly without invented recovery
opencodev1.14.30DeepSeek v4 Flash via
opencode-go/deepseek-v4-flashVERIFIED on schema-only path; live execute hit a mid-test upstream CSRF flip — schema smoke (102 ops) green; the live overview produced valid
Promise.alltyped-query code on the first try and the model handled the upstreamInvalid CSRF token / 401gracefully (explained, suggested re-auth, did not flail)See
examples/unraid-expert-agent/for the persona (AGENTS.md), a vetted set of sample prompts, and cross-platform install snippets.NOT verified by us (and where help is welcome): every agent / IDE client beyond cursor-agent CLI and opencode — Cursor IDE chat panel, Claude Code, Claude Desktop, VS Code + Copilot, Codex CLI, Continue, Cline, Aider, Zed, MCP Inspector (CLI + UI); the Streamable HTTP transport in multi-tenant mode; the Cloudflare Workers entry (scaffolded but not deployed); any non-VM mutation (Docker container start/stop, share/disk operations, parity ops); any Unraid box other than the maintainer's. We need testers — please file verification reports and bug reports with whatever you find. See
CONTRIBUTING.mdfor the rules.
Related MCP server: mcp-graphql-bridge
Why "code mode"?
The default MCP pattern is one tool per API operation. A typical Unraid 7.2 schema has ~57 queries and ~45 mutations across 240+ types — registering all of those as discrete MCP tools blows past every commercial agent's tool-list cap.
Code mode flips that: instead of a hundred tools, you get two. The LLM uses search to figure out what to call (no network), then writes a tiny JS snippet for execute that talks to the live API. See Cloudflare's code mode post for the full pattern, or the architecture doc for the per-module breakdown.
Highlights
Two tools.
searchis read-only;executeruns sandboxed JS that calls real Unraid GraphQL.Typed convenience calls.
unraid.local.query.<fieldName>({ args, fields })andunraid.local.mutation.<fieldName>({ args, fields })synthesise the GraphQL document for you using introspected arg types.Raw escape hatch.
unraid.local.graphql({ query, variables })posts any document;unraid.local.request({ method, path, body })covers the rare non-GraphQL endpoints.Single- and multi-user modes. Single-user via env vars (stdio), multi-user via
X-Unraid-Api-KeyHTTP headers.Per-tenant TLS. Custom CA bundles or
insecuremode survive into a per-request undici dispatcher.Bundled SDL fallback. Server can boot without an Unraid server — it parses the latest committed
src/spec/local-fallback.graphqlsosearchis immediately useful.Cloudflare Workers entry. A scaffold using
@cloudflare/codemodeships incf-worker/. See cf-worker/README.md.
Quick start
git clone https://github.com/jmpijll/unraid-code-mode-mcp
cd unraid-code-mode-mcp
npm install --legacy-peer-deps
cp .env.example .env
# edit .env — set UNRAID_BASE_URL + UNRAID_API_KEY
npm run devWire it into your MCP client. For Cursor, add to .cursor/mcp.json:
{
"mcpServers": {
"unraid": {
"command": "node",
"args": ["/absolute/path/to/unraid-code-mode-mcp/dist/index.js"]
}
}
}(Run npm run build first if you point at dist/. Or use npx tsx against src/index.ts for live development.)
Creating an Unraid API key
The API key is what authenticates the MCP server's calls to your Unraid box. Two ways to mint one:
Option A — Web UI. Go to Settings → Management Access → API Keys and create a key with the ADMIN role (or scope it down to whatever you actually want the agent to do). Copy the value into UNRAID_API_KEY.
Option B — CLI on the Unraid box. SSH in and run:
unraid-api apikey --create --name "mcp" --roles ADMIN --jsonThe JSON output contains a key field; that's UNRAID_API_KEY.
UNRAID_BASE_URL should be the URL you'd visit in a browser to reach the web UI (no path, no trailing slash) — e.g. https://tower.local or https://192.168.1.10.
TLS on Unraid
Unraid 7.2+ usually serves over HTTPS using a self-signed *.unraid.net certificate fronted by the LAN proxy. The MCP server has three options:
Recommended: install the Unraid root CA on the host, or fetch it and pass
UNRAID_CA_CERT_PATH=/path/to/ca.pem.Lab use:
UNRAID_INSECURE=trueskips verification. Logged on every request.Multi-tenant: clients can supply
X-Unraid-Ca-Certand/orX-Unraid-Insecure: trueper request.
See docs/security.md for the full picture.
Sample interactions
Discover the schema:
// search tool
searchOperations('docker', 10).map(function (op) { return op.name + ' (' + op.kind + ')'; });// search tool — drill into a single op
getOperation('info');Run a query (verified live on Unraid 7.2):
// execute tool
const info = await unraid.local.query.info({
fields: ['os { distro release kernel uptime }', 'cpu { manufacturer brand cores threads }'].join(' '),
});
return info;Read multiple things — sequential await and Promise.all both work:
// execute tool — sequential awaits (fine; full canonical async)
const info = await unraid.local.query.info({ fields: 'os { distro }' });
const arr = await unraid.local.query.array({ fields: 'state' });
const shares = await unraid.local.query.shares({ fields: 'name free used size' });
return { info, arr, shares };// execute tool — parallel batch (faster when calls are independent)
const [info, arr, shares, online] = await Promise.all([
unraid.local.graphql({ query: 'query { info { os { distro release kernel } cpu { brand cores threads } } }' }),
unraid.local.graphql({ query: 'query { array { state } }' }),
unraid.local.graphql({ query: 'query { shares { name free used size } }' }),
unraid.local.graphql({ query: 'query { online }' }),
]);
return { info, arr, shares, online };Run a mutation:
// execute tool
return await unraid.local.mutation.archiveAll({});Fall back to raw GraphQL:
// execute tool
const data = await unraid.local.graphql({
query: 'query { array { state capacity { kilobytes { free total } } } }',
});
return data;Documentation
Usage guide — the search/execute API in detail.
Architecture — per-module breakdown, request lifecycle.
Multi-tenant deployment — HTTP transport + headers.
Deployment — Node / Docker / Cloudflare.
Security — sandbox properties, TLS, Unraid 7.2 CSRF behaviour, threat model.
Cursor coupling guide —
.cursor/mcp.jsonshapes,cursor-agentquirks, smoke commands.opencode coupling guide —
opencode.jsonshape, permissions, headless verification.Verification transcripts — sanitized records of every live end-to-end run we have.
Verifying your install
npm run build
npm test # 65 unit + integration tests
npm run test:sandbox # QuickJS host-bridge stress (no Unraid box needed)
npm run smoke:inspector # MCP Inspector CLI smoke against built dist (no Unraid box needed)If smoke:inspector prints OK: both 'search' and 'execute' tools exposed by dist/index.js, your build is wire-compatible with any MCP client. The sandbox stress doubles as the regression bar for the Promise-callback host bridge.
Multi-user / multi-tenant
Run with MCP_TRANSPORT=http and without env credentials. The MCP HTTP transport listens on POST /mcp + GET /health, and every request must carry:
X-Unraid-Api-KeyX-Unraid-Base-UrlX-Unraid-Insecure(optional,trueto skip TLS verification)X-Unraid-Ca-Cert(optional, PEM-encoded CA bundle)
Origin allowlist defaults to localhost; tune via MCP_HTTP_ALLOWED_ORIGINS. See docs/multi-tenant.md.
Verification status
What we have directly verified so far:
Layer | How | Result |
Unit tests | Vitest, 56 specs across spec loader, dispatcher, sandbox, HTTP client, multi-tenant context, and server transports | ✅ all green |
Integration tests | In-process | ✅ green |
QuickJS host-bridge stress |
| ✅ green; this is the regression bar after the asyncify → sync + Promise-callback rewrite |
SDL fallback (introspection disabled) | Server boots without an Unraid box, parses bundled | ✅ green; the |
Live read sweep on a real Unraid 7.2 box |
| ✅ all queries returned real data; sequential awaits and |
Live mutation round-trip on the same box | VM | ✅ full cycle completed; error propagation verified by attempting |
Linter + formatter + typecheck |
| ✅ clean |
What is not yet verified (and where help is welcome):
Any agent / IDE client. All live verification so far has been through
scripts/mcp-call.mjsdriving the stdio transport directly. Cursor (chat panel), Claude Code, Claude Desktop, VS Code + Copilot, Codex CLI, Continue, Cline, opencode, Aider, Zed, the MCP Inspector (CLI and UI) — all wired but NOT verified by us. End-to-end LLM-mediated invocation is the most useful thing testers can report on.Streamable HTTP transport in multi-tenant mode. The transport is wired and unit-tested; a real multi-tenant deployment behind a reverse proxy with header-based credentials is not.
Cloudflare Workers entry.
cf-worker/is scaffolded against@cloudflare/codemodebut the WebRequest/Response↔ MCP SDK Node-stream adapter is not implemented, and the Worker is not deployed anywhere. Tracked incf-worker/README.md.Mutations beyond VM start/stop. Docker container
start/stop, parity checkstart/cancel, share / disk operations, user / API-key management, and the full mutation surface are wired through the typed dispatcher but not live-verified. Probing them blindly against live hardware is unsafe; we want testers with redundant homelabs.Unraid Connect cloud surface.
unraid.connect.*is reserved inTenantContextand not yet implemented. The current server only talks to a controller you can reach over the LAN.Real Unraid boxes other than the maintainer's homelab. A single Unraid 7.2 box is not enough to generalise resilience claims — different array configs, plugin sets, network topologies, and Unraid versions will all surface different edge cases.
Long-running soak / stability under sustained load.
Roadmap
Done in v0.1.0-beta.2 and v0.1.0-beta.3:
✅ Expose the sandbox wall-clock deadline as
UNRAID_EXECUTE_TIMEOUT_MS(1 s – 10 min, default 30 s). Useful for slow-booting VMs and for very largePromise.allbatches against a controller under load. (beta.2)✅ CSRF-aware error decoration — when an Unraid box returns
extensions.code: UNAUTHENTICATED+Invalid CSRF token, the MCP server adds a remediation hint pointing at API key re-mint, the curl sanity check, and the box-side log path. Seedocs/security.md. (beta.2)✅ MCP
serverInfo.versionreads frompackage.jsonat runtime — no more hand-stamped version drift between releases. (beta.2)✅ End-to-end LLM-mediated invocation verification through
cursor-agent(Claude Sonnet 4.6) andopencode(DeepSeek v4 Flash). See the verification matrix above. (beta.2)✅ Auto-bump bundled SDL pin —
.github/workflows/update-spec.ymlruns weekly, detects newunraid/apireleases, regeneratessrc/spec/local-fallback.graphql, and opens a PR with a release-notes link for human review. (beta.3)✅
npm run smoke:inspector— local mirror of the CI MCP Inspector smoke. Boots the builtdist/index.jsserver, requeststools/list, asserts both tools are exposed. CI now uses the same script. (beta.3)
Still open (rough order, highest-leverage first):
More LLM clients verified — Claude Code CLI, Claude Desktop, MCP Inspector UI (CLI smoke is in CI), VS Code + Copilot. Roadmap item, gating for
1.0.0.Streamable HTTP multi-tenant deployment verified against a real reverse proxy with rotating per-tenant credentials.
Mutation verification matrix beyond VM start/stop — Docker container lifecycle, parity checks, share/disk ops — once we have testers with redundant hardware.
unraid.connect.*namespace for the Unraid Connect cloud API. Reserved inTenantContexttoday, not yet implemented.Cloudflare Workers transport adapter (the bridge from Web
Request/Responseto the MCP SDK's NodeIncomingMessage/ServerResponse). Tracked incf-worker/README.md.NPM publish — reserved for
1.0.0. The package is"private": trueuntil then.
Contributing
See CONTRIBUTING.md. Use Conventional Commits (feat:, fix:, chore:, docs:, test:, ci:).
License
MIT — see LICENSE.
Available Tools
2 toolsexecuteExecute Unraid GraphQL operationsA
Run Unraid GraphQL operations by writing JavaScript that uses the unraid.local namespace.
Although the sandbox is JavaScript, the calls below appear synchronous — await is supported and recommended. Each call returns once the host-side HTTP request settles.
Surfaces:
unraid.local.graphql({ query, variables, operationName })— POST any GraphQL document directly to/graphql. Returns the unwrappeddatafield.unraid.local.query.<fieldName>({ args, fields })— typed query call.argsmap to GraphQL variables;fieldsis either a GraphQL selection-set string (no wrapping braces) or a shorthand array of leaf field names.fieldsis required for non-scalar return types.unraid.local.mutation.<fieldName>({ args, fields })— typed mutation call, same rules.unraid.local.request({ method, path, body, headers })— raw HTTP escape hatch for endpoints outside GraphQL. Returns{ status, body, headers }.unraid.local.spec—{ title, version, sourceUrl, queryCount, mutationCount }for diagnostics.
Operations are async — use await. The final expression is the tool result.
Examples
// Read system info via a typed query.
const info = await unraid.local.query.info({
fields: ['os { distro release kernel }', 'versions { unraid api }', 'cpu { manufacturer brand cores }'].join(' '),
});
return info;// List Docker containers with a shorthand selection.
const containers = await unraid.local.query.dockerContainers({
fields: ['id', 'names', 'state', 'status', 'image'],
});
return containers.map(function (c) { return { name: c.names[0], state: c.state }; });// Raw GraphQL document — handy for fragments and aliases.
const data = await unraid.local.graphql({
query: 'query { array { state capacity { kilobytes { free total } } } }',
});
return data;Limits
Hard ceiling on API calls per execute; exceeded → error.
Sandbox memory + time bounded.
Credentials never enter the sandbox.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript code to execute against the live Unraid GraphQL API. Use await — operations are async. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: async execution, sandbox memory/time bounds, credential isolation, and API call limits leading to errors. It also explains return value structures, leaving little ambiguity about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (overview, methods, examples, limits) and front-loads the purpose. While each section contributes value, the examples are somewhat lengthy, and the overall length could be trimmed slightly without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return types, error conditions, limits, and provides multiple examples. It sufficiently equips an agent to use the tool correctly, lacking only explicit comparison to siblings but otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'code' has a basic schema description, but the tool description adds immense value by detailing how to write the JavaScript, available methods, and examples. This significantly enhances the agent's understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as executing JavaScript to run Unraid GraphQL operations using the `unraid.local` namespace. It differentiates from the sibling 'search' by implying a code execution context rather than a simple search, and provides specific methods and examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers extensive guidance on internal usage: async/await, typed vs raw calls, examples, and limits. However, it does not explicitly contrast with the sibling tool 'search' or state when to use this tool versus that alternative, which would improve cross-tool decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch Unraid GraphQL schemaA
Search the Unraid GraphQL schema by writing JavaScript.
The sandbox is read-only — no network. Use this tool to discover what to call before invoking execute.
Globals
index—{ namespace, title, version, sourceUrl, operations[], types }. Each operation is the compact form:{ kind: 'query'|'mutation', namespace: 'local', name, description, args, returnType, returnTypeFields, deprecated }.unraid.local— same shape asindexfor parity with the execute tool. May benullif no spec is loaded.searchOperations(query, limit?)— text-ranked search across name, description, args, and return type.getOperation(name)— full operation info including arg types and return-type field hints.findOperationsByName(substring)— list operations whose name contains the substring (case-insensitive).getType(typeName)— full named-type info (fields for OBJECT/INTERFACE/INPUT_OBJECT, members for UNION, enumValues for ENUM).console.log()— captured into the tool output.
Examples
// All queries that mention "docker"
searchOperations('docker', 20).map(function (op) { return op.name; });// Full detail on the `info` query
getOperation('info');// Inspect the Array type to see its fields
getType('Array');| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript code to execute against the operation index. The final expression is returned. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It explicitly states the sandbox is read-only and has no network, which are critical traits. It also describes the sandbox environment, available globals, and that console.log output is captured. This provides sufficient transparency, though it could mention response format or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for globals, functions, and examples. Every sentence adds value. However, it is somewhat verbose; the examples and function lists could be slightly condensed without losing clarity. Still, the structure aids comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (JavaScript execution in a sandbox with multiple globals and no output schema), the description is remarkably complete. It covers the environment, all available functions with their purpose, input/output shapes, and concrete examples. An agent could immediately use the tool correctly based on this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'code' with a minimal description. The tool's description compensates extensively by detailing the global functions and variables available (e.g., searchOperations, getOperation, getType), their signatures, and usage examples. This adds immense meaning beyond the schema, effectively teaching the agent how to construct the JavaScript code.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search the Unraid GraphQL schema by writing JavaScript.' It specifies the resource and action, and distinguishes from sibling 'execute' by positioning this as a discovery tool before invocation. The verb 'search' and resource 'Unraid GraphQL schema' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to discover what to call before invoking 'execute', and notes the sandbox is read-only with no network. It does not explicitly state when not to use it, but the sibling relationship and discovery purpose imply that. The examples further guide usage, making it nearly complete.
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.
2 tool updates
v0.1.0-beta.3- First observed
execute - First observed
search
TDQS
The two tools have clearly distinct purposes: 'execute' runs GraphQL operations, while 'search' explores the schema. There is no overlap, and their descriptions unambiguously differentiate them.
Both tool names are single, lowercase verbs that directly describe their function. Although they lack a verb_noun pattern, they follow a consistent, simple style that is easy to understand.
With only 2 tools, each covers a fundamental aspect of interacting with a GraphQL API: discovery and execution. The count is perfectly scoped for the server's purpose, avoiding unnecessary complexity.
The server provides all necessary functionality: you can explore the schema with 'search' and then execute any discovered operation with 'execute'. There are no obvious gaps in coverage.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
The Grafbase MCP server sits in front of a GraphQL API and exposes an MCP protocol-compliant interface that allows AI agents and LLMs to explore and query GraphQL APIs using natural language. It provides tools to search schemas, introspect types and fields, and execute GraphQL queries while minimizing context bloat by returning only relevant schema subsets, with built-in support for authentication, authorization, and configurable access control.
An MCP server that gives your AI access to the source code and docs of all public github repos
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Related MCP Servers
- AlicenseNot gradedqualityFmaintenanceA MCP server that exposes GraphQL schema information to LLMs like Claude. This server allows an LLM to explore and understand large GraphQL schemas through a set of specialized tools, without needing to load the whole schema into the context5747MIT
- AlicenseAqualityAmaintenanceA generic MCP (Model Context Protocol) server that bridges any GraphQL API to Claude Code. It introspects your GraphQL schema and exposes each query and mutation as an individual tool, letting Claude interact with your API directly.2481MIT
- AlicenseNot gradedqualityDmaintenanceA Node.js server that enables LLMs to inspect GraphQL schemas and retrieve information about queries, mutations, and types via MCP.191MIT
- AlicenseNot gradedqualityBmaintenanceAn MCP server that exposes any OpenAPI REST API via two tools: search for discovering endpoints and execute for making API calls. It uses Code Mode to keep token footprint low and runs user-written JavaScript in a sandbox.203MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/jmpijll/unraid-code-mode-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server