Tool blocks

Tool blocks are small internal tools for admin and support: UI in Slack and as a frontend page, backed by an API. Use them for troubleshooting and operations—local dev, staging, or prod:

  • Look up a request ID → lifecycle and logs
  • Inspect a failing job, feature flag state, etc.
  • Live data in the thread or a linked page—no dashboards or manual queries

Tool blocks run on a local bridge. That bridge’s data sources (DBs, logs, APIs) are used, and users choose where tool blocks run so the right environment is used.

The tool blocks skill creates tool blocks

Tool blocks are not a skill. A tool blocks skill teaches agents how to create them in a compatible format. We ship that skill; your agent (Cursor, Claude Code, etc.) uses it to generate:

  • API
  • Frontend page
  • Slack block representation

Created tool blocks live in .toolblocks; the bridge picks them up from there and runs them when asked in Slack. See Agent skills for installing the tool blocks skill.

API and frontend on a local bridge

The API and optional frontend run on whichever local bridge is chosen for tool blocks. The API uses data sources available to that bridge:

  • Local DBs, logs, staging, or prod
  • Frontend served from the same bridge
  • “View full report” links talk to that bridge’s API

Because users choose where tool blocks run, you get the right environment without exposing credentials or opening extra ports.

Slack block representation

Tool blocks can return a Block Kit payload; we post it into the thread as native Slack blocks (sections, buttons, links). That keeps the thread readable and interactive—“View full report”, “Run again”—without leaving Slack.