# Tools and workflow Chain.Love MCP Gateway exposes a compact tool surface for Web3 discovery, registry search, session credential binding, and downstream MCP execution. ## Top-level tools These are the primary tools exposed by the gateway itself: | Tool | What it does | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `discover_networks` | Lists the canonical chain keys available in the current Chain.Love registry snapshot. The current snapshot contains `55` supported chains, and the dataset keeps growing over time. | | `discover_categories` | Lists the currently available categories for a selected chain, such as `apis`, `explorers`, `ramps`, `oracles`, `bridges`, `wallets`, `security`, and `mcpservers`. | | `search` | Searches Chain.Love registry services by query, chain, category, tags, filters, limit, and offset so an agent can find the exact provider or hosted tool it needs. | | `bind_credentials_bag` | Binds a session-scoped credentials bag for downstream MCPs. It can accept explicit credentials or read headers such as `x-chainlove-cred-github`. | | `execute` | Unified runtime entrypoint for service actions, downstream MCP connection management, saved connections, and proxied MCP tool calls. | ## Why these tools matter * `discover_networks` removes guesswork around chain names and gives the agent canonical keys such as `ethereum`, `base`, `filecoin`, or `solana`. * `discover_categories` and `search` let the agent work against registry-backed Web3 data instead of hardcoding providers or scraping docs. * `bind_credentials_bag` gives the session temporary downstream credentials without forcing every workflow to manage each provider separately. * `execute` keeps the runtime surface unified. Instead of exposing a different MCP wrapper per integration, Chain.Love uses one tool for connection, inspection, and execution. ## How `search` and `execute` work together In practice, discovery and execution are connected: * `search` finds registry entries and often returns an `execute_hint`. * For MCP-capable services, that hint commonly points to `execute` with `operation: "connect_mcp"`. * After the MCP is connected, the agent can keep using `execute` to inspect tools and call them through the same gateway session. This means the agent does not need to guess the next step after discovery. The registry can guide it toward the correct runtime path. ## Execute operations `execute` currently supports these operations: | Operation | What it does | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `get_details` | Default service-scoped action. Returns the raw registry snapshot plus metadata such as `service_id`, `chain`, `category`, `slug`, and `providerMeta`. | | `open_actions` | Resolves action buttons and links attached to a registry entry, including markdown-style action links. | | `connect_mcp` | Connects to a downstream MCP service, validates connectivity, and returns runtime metadata such as `connection_id`, validation status, auth source, and next actions. | | `list_connections` | Lists owner-scoped saved connections plus session-scoped connections. For public MCPs, it can also expose a virtual public connection. | | `create_connection` | Creates a saved owner-scoped downstream connection. In the current v1 flow, this supports `static_secret` bearer-token style credentials. | | `get_connection` | Returns a single saved connection by `connection_id`. | | `update_connection_label` | Updates or clears the label for a saved connection. | | `delete_connection` | Deletes a saved connection by `connection_id`. | | `list_mcps` | Lists downstream MCP servers discovered from the registry. This is useful when the agent wants an MCP catalog first instead of starting from a single search result. | | `bind_mcp_tokens` | Compatibility path for binding downstream bearer tokens directly to the current session. | | `list_mcp_tools` | Lists tools exposed by a connected downstream MCP. The preferred path uses `connection_id`. | | `call_mcp_tool` | Calls a specific downstream MCP tool through the active Chain.Love session. The preferred path uses `connection_id`, plus `tool_name` and optional tool arguments. | ## Recommended workflows The flows below separate standard registry discovery from downstream MCP execution. ### Web3 discovery workflow {% stepper %} {% step %} #### Discover networks Call `discover_networks` first to avoid guessing chain keys. Today that returns `55` supported networks, including `ethereum`, `base`, `arbitrum`, `optimism`, `filecoin`, `solana`, `bitcoin`, and more. {% endstep %} {% step %} #### Discover categories Call `discover_categories` with a chain key such as `ethereum`, `base`, or `filecoin`. The response shows which service groups exist for that chain right now. {% endstep %} {% step %} #### Search services Call `search` with explicit chain/category filters when possible. For example, search `mcpservers` for GitHub tooling or search `apis` on `base` to find RPC providers. {% endstep %} {% step %} #### Inspect a service If the result is a standard registry service, call `execute` with `get_details` or `open_actions` to inspect the service before taking action. {% endstep %} {% endstepper %} *** ### Downstream MCP workflow The preferred downstream runtime path in `chainlove-mcp` is: ``` execute(list_mcps) -> execute(create_connection) or bind_credentials_bag -> execute(connect_mcp) -> execute(list_mcp_tools) -> execute(call_mcp_tool) ``` Use that flow differently depending on the MCP type: {% stepper %} {% step %} #### Public hosted MCP If the downstream MCP is public, the agent can usually go straight from discovery to `execute(connect_mcp)`, then inspect tools with `execute(list_mcp_tools)`, and finally run the chosen action with `execute(call_mcp_tool)`. {% endstep %} {% step %} #### Private hosted MCP If the downstream MCP requires credentials, first provide them through `bind_credentials_bag` or through `x-chainlove-cred-*` headers, then call `execute(connect_mcp)`. Once the connection is validated, continue with `list_mcp_tools` and `call_mcp_tool`. {% endstep %} {% step %} #### Saved owner-scoped connection If the user wants a reusable saved connection, use `execute(create_connection)` first, then `execute(connect_mcp)` against that saved connection, then continue with tool inspection and tool calls. {% endstep %} {% endstepper %} *** ## Architecture example One practical Chain.Love pattern is a hybrid flow where the agent combines hosted MCP servers with a self-hosted local MCP in the same task. Example scenario: * Use a hosted infra MCP through Chain.Love to find a public Filecoin RPC and gather network inputs. * Let Chain.Love identify that the next step requires a self-hosted local MCP and return local launch instructions to the agent. * Start the local stdio MCP in the user environment to deploy the contract and produce the contract address plus ABI. * Reuse the same Chain.Love gateway session to proxy into a hosted GitHub MCP and create the repo or UI that consumes the deployed contract. ![Hybrid local stdio value flow](https://3678006672-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKkQxEBAeEiKzN6aHQGGd%2Fuploads%2Fgit-blob-b562cea06c1faa1ada6c33d0c8f9bed0d6abfdec%2Fchainlove-mcp-hybrid-local-stdio-value-flow.svg?alt=media) ## Example: connect GitHub MCP through Chain.Love ```json { "tool": "execute", "arguments": { "service_id": "mcpservers:github-mcp-server", "operation": "connect_mcp" } } ``` After the connection is validated, the next action is usually: ```json { "tool": "execute", "arguments": { "operation": "list_mcp_tools", "arguments": { "connection_id": "agent::mcpservers:github-mcp-server" } } } ``` Then a specific downstream tool can be called with: ```json { "tool": "execute", "arguments": { "operation": "call_mcp_tool", "arguments": { "connection_id": "agent::mcpservers:github-mcp-server", "tool_name": "", "arguments": {} } } } ``` {% hint style="info" %} Need a higher-level overview first? Open . {% endhint %}