Steroid Kit logo

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

MetricWithout Steroid MCPWith Steroid MCP
Marketplace schemasIndividual server tools may all be registeredSearch/run pair returns selected candidate argument descriptors on demand
Tool eligibilityAgent can propose any registered toolGuarded run checks discovered candidates and workflow capability
Token usageDepends on registered schemas, caller and cachingDepends on nine Connected operation schemas, discovery, arguments and results; no fixed token guarantee
Catalog availabilityClient-specific configurationRegistry ingestion/indexing must succeed; a listed entry is not proof of runtime availability
CredentialsOften embedded in local server configurationSeparate 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_workflow

Marketplace 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.

Continue Reading

→ Local vs Connected Operations→ Credential Injection→ Hallucination Prevention→ Server Catalog

On this page