
Steroid_Kit
Steroid MCP›Overview
Steroid MCP — Overview
Steroid MCP is a Model Context Protocol server that gives AI agents structured, hallucination-resistant access to a catalog of 200+ integrations. Marketplace discovery/execution uses two tools; the complete client registers three recall operations in Local mode and nine operations in Connected mode.
Impact
| Metric | Without Steroid MCP | With Steroid MCP |
|---|---|---|
| Marketplace schemas | Individual server tools may all be registered | Search/run pair returns selected candidate argument descriptors on demand |
| Tool eligibility | Agent can propose any registered tool | Guarded run checks discovered candidates and workflow capability |
| Token usage | Depends on registered schemas, caller and caching | Depends on nine Connected operation schemas, discovery, arguments and results; no fixed token guarantee |
| Catalog availability | Client-specific configuration | Registry ingestion/indexing must succeed; a listed entry is not proof of runtime availability |
| Credentials | Often embedded in local server configuration | Separate elicitation and encrypted local storage; required values are sent to execution services |
NOTE
Discovery reduces up-front marketplace schema loading. It does not guarantee correct arguments, truthful summaries, zero model errors or a measured token-saving percentage.
How It Works
Instead of registering every available tool definition at server startup, Steroid MCP exposes a minimal marketplace search/run surface alongside recall and workflow operations. The agent calls search_tools with a natural-language query, reads the returned tool_candidates and their argument descriptors, then calls run_tool with the workflow ID, opaque capability, exact server/tool and inputs.
Mode-dependent MCP operations
Local (3): recall_memory, recall_turn, recall_diff
Connected (9): the Local tools plus
search_tools, run_tool, search_workflows, run_workflow,
create_workflow, repair_workflowMarketplace Search and Run
search_tools
Accepts a natural-language query and returns the best-matching tool (or tools) from the catalog, along with a workflow-scoped opaque capability the agent must present when calling run_tool. The public signature is search_tools(query); there is no limit argument.
search_tools — input
{
"query": "send a message to a Slack channel"
}search_tools — schematic response (metadata abbreviated)
{
"workflow_run_id": "<returned workflow ID>",
"step": 1,
"capability_token": "<returned opaque handle>",
"tool_candidates": [
{
"server_name": "slack",
"server_description": "Slack integration",
"server_metadata": {},
"tool_details": {
"name": "slack_post_message",
"description": "Post a new message to a Slack channel",
"arguments": [
{ "name": "channel_id", "type": "string", "desc": "The ID of the channel to post to" },
{ "name": "text", "type": "string", "desc": "The message text to post" }
]
}
}
],
"message": "<server message>",
"instructions": "<server instructions>"
}Default ranking returns three candidates using 68% normalized dense and 32% normalized lexical scores, followed by MMR diversity reranking. This is server configuration, not a caller limit or a local-Vault credential tie-breaker. Capabilities default to five-minute expiry and are invalidated by process restart.
run_tool
Executes a tool identified by its capability token. Steroid resolves the full schema, checks the Vault for credentials, triggers an elicitation flow if credentials are missing, and returns the tool output in a result envelope. arguments defaults to an empty object; additional_user_input is an optional list for missing-input elicitation. There are no public vault_profile, timeout_ms or dry_run arguments.
run_tool — input
{
"workflow_run_id": "<returned workflow ID>",
"capability_token": "<returned opaque handle>",
"server_name": "slack",
"tool_name": "slack_post_message",
"arguments": {
"channel_id": "C0123456789",
"text": "Deployment complete."
}
}run_tool — schematic response
{
"workflow_run_id": "<returned workflow ID>",
"step": 1,
"status": "<returned status>",
"artifact_ref": "<returned artifact reference>",
"artifact_token": "<returned artifact signature>",
"full_result": "{\"content\":[]}"
}Decode full_result as JSON; its contents are tool-specific, not a universal ok/output object. Artifact tokens use HMAC-SHA256 and are different from opaque capabilities. The inspected public MCP surface does not establish a universal IDE-download/object-storage contract.
Cloud Runtime and Retention Boundaries
Marketplace execution uses the reverse proxy and gateway rather than installing each server on your developer machine. Isolation depends on the catalog/runtime: clients can be reused, remote servers need not spawn a container, and egress restrictions depend on gateway configuration.
- The orchestrator retains workflow state/final results in process memory with a default one-hour cleanup age.
- Execution secrets are Redis hashes with a default 1,800-second TTL, refreshed on insertion. Redis AOF persistence is enabled in Compose; expiry is not immediate erasure of previous AOF records.
- Agent-built flows additionally persist encrypted AP App Connections. Manual blocks use their credential properties/connection references; the browser cannot automatically read the local Vault.
- Generated AP blocks use bridge-secret-protected direct execution, not the public discovery/capability path. This is not a universal per-block artifact-verification chain.
- No customer-facing per-tool/per-secret audit UI or unconditional no-log guarantee is established by the inspected implementation.
Quick Start
Follow the Setup in Getting Started.