Integrates with Google Cloud KMS for secure transaction signing during deployments and contract interactions.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@foundry-zksync-mcp compile the contract in src/Counter.sol"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that exposes foundry-zksync CLI tools to AI assistants like Claude.
Tool | Description |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Read and inspect project configuration |
| Match errors/logs against a knowledge base of zkSync gotchas |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Look up foundry-zksync documentation by topic |
| Start or check a local anvil-zksync dev node |
Related MCP server: Prover MCP
Node.js >= 18
foundry-zksync installed (foundryup-zksync)
No install needed — run directly with npx:
claude mcp add foundry-zksync -- npx -y foundry-zksync-mcpOr add to claude_desktop_config.json / ~/.claude.json:
{
"mcpServers": {
"foundry-zksync": {
"command": "npx",
"args": ["-y", "foundry-zksync-mcp"]
}
}
}git clone https://github.com/Jrigada/foundry-zksync-mcp.git
cd foundry-zksync-mcp
npm install
npm run buildThen register with Claude Code:
claude mcp add foundry-zksync node /absolute/path/to/foundry-zksync-mcp/dist/index.jsAll signing tools (deploy, cast_send, run_script) support multiple wallet methods. Choose based on your security needs:
For local dev with well-known test keys, use privateKey directly:
privateKey: "0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80"These are the default anvil-zksync test accounts — they hold no real value.
Warning: Never use
privateKeywith keys that hold real funds. MCP tool parameters are visible to the AI assistant and may be logged.
Keys are encrypted on disk — only the account name travels through MCP.
# Import a private key into a named keystore (interactive, key never shown)
cast wallet import deployer --interactive
# List your keystores
ls ~/.foundry/keystores/Then use account: "deployer" in any signing tool. Forge will prompt for the password at runtime, or you can point to a password file with passwordFile.
If you have an existing encrypted keystore JSON file (e.g. from Geth, MetaMask export):
keystore: "/path/to/keystore.json"
passwordFile: "/path/to/password.txt"ledger: true # Ledger
trezor: true # Trezoraws: true # AWS KMS (set AWS_KMS_KEY_ID env var)
gcp: true # Google Cloud KMS (set GCP_PROJECT_ID, GCP_LOCATION, etc.)Method | Key Exposure | Best For |
Hardware wallet | None (key never leaves device) | High-value production |
Cloud KMS | None (key in HSM) | Automated production |
Named keystore ( | None through MCP (encrypted on disk) | General production use |
Keystore file | None through MCP (encrypted on disk) | Existing workflows |
| Visible to AI assistant | Local dev with test keys only |
src/
index.ts MCP server entry point, registers all 21 tools
knowledge.ts Knowledge base (45+ entries) and system addresses
tools/
shared.ts Profile field and env builder shared across forge tools
init.ts forge init with zkSync config
compile.ts forge build --zksync
test.ts forge test --zksync
run_script.ts forge script --zksync
deploy.ts forge create --zksync (structured output)
verify.ts forge verify-contract --zksync
install.ts forge install
clean.ts forge clean
gas_report.ts forge test --gas-report
snapshot.ts forge snapshot
read_foundry_toml.ts Read project config
explain.ts Error/log explanation with knowledge base
get_zksync_docs.ts Documentation lookup with embedded content
cast_abi_encode.ts cast abi-encode
cast_abi_decode.ts cast abi-decode
cast_calldata_decode.ts cast calldata-decode
cast_call.ts cast call
cast_send.ts cast send
cast_balance.ts cast balance
cast_nonce.ts cast nonce
anvil_zksync.ts anvil-zksync node management
__tests__/ 133 tests (vitest)Start or check a local anvil-zksync development node. Supports forking from mainnet/testnet. Default port: 8011.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | Port to listen on (default: 8011) | |
| forkUrl | No | RPC URL to fork from, e.g. https://mainnet.era.zksync.io | |
| forkBlockNumber | No | Block number to fork from (requires forkUrl) | |
| accounts | No | Number of funded accounts to generate (default: 10) | |
| balance | No | ETH balance for each generated account in ether (default: 10000) | |
| action | Yes | 'start' launches anvil-zksync in the background and returns when ready. 'check' tests if anvil-zksync is reachable at the given port. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It mentions starting/checking and forking, but does not disclose background process behavior or potential port conflicts. The action parameter's schema description adds some behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with essential information, no fluff. Efficiently communicates core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description is brief but covers key points. Lacks details on background process lifecycle, error conditions, or prerequisites. With 6 parameters and no output schema, more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal meaning beyond schema (e.g., forking support already implied by forkUrl parameter).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts or checks a local anvil-zksync node, with forking support and default port. It distinguishes itself from siblings like deploy or test by focusing on local node management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for local node setup, and the action parameter clarifies when to start vs check. However, it lacks explicit guidance on when not to use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode ABI-encoded hex data back into human-readable values (cast abi-decode)
| Name | Required | Description | Default |
|---|---|---|---|
| signature | Yes | Solidity function signature whose output types to decode against, e.g. "balanceOf(address)(uint256)" or "transfer(address,uint256)" | |
| data | Yes | Hex-encoded ABI data to decode (0x-prefixed) | |
| input | No | If true, decode as input data (function args). If false/omitted, decode as output data (return values). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states the core function but does not disclose behavioral traits such as error handling, permissions, or side effects. It is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete sentence that front-loads the purpose. It contains no unnecessary words and efficiently conveys the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with full schema coverage, the description is adequate but lacks details about return values (no output schema) and the effect of the 'input' parameter, which is only explained in the schema. It could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional parameter details beyond what is in the schema. It is adequate but does not enhance understanding of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool decodes ABI-encoded hex data into human-readable values. It includes the command name and is specific enough to distinguish from siblings like cast_abi_encode or cast_calldata_decode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to decode ABI hex data) but does not explicitly state when not to use it or list alternatives. It is straightforward, though lacking explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ABI-encode values for a given Solidity function/constructor signature (cast abi-encode)
| Name | Required | Description | Default |
|---|---|---|---|
| signature | Yes | Solidity function or constructor signature, e.g. "constructor(address,uint256)" or "transfer(address,uint256)" | |
| args | Yes | Values to encode, matching the signature types in order, e.g. ["0x1234...", "1000000"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the core function without detailing traits like error handling (e.g., what happens if arguments don't match the signature), encoding format (e.g., hex output), or whether the operation has side effects. The minimal description adds little beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence – concise but overly minimal. It front-loads the key action, but lacks structure (e.g., no breakdown of steps, no examples). It is not wasteful, but it could be more informative without sacrificing conciseness by adding a brief usage hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of ABI encoding and the lack of an output schema, the description is incomplete. It does not explain the return format (e.g., hex-encoded bytes), potential errors from mismatched types, or how to handle edge cases. Parameter definitions are covered in the schema, but the description should provide more operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters ('signature' and 'args') are described in the schema with clear definitions. The description adds no additional meaning beyond what the schema provides. According to guidelines, baseline is 3 when coverage is high, and this score reflects that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'ABI-encode values for a given Solidity function/constructor signature'. It uses a specific verb ('ABI-encode') and resource ('values for a given Solidity function/constructor signature'), and the name 'cast_abi_encode' distinguishes it from siblings like 'cast_abi_decode' and 'cast_calldata_decode'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It lacks context such as prerequisites, typical use cases (e.g., preparing calldata for a contract call), or when to use sibling tools like 'cast_abi_decode'. A brief example of a signature is given but it does not help in decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the ETH balance of an address (cast balance)
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Address to query the balance of | |
| rpcUrl | Yes | RPC URL of the network | |
| blockTag | No | Block to query at, e.g. "latest", "pending", or a block number | |
| ether | No | If true, format the output in ether instead of wei |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Query the ETH balance'. It does not disclose any behavioral traits such as error handling, permission requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with no output schema, the description is adequate but lacks usage guidelines and behavioral context that would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all 4 parameters. The tool description adds no new semantic information beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Query' and the resource 'ETH balance'. It distinguishes from siblings like cast_nonce and cast_call by its specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like cast_nonce or cast_call. The description does not mention exclusions or ideal contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only call to a deployed contract — no gas spent, no state change (cast call)
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Address of the contract to call | |
| signature | Yes | Function signature with return type, e.g. "balanceOf(address)(uint256)" or "name()(string)" | |
| args | No | Function arguments in order, e.g. ['0x1234...'] | |
| rpcUrl | Yes | RPC URL of the zkSync network to call against | |
| blockTag | No | Block to query at, e.g. "latest", "pending", or a block number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behavioral traits: read-only, no gas spent, no state change. This tells the agent it is a safe, non-modifying operation. However, it does not cover error handling, permission requirements, or result format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the key concept 'Read-only call'. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Brief description is adequate for a simple call, but lacks details on return value (no output schema) and edge cases. Considering 5 parameters and no annotations, more context about what the tool returns would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline applies. The description adds no additional meaning beyond the schema's parameter descriptions. It does not explain formatting or constraints beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read-only call to a deployed contract — no gas spent, no state change', which specifies the action (call), the resource (deployed contract), and its effect (no state change). It distinguishes itself from siblings like cast_send, which is a write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying contracts without modifying state, but does not explicitly state when to use it versus alternatives (e.g., cast_send for write, cast_balance for balance checks). No guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode raw transaction calldata (with 4-byte selector) into function arguments (cast calldata-decode)
| Name | Required | Description | Default |
|---|---|---|---|
| signature | Yes | Function signature, e.g. "transfer(address,uint256)" | |
| calldata | Yes | Raw transaction calldata (0x-prefixed, includes the 4-byte selector) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description does not disclose error handling, return format, or any side effects. For a decode operation, it is likely read-only, but this is not stated, and the behavior on invalid calldata is omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, 10 words, with no filler. The parenthetical 'with 4-byte selector' is included efficiently. Every part is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple two-parameter tool, but it lacks specification of the return value format (e.g., decoded arguments as tuple or array). Since there is no output schema, this is a gap. Error cases are not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by providing an example for signature (e.g., 'transfer(address,uint256)') and clarifying the calldata format (0x-prefixed, includes 4-byte selector).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'Decode', resource 'raw transaction calldata', and output 'function arguments', with parenthetical clarifying the inclusion of the 4-byte selector. It clearly distinguishes from sibling tools like cast_abi_decode by mentioning the raw transaction calldata context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like cast_abi_decode. Usage is implied from the tool name and description, but no exclusions or when-not-to-use advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the transaction nonce of an address (cast nonce). Note: on zkSync this returns the TX nonce only, not the deploy nonce.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Address to query the nonce of | |
| rpcUrl | Yes | RPC URL of the network | |
| blockTag | No | Block to query at, e.g. "latest", "pending", or a block number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It correctly identifies the tool as a query (read-only) operation and adds a specific behavioral note about zkSync behavior. No side effects or rate limits are mentioned, but the tool is simple and the description is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no filler. The first sentence states the core function, and the second adds a relevant caveat. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with three well-described parameters and no output schema, the description is fairly complete. It explains the primary behavior and a key exception (zkSync). It could mention the return type or default block behavior, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are described in the input schema with clear descriptions. The description adds no additional parameter-level details beyond the schema, but the note about zkSync provides contextual value. With full schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the transaction nonce of an address, which is distinct from all sibling tools. The verb 'Query' and resource 'transaction nonce' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives or any prerequisites. While the purpose is clear, the agent is not told when not to use it or if there are better options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a state-changing transaction to a deployed contract (cast send)
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Address of the contract to send the transaction to | |
| signature | Yes | Function signature, e.g. "transfer(address,uint256)" | |
| args | No | Function arguments in order | |
| rpcUrl | Yes | RPC URL of the zkSync network | |
| privateKey | No | Raw private key for signing. Only use for local development with well-known test keys (e.g. anvil-zksync accounts). For production, use 'account' (named keystore) or hardware wallets instead. | |
| account | No | Named keystore account from ~/.foundry/keystores (recommended for production). Create one with: cast wallet import <name> --interactive | |
| keystore | No | Path to an encrypted keystore JSON file | |
| passwordFile | No | Path to a file containing the keystore password | |
| keystorePassword | No | Keystore password (prefer passwordFile to keep it out of process args) | |
| unlocked | No | Use eth_sendTransaction with --from address (no local signing). For nodes that manage keys natively. | |
| from | No | Sender address, used with --unlocked or hardware wallets. Maps to --from for cast/deploy, --sender for forge script. | |
| ledger | No | Sign with a Ledger hardware wallet | |
| trezor | No | Sign with a Trezor hardware wallet | |
| aws | No | Sign with AWS KMS (requires AWS_KMS_KEY_ID env var) | |
| gcp | No | Sign with Google Cloud KMS (requires GCP_PROJECT_ID, GCP_LOCATION, GCP_KEY_RING, GCP_KEY_NAME, GCP_KEY_VERSION env vars) | |
| value | No | ETH value to send with the transaction, e.g. "0.1ether" or amount in wei | |
| gasLimit | No | Gas limit override |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions 'state-changing' but does not detail side effects, authorization requirements (e.g., needing a private key or keystore), rate limits, or potential consequences. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that immediately conveys the core purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (17 parameters, no output schema, no annotations), the description is incomplete. It does not explain the return value (likely a transaction hash), error handling, prerequisites (deployed contract, signing method), or the relationship between multiple signing options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all parameters with good coverage (100%), so the description adds no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Send' and the resource 'state-changing transaction to a deployed contract', which matches the tool's function. The parenthetical '(cast send)' further identifies it, and it is distinct from siblings like cast_call (read-only) and deploy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for state-changing transactions, but does not explicitly state when to use it versus alternatives like cast_call for read-only queries or deploy for contract creation. No when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove build artifacts (out/ and zkout/) from a foundry project (forge clean)
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Absolute path to the foundry project directory | |
| profile | No | Foundry profile to use (maps to FOUNDRY_PROFILE env var). Selects a [profile.<name>] section from foundry.toml, e.g. 'zksync', 'ci', 'production'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a destructive operation (removal) but does not disclose safety, reversibility, permissions, or side effects (e.g., whether the artifacts can be regenerated). The description is too minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with the verb front-loaded. No wasted words; every part is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple cleanup tool with two parameters and no output schema, the description covers the basic purpose but omits context like return behavior, confirmation, or error handling. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions for both parameters. The description adds no additional meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('build artifacts (out/ and zkout/)') and explicitly mentions the corresponding forge command ('forge clean'), clearly distinguishing it from sibling tools like compile, test, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool's action but provides no guidance on when to use it versus alternatives (e.g., when to clean vs. compile), nor any exclusions or prerequisites. Usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compile a foundry-zksync project (forge build --zksync). Check foundry.toml for [profile.X.zksync] sections — if zkSync sources live under a specific profile (e.g. 'zksync'), pass that as the profile argument.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Absolute path to the foundry project directory | |
| profile | No | Foundry profile to use (maps to FOUNDRY_PROFILE env var). Selects a [profile.<name>] section from foundry.toml, e.g. 'zksync', 'ci', 'production'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fails to disclose side effects (e.g., artifact modification), error handling, or any destructive behavior. The description is too brief for a compile tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. First sentence states the action, second provides a critical usage hint. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description does not mention return values or success/failure indicators. It covers the purpose and a parameter detail but omits expectations on output, which is a gap for a compile tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context for the 'profile' parameter by explaining its relevance to zkSync profiles in foundry.toml, which goes beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Compile' and the resource 'foundry-zksync project', with a specific command equivalent ('forge build --zksync'). It differentiates from siblings like 'deploy' and 'run_script' by focusing on compilation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use the profile parameter but lacks explicit when-to-use or when-not-to-use instructions compared to sibling tools like 'deploy' or 'run_script'. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy a contract to a zkSync network (forge create --zksync). Returns structured output with contract address, tx hash, and deployer.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Absolute path to the foundry project directory | |
| profile | No | Foundry profile to use (maps to FOUNDRY_PROFILE env var). Selects a [profile.<name>] section from foundry.toml, e.g. 'zksync', 'ci', 'production'. | |
| contractPath | Yes | Contract identifier in the form src/MyContract.sol:MyContract | |
| rpcUrl | Yes | RPC URL of the target zkSync network | |
| privateKey | No | Raw private key for signing. Only use for local development with well-known test keys (e.g. anvil-zksync accounts). For production, use 'account' (named keystore) or hardware wallets instead. | |
| account | No | Named keystore account from ~/.foundry/keystores (recommended for production). Create one with: cast wallet import <name> --interactive | |
| keystore | No | Path to an encrypted keystore JSON file | |
| passwordFile | No | Path to a file containing the keystore password | |
| keystorePassword | No | Keystore password (prefer passwordFile to keep it out of process args) | |
| unlocked | No | Use eth_sendTransaction with --from address (no local signing). For nodes that manage keys natively. | |
| from | No | Sender address, used with --unlocked or hardware wallets. Maps to --from for cast/deploy, --sender for forge script. | |
| ledger | No | Sign with a Ledger hardware wallet | |
| trezor | No | Sign with a Trezor hardware wallet | |
| aws | No | Sign with AWS KMS (requires AWS_KMS_KEY_ID env var) | |
| gcp | No | Sign with Google Cloud KMS (requires GCP_PROJECT_ID, GCP_LOCATION, GCP_KEY_RING, GCP_KEY_NAME, GCP_KEY_VERSION env vars) | |
| broadcast | No | If true, actually broadcast the deployment transaction on-chain. Without this, forge create runs in dry-run mode. | |
| constructorArgs | No | Constructor arguments, each as a separate string. Solidity types are ABI-encoded by forge, e.g. ['0xaddr', '100', 'hello'] | |
| verify | No | If true, verify the contract on a block explorer after deployment | |
| verifierUrl | No | Block explorer verification API URL (e.g. https://api-era.zksync.network/api) | |
| extraArgs | No | Additional CLI flags, each as a separate array element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits such as side effects (gas costs), failure modes, or permission requirements. Only mentions return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, front-loaded with key action and result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 20 parameters and no output schema, the description is extremely sparse. Does not explain the significance of broadcast, various signing methods, or verification step. Incomplete for a complex deployment tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 20 parameters. Description adds no additional meaning beyond what schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool deploys a contract to zkSync using 'forge create --zksync' and returns structured output with contract address, tx hash, and deployer. It distinguishes from sibling tools like compile, verify, and run_script.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Sibling tools include run_script and verify, but description does not explain selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain raw output from foundry-zksync: error messages, logs, or transactions. Matches against a knowledge base of known zkSync gotchas and returns actionable advice. Use context='general' for background on what foundry-zksync is and how it works.
| Name | Required | Description | Default |
|---|---|---|---|
| rawText | Yes | Raw text to explain — can be an error message, forge log output, transaction hash, ABI-encoded data, or a general question about foundry-zksync | |
| context | No | Hint for what kind of text this is. 'general' prepends foundry-zksync background context. Defaults to general. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals the tool matches against a knowledge base and returns actionable advice. It does not disclose output format, error handling for unknown inputs, or any side effects, but the read-only nature is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose and a key usage hint. No superfluous content; front-loaded with core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input types and behavior, but lacks details on output format. Given no output schema, a bit more on what 'actionable advice' looks like would improve completeness, but overall sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds no extra meaning beyond the schema, though it reinforces the context='general' usage. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool explains raw output from foundry-zksync (error messages, logs, transactions) and matches against a knowledge base for actionable advice. It distinguishes from siblings like get_zksync_docs by focusing on specific outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using context='general' for background, providing clear when-to guidance. However, it does not mention when not to use this tool or suggest alternatives for general documentation, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run tests and generate a gas usage report (forge test --zksync --gas-report). Note: zkSync gas values are aggregate-only (no computation/pubdata breakdown).
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Absolute path to the foundry project directory | |
| profile | No | Foundry profile to use (maps to FOUNDRY_PROFILE env var). Selects a [profile.<name>] section from foundry.toml, e.g. 'zksync', 'ci', 'production'. | |
| filter | No | Regex passed to --match-test to filter which test functions run | |
| contractFilter | No | Regex passed to --match-contract to filter which contracts appear in the report | |
| pathFilter | No | Glob passed to --match-path to filter which test files run |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of transparency. It discloses that the tool runs tests (potential for state changes but minimal), generates a report, and notes that zkSync gas values are aggregate-only. However, it does not mention side effects, permissions, or whether the report is saved or returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence with a parenthetical note. Every word adds value, front-loading the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description should compensate by explaining the output format, where the report is written, or how to interpret results. It only notes a limitation of zkSync values, leaving agents uncertain about what to expect from the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions (e.g., projectPath, profile, filter). The description adds the overall action context but does not further clarify individual parameters beyond what the schema already provides, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool runs tests and generates a gas usage report, specifying the underlying command (forge test --zksync --gas-report) and a key limitation about zkSync gas values. This distinguishes it from sibling tools like 'test' (plain test execution) and 'snapshot'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a gas report is needed, but it does not explicitly state when to use this tool vs alternatives like 'test' or 'snapshot'. No prerequisites or when-not-to-use conditions are mentioned, leaving guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up foundry-zksync documentation by topic. Returns URLs to the foundry-zksync book for installation, config, testing, deployment, cheatcodes, nonces, factory deps, paymasters, verification, and more. Use topic='list' to see all available topics.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic to look up in the foundry-zksync book. Examples: 'installation', 'forge-test', 'cheatcodes', 'deployment', 'config', 'zksync-config', 'nonces', 'factory-deps', 'paymaster', 'verification', 'cast-send', 'cast-call', 'evm-interpreter'. Or use 'list' to see all available topics. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it returns URLs. With no annotations, it covers the main behavioral aspect (read-only lookup). No side effects mentioned, but appropriate for a documentation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded purpose, no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple documentation lookup tool with one parameter and no output schema, the description covers what it does, how to use it, and what to expect as output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes the 'topic' parameter with examples. Description adds emphasis on 'list' but does not provide additional semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it looks up foundry-zksync documentation by topic and returns URLs, distinguishing it from sibling tools that execute commands (e.g., compile, test).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear use case and mentions the 'list' topic to see all topics. Could explicitly contrast with siblings, but the purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scaffold a new foundry project and add [profile.default.zksync] config (forge init)
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Absolute path where the new project should be created | |
| name | No | Project name (used as directory name if projectPath is the parent) | |
| noGit | No | If true, skip git initialization (--no-git) | |
| noCommit | No | If true, skip the initial git commit (--no-commit) | |
| template | No | GitHub template to use, e.g. 'PaulRBerg/foundry-template' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'scaffold' and 'add config', but does not disclose details like git repository creation (though schema has noGit and noCommit), file overwriting behavior, or other effects. Some transparency, but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action. No redundant words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters and no output schema, the description is minimal. It does not explain the output or side effects (e.g., created files, git state). For a scaffolding tool, more context is needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds context about the config addition but does not explain parameter usage or relationships beyond what schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb 'scaffold' and resource 'new foundry project', and specifies the addition of a specific config. This distinguishes it from sibling tools like compile, test, and cast_* commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites mentioned (e.g., directory existence, required dependencies). The description only states what it does, not when or why to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install dependencies for a foundry project (forge install)
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Absolute path to the foundry project directory | |
| dependencies | No | Dependencies to install, e.g. ['OpenZeppelin/openzeppelin-contracts', 'transmissions11/solmate']. If omitted, installs all existing dependencies from foundry.toml. | |
| noCommit | No | If true, passes --no-commit to skip creating a git commit for the install |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action. It fails to disclose important behaviors such as network access to download dependencies, file modifications, default git commit creation, or required permissions. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste. However, for a tool that could benefit from behavioral context, it might be too terse, balancing conciseness with completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no output schema, no annotations), the description covers the basic purpose but lacks behavioral or usage context that an AI agent would need to invoke it correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters. The description adds no extra meaning beyond the schema; it just restates the purpose. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Install' and resource 'dependencies for a foundry project', and includes the alias '(forge install)' which reinforces the purpose. It effectively distinguishes from sibling tools like compile, deploy, or test, which have different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus siblings or when not to use it. The purpose is implied but not formally stated in terms of context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read and return the contents of foundry.toml from a project. Useful for inspecting profiles, zkSync config, library links, and other settings.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Absolute path to the foundry project directory | |
| summary | No | If true, return a summary highlighting zkSync-relevant config (profiles, zksolc version, compile mode, libraries) instead of raw TOML. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden of behavioral disclosure. It indicates a read-only operation but doesn't explicitly confirm no side effects or address potential failure modes (e.g., file not found). The behavioral transparency is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core action, the second adds context. It is concise, front-loaded, and every sentence provides value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no output schema, few params), the description covers the basic purpose but lacks details on edge cases (e.g., behavior if file is missing) or return format. It is minimally sufficient but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters documented in schema). The description adds no additional meaning or clarification beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read and return') and the resource ('contents of foundry.toml'), making the purpose immediately obvious. It also lists use cases, which differentiate it from sibling tools that perform actions like compile or deploy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting config, but lacks explicit guidance on when to use this tool vs alternatives (e.g., other read tools if any). No exclusions or context for when not to use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a forge script targeting zkSync (forge script --zksync)
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Absolute path to the foundry project directory | |
| profile | No | Foundry profile to use (maps to FOUNDRY_PROFILE env var). Selects a [profile.<name>] section from foundry.toml, e.g. 'zksync', 'ci', 'production'. | |
| scriptPath | Yes | Path to the Solidity script file, e.g. script/Deploy.s.sol | |
| rpcUrl | No | RPC URL to fork from or broadcast to | |
| sender | No | Address to use as msg.sender for the script simulation (--sender). Useful for dry-run without a signing key. | |
| broadcast | No | If true, passes --broadcast to actually send transactions on-chain | |
| slow | No | If true, sends transactions sequentially (--slow). Required on ZK chains which do not support transaction batching. | |
| privateKey | No | Raw private key for signing. Only use for local development with well-known test keys (e.g. anvil-zksync accounts). For production, use 'account' (named keystore) or hardware wallets instead. | |
| account | No | Named keystore account from ~/.foundry/keystores (recommended for production). Create one with: cast wallet import <name> --interactive | |
| keystore | No | Path to an encrypted keystore JSON file | |
| passwordFile | No | Path to a file containing the keystore password | |
| keystorePassword | No | Keystore password (prefer passwordFile to keep it out of process args) | |
| unlocked | No | Use eth_sendTransaction with --from address (no local signing). For nodes that manage keys natively. | |
| from | No | Sender address, used with --unlocked or hardware wallets. Maps to --from for cast/deploy, --sender for forge script. | |
| ledger | No | Sign with a Ledger hardware wallet | |
| trezor | No | Sign with a Trezor hardware wallet | |
| aws | No | Sign with AWS KMS (requires AWS_KMS_KEY_ID env var) | |
| gcp | No | Sign with Google Cloud KMS (requires GCP_PROJECT_ID, GCP_LOCATION, GCP_KEY_RING, GCP_KEY_NAME, GCP_KEY_VERSION env vars) | |
| extraArgs | No | Additional CLI flags, each as a separate array element, e.g. ['--verify', '--etherscan-api-key', 'abc'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only provides a one-line command example. It omits key behaviors: whether broadcasting is default, side effects of simulation vs real execution, network dependencies, or auth requirements beyond what the schema lists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Overly concise – a single sentence that barely extends beyond the tool name. It sacrifices usefulness for brevity, failing to provide critical context for such a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is severely incomplete given 19 parameters, no output schema, and no annotations. It does not describe return values, side effects, error conditions, or usage patterns, leaving the agent without essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description adds no additional parameter semantics beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a forge script for zkSync, with the specific command `forge script --zksync`. It uses a strong verb-resource combination and distinguishes from siblings like `deploy` which likely has different semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like `deploy` or `explain`. It does not specify prerequisites, when not to use it, or provide examples of appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or compare gas snapshots (forge snapshot --zksync). Use diff=true to compare against existing .gas-snapshot, check=true to fail on changes.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Absolute path to the foundry project directory | |
| profile | No | Foundry profile to use (maps to FOUNDRY_PROFILE env var). Selects a [profile.<name>] section from foundry.toml, e.g. 'zksync', 'ci', 'production'. | |
| filter | No | Regex passed to --match-test to filter which test functions run | |
| contractFilter | No | Regex passed to --match-contract to filter which test contracts run | |
| diff | No | If true, compare against the existing .gas-snapshot file and show differences | |
| check | No | If true, compare against existing snapshot and fail if any gas values changed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions creation and comparison but omits critical details like file overwriting (destructive behavior), required permissions, or the effect on .gas-snapshot files. The lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two focused sentences with no redundant information. The core purpose and key usage hints are front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters, no output schema, and no annotations, the description is inadequate for complete guidance. It covers the main function and two boolean parameters but leaves required 'projectPath' and other optional parameters unexplained beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so baseline is 3. The description adds meaning for 'diff' and 'check' parameters beyond the schema, but does not provide additional semantics for the required 'projectPath' or other optional filters. The added value is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or compares gas snapshots, which is a specific verb-resource combination. It hints at the command-line equivalent but does not explicitly distinguish from the sibling 'gas_report' tool, though the context implies different functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage hints for the 'diff' and 'check' boolean parameters, but does not offer guidance on when to use this tool versus alternatives like 'gas_report' or when not to use it. It leaves the user to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run tests in a foundry-zksync project (forge test --zksync). Check foundry.toml for [profile.X] sections — if the test directory differs per profile (e.g. profile 'zksync' has test = 'zksync/tests'), pass the correct profile argument.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Absolute path to the foundry project directory | |
| profile | No | Foundry profile to use (maps to FOUNDRY_PROFILE env var). Selects a [profile.<name>] section from foundry.toml, e.g. 'zksync', 'ci', 'production'. | |
| filter | No | Regex passed to --match-test to filter which test functions run | |
| contractFilter | No | Regex passed to --match-contract to filter which test contracts run | |
| pathFilter | No | Glob passed to --match-path to filter which test files run, e.g. 'test/unit/*' | |
| verbosity | No | Verbosity level (0-5), maps to -v through -vvvvv. Higher = more trace output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the underlying command and configuration file interaction but does not disclose side effects, permissions, or error handling. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the main purpose. Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no output schema, the description covers the core purpose and profile nuance but does not explain what happens after execution (e.g., output format, exit codes) or potential side effects. Adequate for a tool with limited complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by explaining the profile parameter's relation to foundry.toml and clarifying that filter parameters use regex. This enhances understanding beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs tests in a foundry-zksync project using 'forge test --zksync'. It is specific and distinguishes from sibling tools by emphasizing the ZKsync context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises checking foundry.toml for profile-specific test directories and passing the correct profile argument. It provides clear context but does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a deployed contract on a block explorer (forge verify-contract --zksync). Supports Etherscan (requires API key) and zkSync Explorer (no key needed).
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Absolute path to the foundry project directory | |
| profile | No | Foundry profile to use (maps to FOUNDRY_PROFILE env var). Selects a [profile.<name>] section from foundry.toml, e.g. 'zksync', 'ci', 'production'. | |
| contractAddress | Yes | Deployed contract address to verify | |
| contractPath | Yes | Contract identifier, e.g. src/MyContract.sol:MyContract | |
| verifier | Yes | Verification backend. 'etherscan' requires an API key, 'zksync' uses the zkSync Explorer (no API key needed). | |
| verifierUrl | Yes | Verifier API URL. Etherscan mainnet: https://api-era.zksync.network/api, Etherscan testnet: https://api-sepolia-era.zksync.network/api, Explorer mainnet: https://explorer.zksync.io/contract_verification, Explorer testnet: https://sepolia.explorer.zksync.io/contract_verification | |
| etherscanApiKey | No | Etherscan API key (required when verifier is 'etherscan') | |
| constructorArgs | No | ABI-encoded constructor arguments (hex string, no 0x prefix) | |
| compilerVersion | No | Compiler version used for deployment, e.g. v0.8.26+commit.8a97fa7a | |
| numOptimizations | No | Number of optimization runs used during compilation | |
| retries | No | Number of verification retries (default: 2, max: 10). Minimum is 1. Forge retries on transient failures. | |
| extraArgs | No | Additional CLI flags |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the underlying forge command and API key requirements, but fails to disclose potential side effects, failure modes (e.g., network errors), or verification process details (e.g., polling, retries). The description is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that cover the core purpose and key distinction (API key requirement). However, it could be slightly more structured (e.g., bullet points for different verifiers) without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters and no output schema, the description covers the main verification flow but lacks details on return values, verification success/failure indicators, and error handling. It is adequate but not fully complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so each parameter is documented. The tool description adds minimal extra context (e.g., verifier URLs, API key requirement). The baseline is 3 since the schema already provides comprehensive parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: verifying a deployed contract on a block explorer. It specifies the verb 'verify', the resource 'deployed contract', and supports specific explorers (Etherscan, zkSync Explorer). It is distinct from sibling tools like 'deploy' or 'compile'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that Etherscan requires an API key while zkSync Explorer does not, but it does not explicitly specify when to use this tool versus alternatives or provide exclusions. Usage context is implied but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.3anvil_zksynccast_abi_decodecast_abi_encodecast_balancecast_callcast_calldata_decodecast_noncecast_sendcleancompiledeployexplaingas_reportget_zksync_docsinitinstallread_foundry_tomlrun_scriptsnapshottestverifyEach tool has a clearly distinct purpose: node management, ABI operations, contract interactions, compilation, deployment, testing, documentation, etc. No two tools overlap in function; even decoding tools differ in input type.
Tools follow a mix of patterns: some are single verbs (compile, deploy), others are prefixed with 'cast_' for Foundry commands, and a few are descriptive (get_zksync_docs, read_foundry_toml). While not a strict verb_noun pattern throughout, naming is intuitive and predictable.
With 21 tools, the server covers the full lifecycle of foundry-zksync development without being overwhelming. Each tool serves a necessary role, and the count is well-scoped for the domain.
The tool set covers all major operations: project setup, compilation, deployment, testing, gas analysis, script execution, contract interaction, ABI handling, verification, and documentation. No critical gaps are apparent for typical foundry-zksync workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provide AI agents and automation tools with contextual access to blockchain data including balance…
OpenAI-compatible LLM MCP (7 tools); chat via balance key or x402 USDC on Base
Non-custodial DeFi for AI agents: swaps, concentrated liquidity (V3/V4) zaps + ranges, 5 EVM chains
Helps AI coding agents integrate MetaMask Embedded Wallets (Web3Auth) SDKs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jrigada/foundry-zksync-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
