Config is the same across clients — only the file and path differ.
{
"mcpServers": {
"soma": {
"env": {
"RUST_LOG": "warn",
"SOMA_API_KEY": "YOUR_API_KEY",
"SOMA_API_URL": "https://api.example.com"
},
"args": [
"mcp"
],
"command": "/path/to/soma"
}
}
}Are you the author?
Add this badge to your README to show your security score and help users find safe servers.
API docs — rustdoc for every workspace crate plus the Redoc-rendered OpenAPI reference, deployed to GitHub
Run this in your terminal to verify the server starts. Then let us know if it worked — your result helps other developers.
npx -y 'soma-rmcp' 2>&1 | head -1 && echo "✓ Server started successfully"
After testing, let us know if it worked:
Five weighted categories — click any category to see the underlying evidence.
No known CVEs.
Checked soma-rmcp against OSV.dev.
Be the first to review
Have you used this server?
Share your experience — it helps other developers decide.
Sign in to write a review.
Others in other
Compress tool outputs, logs, files, and RAG chunks before they reach the LLM. 60-95% fewer tokens, same answers. Library, proxy, MCP server.
Pi Coding Agent extension (CLI-first) — routes bash/read/grep/find/ls through lean-ctx CLI for strong token savings. Optional MCP bridge can register advanced tools.
97% token reduction for AI coding sessions — zero deps, 21 languages, MCP server
One local source for the MCP servers, tools, and memory your AI coding agents share, synced into each tool's native config with a review gate and a receipt for every change. No daemon, no lock-in.
MCP Security Weekly
Get CVE alerts and security updates for ai.dinglebear/soma and similar servers.
Start a conversation
Ask a question, share a tip, or report an issue.
Sign in to join the discussion.
API docs — rustdoc for every
workspace crate plus the Redoc-rendered OpenAPI reference, deployed to GitHub
Pages from
main.
Soma is a batteries-included RMCP server runtime and shipping binary
for bringing new agent capabilities online with as little custom Rust as
possible. It locks in the production patterns that every server in the family
keeps rediscovering: one compact MCP tool, stdio and Streamable HTTP transports,
CLI parity, direct REST routes, auth/OAuth, observability, plugin packaging,
web fallback, Docker/runtime samples, generated contracts, and release
automation.
The repository can still scaffold a renamed project, but Soma is now a shipped
runtime first. The default product path is to run soma in an explicit mode,
drop provider files into providers/ (or point SOMA_PROVIDER_DIR
elsewhere), and let the provider registry project those capabilities across MCP,
CLI, REST, OpenAPI, Palette summaries, generated docs, and plugin metadata.
Provider manifests also carry MCP-native prompt, resource, task, and elicitation
metadata for the registry contract. Scaffolding is the path for creating a new
distributable repo with the same locked-in runtime.
30-second path: install the soma binary -> soma status ->
npx -y soma-rmcp mcp from an MCP client -> call the soma MCP tool through
tools/call with {"action":"status"}.
Status: production RMCP runtime. Write-capable provider actions are allowed only when the provider declares them and destructive actions are gated.
Not for: an unauthenticated public gateway, a replacement for upstream service authorization, arbitrary untrusted code execution, or a multi-tenant security boundary by itself.
Soma is the runtime product first and the template/export source second.
Generated projects replace these names during scaffold post-processing, but the
shipped soma command is the source of truth for product behavior.
| Surface | Soma value | Generated-project pattern |
|---|---|---|
| Repository | dinglebear-ai/soma | <service>-rmcp or a documented product exception |
| Rust crate/package | soma | service-specific crate names |
| Canonical binary | soma | usually r<service> or the product name |
| npm package | soma-rmcp | <service>-rmcp |
| MCP tool | soma | usually <service> |
| Env prefix | SOMA_* | generated service prefix |
| Path | Use when | You author | Runtime supplies |
|---|---|---|---|
| Drop-in provider | You can describe a capability as a manifest, script, WASM module, OpenAPI operation, or upstream MCP call. | Files under providers/ with tools, prompts, resources, env needs, capability grants, and surface overlays. | MCP tool dispatch, dynamic CLI commands, direct REST routes, schema validation, auth policy, refresh, OpenAPI/Palette summaries, generated docs, and plugin metadata. |
| Static Rust provider | The capability needs native Rust, tight integration, or reusable crates. | A Rust provider/action registered with the provider registry. | T |