solflow-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PATH | No | Only needed if the client can't find `solc`. Set to your PATH including solc-select's bin directory. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Static call-flow navigation for Solidity repositories (Slither-based). Typical audit loop: list_entry_points -> get_flow on an interesting entry point (include_source=true to read code inline) -> get_function_source / get_type_definition for details -> find_paths_to to see which entry points reach a sensitive internal function -> list_unresolved + set_interface_bindings to follow calls through interfaces. The first call for a repo compiles it (can take a while); later calls are cached. After editing Solidity sources, call analyze_repo(force=true). SolFlow emits no vulnerability findings; it only shows code structure. Unresolved nodes are places where static analysis cannot see the callee - treat them as gaps.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| analyze_repoA | Compile a Solidity repo (Foundry/Hardhat/etc. via crytic-compile + Slither) and build one call-flow per external entry point. Returns a summary. |
| list_entry_pointsA | List every externally callable entry point, grouped by contract and split into mutating vs read-only, with modifiers, call-tree depth, node count and number of unresolved calls. Use the printed names with get_flow. |
| get_flowA | Show the full execution call tree for one entry point as an indented text tree: modifiers, internal/library/external calls (with the parent line that makes each call), inherited/virtual dispatch resolved through C3, builtins used (require, keccak256, ...), dependency calls not followed, and UNRESOLVED calls with the reason. |
| get_function_sourceA | Get the source (line-numbered) and metadata of any function or modifier, including internal/private ones and those in libraries, plus its outgoing calls. |
| find_paths_toA | Reverse reachability: which entry points can reach a given function (or dependency call), and through which call chain. E.g. "who can reach _mint?", "which external functions end up in Pool.swap?". |
| list_unresolvedA | List every call site static analysis cannot follow (unbound interface calls, low-level .call/.delegatecall, Yul dynamic dispatch, abstract with no impl), which entry points hit each one, and interfaces that could be bound to a concrete implementation via set_interface_bindings (with candidates). |
| set_interface_bindingsA | Bind interfaces to concrete contracts so flows follow calls like IOracle(addr).price() into the chosen implementation's body. Rebuilds flows instantly (no recompile). Bound edges are marked as asserted, not proven. |
| get_type_definitionA | Get the definition of a struct, enum, or user-defined value type, plus the definitions of user types its members reference (one level per call). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool has a clearly distinct role in the Solidity call-flow analysis workflow: setup, entry-point listing, single-flow inspection, function source retrieval, reverse reachability, unresolved-call diagnostics, and interface binding. Overlap between get_flow and get_function_source is minimal because one targets entry-point call trees while the other retrieves arbitrary function source and metadata.
All tool names use consistent snake_case and begin with an action verb. The convention is predictable across setup, retrieval, listing, search, and configuration tools.
Eight tools is a well-scoped set for a Solidity static-analysis server. Each tool covers a distinct stage of the analysis workflow, and none appears to be filler.
The surface covers compilation, entry-point discovery, flow inspection, source retrieval, reverse paths, unresolved calls, and interface binding, which supports the core analysis workflow well. Minor gaps remain, such as no direct enumeration of internal functions or contracts beyond external entry points, which agents may need to infer through flows or known names.