Skip to main content
Glama
Sign In
solflow-mcp

solflow-mcp

by fuzious
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

analyze_repo

Idempotent

Compile a Solidity repo and build a call-flow per external entry point, mapping reachable calls with configurable exclusions and interface bindings.

Instructions

Compile a Solidity repo (Foundry/Hardhat/etc. via crytic-compile + Slither) and build one call-flow per external entry point. Returns a summary.

Other tools call this implicitly with defaults, so only call it to (a) change
scope, or (b) recompile after source edits (force=true).

Each call sets the WHOLE scope from defaults + solflow.toml + these arguments;
options and unsaved set_interface_bindings from earlier calls are dropped.

Args:
    repo_path: Absolute path to the project root (where foundry.toml etc. lives).
    force: Recompile even if cached (needed after editing .sol files).
    exclude_paths: Gitignore-style globs; contracts in matching files get no flows.
    exclude_contracts: Globs on contract names to exclude (e.g. "*Harness*").
    inline_libraries: Names of lib/<NAME>/ dependencies to recurse into instead
        of stopping at them (e.g. "openzeppelin-contracts").
    stub_paths: Globs for in-tree call targets NOT to recurse into (e.g. dense
        math libs: "src/libraries/FullMath.sol").
    bindings: Interface -> concrete contract, e.g. {"IOracle": "ChainlinkOracle"},
        so calls through the interface are followed into that implementation.
    use_default_excludes: Default excludes are tests (*.t.sol, test/, tests/),
        mocks/, *Mock* contracts and dependency contracts (lib/, node_modules/,
        including such folders outside the repo root). Excluded contracts get no
        entry points of their own; project contracts that inherit dependency
        code still get those entry points. Set false to include them.
    config_path: Optional solflow.toml path (default: <repo>/solflow.toml if present).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "repo_path": "<repo_path>"
    },
    "name": "analyze_repo"
  }
}

Input Schema

NameRequiredDescriptionDefault
forceNo
bindingsNo
repo_pathYes
stub_pathsNo
config_pathNo
exclude_pathsNo
inline_librariesNo
exclude_contractsNo
use_default_excludesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by disclosing that every call resets the WHOLE scope from defaults + solflow.toml + arguments, and that prior options and unsaved set_interface_bindings are dropped — a non-obvious state side effect an agent must know. It also explains caching and force semantics, consistent with readOnlyHint=false and idempotentHint=true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical state-reset warning is front-loaded before the alternative-use rule, and the Args block is dense and skimmable. Slightly verbose in tooling parentheticals (crytic-compile + Slither) that don't affect invocation, but little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, non-read-only tool with no output schema, the description covers compilation stack, output shape (summary of call-flows), scope composition, exclusions, and recompile triggering. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage across 9 parameters, the description carries the full burden and does: each argument gets a purpose plus examples (glob style for exclude_paths, "*Harness*" for exclude_contracts, interface-to-implementation map for bindings) and the default-exclusion behavior is spelled out.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: compile a Solidity repo and build one call-flow per external entry point, returning a summary. The scope (whole-repo analysis, not filtered queries) distinguishes it from siblings like list_entry_points and get_flow, which consume its output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says other tools call this implicitly with defaults, so an agent should only invoke it to (a) change scope or (b) recompile after source edits with force=true. That is a clear when-to-use and when-not-to-use rule with the alternative path named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools