MCP Server Blocks

What Are MCP Blocks?

An MCP block wraps a single tool from a connected MCP server. When the flow reaches the block, Steroid resolves input variables, collects the piece's secret/config properties and calls the bridge's direct execution path. The returned bridge envelope is available under the step name. Blocks are the explicit counterpart to LLM nodes — they execute side effects (reading data, writing records, sending messages) while the LLM nodes handle all reasoning and text transformation.

Available Servers

The current factory generates 229 pieces for 3,188 tools. Twelve of the 241 registry entries have no tool definitions and are skipped; not every listed server has a block. The screenshot below shows the full server catalogue as it appears in the step picker.

Code & Version Control

• github-official — 40 tools; issue_write requires method, owner and repo.
• Use the current catalog and generated piece for other developer integrations; do not infer tool names from display labels.

Communication

• slack — 8 tools; slack_post_message requires channel_id and text.
• Slack also declares slack.bot_token and required server config slack.team_id.

Databases

• postgres — one query tool, described as read-only; supply sql. Its connection URL is the secret postgres.url.
• Other database tools have their own catalog schemas; there is no universal transaction/list-tables interface.

Project Management

• notion — 19 tools; API-post-page requires parent and properties.
• Use the exact declared secret notion.internal_integration_token and share the required pages with the integration.

Cloud & Infrastructure

• Find cloud/infrastructure integrations in the catalog; server-specific tool names and permissions vary.
• Catalog presence is not a guarantee of tested runtime availability or unrestricted access to every vendor API.

Configuring a Block

Click a block to open its configuration panel. The panel shows all input fields defined by the MCP tool's schema. Required fields are marked with an asterisk.

Each field accepts one of three value types, and you can mix them freely within the same block:

Static values — plain text or JSON typed directly into the field. Use for constants like a repository name or a fixed Slack channel.

Dynamic references — the {{step_1}} resolves the complete output of a previous step at runtime. Use for passing data between steps.

Mixed — a string that combines static text and dynamic references, e.g. "Summary for PR #{{trigger.body.pr_number}}".

Passing Data Between Blocks

Every step's complete output is stored in the flow run context under its node name. You can reference any field from any previous step at any point in the flow.

issue_write:
  arg_method = create
  arg_owner  = {{trigger.body.owner}}
  arg_repo   = {{trigger.body.repo}}
  arg_title  = {{trigger.body.title}}
  arg_body   = {{trigger.body.body}}

Use actual internal step names from the data picker.
Inspect bridge/full_result wrappers before binding a narrower result field.

{
  "first_step": "{{step_1}}",
  "second_step": "{{step_2}}"
}

{{step_1}}                         # native value for a single-token reference
Result: {{step_1}}                 # mixed text serializes object/array values
{{connections.<externalId>.secret_text}} # existing AP Connection reference

Generated input properties use arg_ bindings.
Browser-authored nodes do not automatically read the local Vault.
Directly entered secret properties can be persisted with the flow;
prefer approved connection references or the agent-build credential path.