YepCode MCP Server
Infrastructure · tested 2026-08-18 · re-test due 2026-11-16 · by the Hlido desk, not the vendor
In short: A clean bridge that turns any YepCode process into an MCP tool by adding a tag — genuinely low-friction for teams already on YepCode, and honestly a lock-in decision for everyone else.
Quick answer
YepCode MCP Server scores 73/100 (STEADY) on Hlido’s independent, hands-on test (reviewed 2026-08-18). STEADY (73) because it delivers a clear, well-documented capability — turning tagged processes into MCP tools with JSON-Schema-typed inputs, sandboxed execution, and both hosted and open-source self-hosted options — that
YepCode's MCP server answers a specific, real need: exposing existing backend processes to agents as callable tools without standing up new infrastructure. The mechanic is elegant — write a process in Python or Node against your APIs and databases, describe its inputs with JSON Schema, tag it `mcp-tool`, and it appears as a tool in Cursor, Claude Desktop or any MCP client. Execution happens inside YepCode's isolated sandboxes with secrets, dependencies, logs and auditability already handled, which is a meaningful safety and observability story compared with hand-rolled tool servers. It offers both a hosted, always-on endpoint (OAuth or API token) and an open-source self-hosted server runnable via NPX or Docker for air-gapped setups, plus built-in tools like `run_code` for ad-hoc execution and storage/API management helpers. The honest framing on the page — 'build tools, not servers' — is accurate. The unavoidable caveat is that the value is inseparable from the YepCode platform: 'your deployment is publishing a process in YepCode', so the MCP server is a thin, high-quality exposure layer over a runtime you must adopt. That is a fair trade for existing YepCode users and a real commitment for newcomers. The public surface shows no pricing detail, adoption numbers or independent reliability evidence for the MCP layer specifically, so production-scale behaviour is asserted rather than demonstrated. As a way to give agents real, sandboxed actions with minimal glue, it is well-built and clearly explained — just understand you are buying into a runtime, not only a protocol adapter.
Why STEADY
STEADY (73) because it delivers a clear, well-documented capability — turning tagged processes into MCP tools with JSON-Schema-typed inputs, sandboxed execution, and both hosted and open-source self-hosted options — that meaningfully lowers the effort of giving agents real actions. Not VITAL because the offering is tightly coupled to the YepCode platform (adopting it means adopting the runtime), and the captured surface carries no pricing specifics, adoption evidence or independent reliability signal for the MCP layer, leaving production durability unverified.
What it does well
- Turns any YepCode process into an MCP tool by adding a tag — no new server to build or deploy
- Types tool inputs with JSON Schema so model tool-calls are accurate and predictable
- Runs tools inside isolated sandboxes with secrets, dependencies, logs and auditability built in
- Offers both an always-on hosted endpoint (OAuth or API token) and an open-source self-hosted server via NPX/Docker
- Ships foundational built-in tools (run_code, storage and API management) alongside your own processes
What it fails at
- Value is inseparable from the YepCode platform — using it means adopting YepCode's process runtime
- No pricing detail for the MCP capability on the captured surface
- No adoption, scale or independent reliability evidence for the MCP layer specifically
- Air-gapped self-hosting still centres on YepCode-authored processes, limiting portability of the toolchain
- Latency and cold-start behaviour of sandboxed execution are not documented on the surface
Best for
- Teams already running processes on YepCode who want to expose them to agents with near-zero extra work
- Developers who want agent tools that execute in a sandbox with secrets and audit handled for them
- Setups needing both a hosted always-on endpoint and an air-gapped self-hosted option from one toolchain
- Anyone standardising many internal actions as JSON-Schema-typed MCP tools
Not recommended for
- Teams unwilling to adopt the YepCode runtime just to get an MCP exposure layer
- Buyers who need published pricing and reliability SLAs before committing to a tool-execution platform
- Fully portable toolchains that must not couple to a single execution vendor
- Simple single-tool needs where a lightweight standalone MCP server would suffice
Related agents
Agent relevance
API MCP SDK Behavioral-testable
Agentic-Commerce Readiness 66/100 · INTEGRABLE
Independent readiness for agent delegation & transaction. How it’s scored · check live
First-class MCP: point any MCP client (Cursor, Claude Desktop, or others) at the hosted endpoint (cloud.yepcode.io/mcp) or run the open-source server locally, and tagged YepCode processes appear as callable tools with JSON-Schema inputs. Built-in tools (run_code, storage, API management) are available immediately. This is squarely agent-facing infrastructure — its entire purpose is to give agents real, sandboxed actions.
Agent-friendly score: 8/10
Score over time
The longitudinal record — every point is the score as published on that date. Raw series.
Evidence
- Tagging a process (e.g. mcp-tool) exposes it as an MCP tool in Cursor, Claude and other clients — source (2026-08-18) verified
- Inputs described with JSON Schema; tools run in isolated sandboxes with secrets and audit — source (2026-08-18) verified
- Hosted always-on endpoint plus open-source self-hosted server via NPX/Docker — source (2026-08-18) verified
- Published pricing and independent reliability metrics for the MCP layer — source (2026-08-18)
scorecard.json · registry · methodology
Embed this trust badge
Markdown
[](https://hlido.eu/check/?agent=yepcode-mcp-server-js)HTML
<a href="https://hlido.eu/check/?agent=yepcode-mcp-server-js"><img src="https://hlido.eu/badge/yepcode-mcp-server-js.svg" alt="Hlido trust score"></a>