Integrates with Docker to run and manage Succinct Prover Network containers, including hardware calibration, prover operations, and container monitoring.
Enables interaction with the Succinct Prover Network on Ethereum's Sepolia testnet, including prover contract management, PROVE token staking, proof request handling, and earning rewards for generating proofs.
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., "@Prover MCP calibrate my prover hardware"
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.
⚠️ Testnet Only: This MCP is for Sepolia testnet only.
A Model Context Protocol (MCP) server that enables AI assistants to control Succinct Prover Network operations following the official Succinct workflow.
⚠️ Security Notice: Use only fresh test wallets for Sepolia testnet. Never use mainnet private keys!
Node.js 18+ - Download here
Docker Desktop - Download here
⚠️ Must be running before setup
Fresh Ethereum Wallet
Create a new wallet (MetaMask, etc.)
Get Sepolia ETH from faucet
Export private key (64 hex characters, no 0x prefix)
PROVE Tokens
Get 1000+ PROVE tokens from official faucet
Minimum 1000 PROVE required for staking
Related MCP server: Avalanche MCP Tools
git clone https://github.com/d3lta02/prover-mcp.git
cd prover-mcp
npm install
npm run buildOption 1: Interactive Setup (Recommended)
npm run init
# Choose: Interactive Setup
# Select: AI client preference
# Optional: Add credentials during setupOption 2: Auto Setup (Fastest)
npm run init
# Choose: Auto Setup
# Automatically configures detected AI clientsnpm start
# Succinct Prover Network MCP Server runningBoth methods create:
📄 .env file with configuration template
🤖 AI client MCP configurations (Claude/Cursor)
📋 Next steps following official Succinct workflow
Environment variables are set directly in your AI client's MCP configuration:
Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json
Cursor IDE: ~/.cursor/mcp.json
{
"mcpServers": {
"succinct-prover": {
"command": "node",
"args": ["./build/index.js"],
"cwd": "/path/to/your/prover-mcp",
"env": {
"PROVER_ADDRESS": "your_prover_contract_address",
"PRIVATE_KEY": "your_64_character_private_key_no_0x_prefix"
}
}
}
}Edit the .env file created by setup:
# Edit with your real credentials
PROVER_ADDRESS=0x1234567890123456789012345678901234567890
PRIVATE_KEY=1234567890123456789012345678901234567890123456789012345678901234💡 Pro Tip: MCP config method bypasses tool cache issues and provides better reliability.
The setup follows the official 5-step Succinct workflow:
✅ Requirements (Automated by setup)
Fresh Ethereum wallet with Sepolia ETH
1000+ PROVE tokens from faucet
Docker Desktop running
🏗️ Create Prover Contract (Manual)
Connect wallet & create prover
Save prover address (different from wallet address!)
💰 Stake PROVE Tokens (Manual)
Stake minimum 1000 PROVE tokens
⚙️ Calibrate Hardware (AI Assisted)
Command: "Calibrate my prover hardware"
🚀 Run Prover (AI Assisted)
Command: "Run Succinct Prover"
💬 "Run Succinct Prover" - Start the prover and earn PROVE tokens
💬 "Calibrate my prover hardware" - Optimize performance settings
💬 "Show Succinct workflow" - Check setup progress
💬 "Get my prover status" - View current earnings and performance
💬 "Get proof requests" - View available proof requests
💬 "Get my account balance" - Check PROVE token balance
💬 "Stop my prover" - Gracefully stop the prover
For advanced users who want to monitor prover logs directly in terminal:
# Find your container ID
docker ps | grep succinct
# Stream live logs
docker logs -f CONTAINER_ID
# Monitor resource usage
docker stats CONTAINER_ID💡 Note: Replace CONTAINER_ID with your actual container ID. The MCP provides smart log viewing, but terminal monitoring offers real-time streaming for power users.
The MCP server provides secure access to Succinct Prover Network operations:
Environment Loading: Credentials loaded from MCP config (priority) or .env file
Docker Integration: Official Succinct Docker images with hardware optimization
AI Commands: Natural language interface to prover operations
Security: Sepolia testnet only, credentials never logged
The MCP configuration ensures environment variables are available to all tools, bypassing cache issues.
❌ "Environment validation failed"
Ensure credentials are set in MCP config or .env file
Restart your AI client completely after configuration changes
❌ "Docker not found"
Install and start Docker Desktop
Verify: docker --version
❌ "Tool cache issues"
Use MCP config method instead of .env file
MCP config bypasses tool cache limitations
❌ "No PROVE tokens"
Get tokens from official faucet
Minimum 1000 PROVE required for staking
npm run validate # Validate installation
npm run init # Re-run setup process
npm test # Run test suite🔒 CRITICAL SECURITY NOTES
Testnet Only: This MCP only works with Sepolia testnet
Fresh Wallets: Use dedicated test wallets, never mainnet wallets
Private Keys: Never commit credentials to version control
Official Sources: Only use official Succinct URLs and contracts
All credential files are automatically git-ignored for security.
npm run buildnpm test
npm run validatesrc/
├── index.ts # MCP server entry point
├── main.ts # CLI argument handling
├── cli/init.ts # Interactive setup tool
├── tools/prover/ # Prover network tools
├── tools/network/ # Network status tools
└── tools/monitoring/ # Performance monitoringFork the repository
Create feature branch: git checkout -b feature-name
Follow the official Succinct documentation
Test with Sepolia testnet only
Submit pull request
MIT License - See LICENSE file for details.
⚡ Ready to start earning PROVE tokens? Run npm run init and follow the setup!
💡 Important: The
cwd(current working directory) parameter is automatically set bynpm run initto ensure relative paths work correctly across different installations.
🔴 Continuous auto-streaming prover logs with periodic refresh (no manual commands)
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | Number of log lines to show (default: 50) | |
| containerId | No | Container ID (optional - auto-detect if not provided) | |
| refreshCount | No | Number of times to refresh (default: 3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavior. It mentions 'continuous auto-streaming with periodic refresh' but omits details like refresh interval, blocking behavior, or side effects. Partially transparent 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?
Description is a single sentence with a red emoji. It is concise and front-loaded, though the emoji adds minor noise. No unnecessary content.
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 3 parameters and no output schema or annotations, the description is too minimal. It lacks behavior details like return value, errors, or lifecycle of the streaming. Incomplete for a tool of this 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% with descriptions for all three parameters. The description adds no extra meaning 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 'Continuous auto-streaming prover logs with periodic refresh (no manual commands)', specifying the verb and resource. It distinguishes from siblings like 'stream_prover_logs_to_terminal' by emphasizing automation, but lacks explicit differentiation.
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 like 'show_live_prover_logs' or 'stream_prover_logs_to_terminal'. The phrase 'no manual commands' hints at automation but does not specify prerequisites or 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.
Official Succinct hardware calibration to determine optimal bidding parameters for maximum profitability
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Hardware mode for calibration | |
| usdCostPerHour | No | USD cost per hour for your hardware |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden. It does not disclose side effects (e.g., state changes, destructive potential), required permissions, or whether calibration is a long-running process. The phrase 'determine optimal bidding parameters' is vague regarding actual behavior.
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, efficient sentence with no extraneous information. It is front-loaded with the key action and intended outcome.
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 lacks information about return value or output format, which is critical since no output schema exists. It also omits behavioral context like whether calibration is synchronous or requires specific hardware setup. This makes it incomplete for confident use.
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%, with the schema already explaining 'mode' and 'usdCostPerHour'. The description adds no further meaning beyond stating the tool's purpose, so it meets baseline without adding value.
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 performs 'hardware calibration' to 'determine optimal bidding parameters for maximum profitability', which is a specific verb+resource that distinguishes it from sibling tools like submit_bid or get_prover_metrics.
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 versus alternatives, such as after hardware setup or before bidding. No prerequisites, conditions, 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.
Create and store artifacts on the network
| Name | Required | Description | Default |
|---|---|---|---|
| metadata | No | Additional metadata for the artifact | |
| artifactType | Yes | Type of artifact (circuit, proof, data, config) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states 'create and store', omitting details on side effects, permissions, idempotency, or what 'store' entails.
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, efficient sentence. It is front-loaded and contains no fluff, though additional detail would not harm 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?
Given no annotations and no output schema, the description fails to explain what happens after creation (e.g., return value, persistence, errors). It is insufficient for an agent to fully understand the tool's behavior.
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 the description adds no new meaning beyond what is already in the schema. 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 action (create and store) and the resource (artifacts). The schema further specifies artifact types, giving some specificity. However, it does not differentiate from sibling tools, though no sibling shares the same name.
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 like create_prover or request_proof. The description provides no context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
(MANUAL STEP) Provides the URL to create your prover contract on-chain.
| Name | Required | Description | Default |
|---|---|---|---|
| stakerFeeBips | No | Staker fee in basis points (0-10000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only says it provides a URL for a manual step. It does not disclose side effects, required privileges, or what happens after obtaining the URL, leaving significant behavioral gaps.
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 is concise but lacks detail; it is appropriately short but does not fully leverage the space.
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 only one parameter and no output schema, the description is incomplete. It does not explain prerequisite steps, the format of the URL, or how to proceed after creation.
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 a clear description of 'stakerFeeBips', but the description does not mention the parameter or explain its role in the manual step. No added value 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?
The description states it provides a URL to create a prover contract, which gives a basic idea but uses 'Provides' vaguely. It distinguishes from sibling tools by mentioning 'manual step', but purpose could be clearer.
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, such as 'stake_to_prover' or 'run_prover'. The manual step nature is stated but not contextualized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed environment debugging and auto-restore report
| Name | Required | Description | Default |
|---|---|---|---|
| random_string | Yes | Dummy parameter for no-parameter tools |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose whether the tool is read-only, requires special permissions, has side effects, or what the report includes. The phrase 'auto-restore report' hints at state information but is insufficient.
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, which is concise but omits important details. It is front-loaded but too sparse for a tool that returns a detailed report.
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?
There is no output schema, so the description should explain what the debugging report contains, including the auto-restore information. It does not, leaving the agent with an incomplete understanding of the tool's 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?
The only parameter is described in the schema as a dummy placeholder, and the description adds no further meaning. It does not clarify why the parameter exists or how the agent should use it.
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 retrieves a debugging and auto-restore report, with a specific verb and resource. However, it does not differentiate from sibling tools like 'get_environment_status', which may have overlapping 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?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The agent receives no help in selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Smart hardware detection with official Succinct requirements analysis and competitive profitability assessment
| Name | Required | Description | Default |
|---|---|---|---|
| random_string | Yes | Dummy parameter for no-parameter tools |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It fails to mention side effects, permissions, rate limits, or whether the tool is read-only or mutating. The term 'detection' implies reading but is not explicit.
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 short but lacks structure. It uses marketing language ('smart', 'official', 'competitive') without conveying factual information, making it inefficient.
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 absence of annotations and output schema, the description is insufficient. It does not explain return values, behavior, or how results are presented, leaving the agent without a complete understanding.
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 a single dummy parameter, so the description does not need to add much. However, the description does not clarify that the parameter is meaningless, leaving the agent without insight.
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 vague terms like 'smart hardware detection' and 'competitive profitability assessment' without specifying what exactly the tool does or what resource it acts on. It does not distinguish from sibling tools like calibrate_prover_hardware, which likely has a related 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 guidance is given on when to use this tool instead of alternatives. The description lacks context for appropriate usage scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get PROVE token balance for an account
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | Account address (optional, uses prover address if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. Only states 'Get', implying read-only, but no details on side effects, network calls, or permissions. Minimal behavioral disclosure.
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 is concise and front-loaded. Every word adds value; no fluff or 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?
Simple tool but missing output schema and any description of return value. Does not explain what 'balance' means (e.g., integer, decimal, format). No sibling differentiation or context about when this might fail.
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 has 100% description coverage for the single optional parameter. Description adds no additional meaning beyond what schema provides, 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?
Description clearly states the verb 'Get', resource 'PROVE token balance', and scope 'for an account'. It is specific and distinguishes from siblings like get_account_info which likely returns broader account data.
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 such as get_account_info or faucet tools. Missing context about prerequisites or ideal use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed account information and statistics
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | Account address (optional, uses prover address if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose any behavioral traits beyond the obvious. Does not explain if the tool is read-only or has side effects, nor what happens with missing address.
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. However, it could benefit from slightly more structure to include usage hints.
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, and description is too brief. Does not mention what statistics or information is returned, leaving the agent with incomplete expectations.
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 the description adds no additional meaning beyond the schema. 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 it retrieves detailed account information and statistics, using a specific verb and resource. It differentiates from siblings like get_account_balance and get_nonce which are more specific.
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. Does not mention that it uses the prover address by default or when to provide an explicit address.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed environment configuration and .env file status
| Name | Required | Description | Default |
|---|---|---|---|
| random_string | Yes | Dummy parameter for no-parameter tools |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, and the description only states the action without disclosing read-only nature, side effects, authentication needs, or what 'detailed environment configuration' entails. The dummy parameter is not explained in the description, leaving the agent with minimal behavioral insight.
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, but it omits essential details that could be included without verbosity. Adequate for minimal information but not optimally front-loaded or complete.
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 output schema and annotations, the description should provide more context about what 'detailed environment configuration' includes and what the .env file status looks like. It is insufficient for an agent to use the tool effectively.
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 covers the single parameter with a description, achieving 100% coverage. The description adds no extra meaning beyond the schema, so 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 it gets environment configuration and .env file status, specifying the verb 'get' and the resource. However, it does not differentiate from the sibling tool 'debug_environment', which could have overlapping 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?
No guidance is provided on when to use this tool versus alternatives, nor any context on prerequisites or limitations. The agent receives no help in deciding between get_environment_status and similar tools like debug_environment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get unassigned proof requests matching criteria
| Name | Required | Description | Default |
|---|---|---|---|
| version | No | Filter by circuit version | |
| minDeadline | No | Minimum deadline (timestamp) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral traits. It only states a read-like operation with no mention of side effects, authentication needs, limits, or pagination. The agent cannot assess safety or constraints from this description alone.
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 redundant words. It efficiently communicates the core action and object. However, it omits important details like usage context and behavior, which slightly reduces its completeness despite the brevity.
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 filtered list tool with two fully documented parameters, the description is adequate but lacks details such as whether filters combine with AND/OR, default results, ordering, or response format. The absence of an output schema and annotations leaves moderate gaps for the agent to resolve.
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%, meaning both parameters have clear descriptions in the schema. The tool description adds no additional meaning beyond what the schema already provides, so the 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 'Get', the resource 'unassigned proof requests', and the filtering condition 'matching criteria'. This distinguishes it from sibling tools like 'get_proof_status' or 'request_proof' which cover different aspects of proof requests.
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 retrieving unassigned requests with criteria, but it does not explicitly specify when to use this tool versus alternatives or provide any exclusions. No sibling-based guidance is given, leaving the agent to infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get overall network statistics
| Name | Required | Description | Default |
|---|---|---|---|
| random_string | Yes | Dummy parameter for no-parameter tools |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states 'Get' which implies a read-only operation. It fails to disclose any behavioral traits such as data freshness, permissions required, or whether the operation is safe. The description does not add value beyond the implied read intent.
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 with no filler, but it is too brief to be effective. While concise, it sacrifices necessary detail, making it minimally viable rather than well-structured.
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?
Considering the lack of an output schema, the description should hint at the return format or types of statistics. It does not, leaving agents to guess. Additionally, with many similar sibling tools, the description is insufficient for a complete understanding of the tool's role.
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 one required parameter 'random_string' with a description stating it is a dummy. Schema coverage is 100%, so the parameter's purpose is already clear. The description adds no further meaning, but given the dummy nature, 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 'Get overall network statistics' clearly identifies the tool's function of retrieving network statistics. However, it lacks specificity about what 'network statistics' encompasses, and among siblings like get_system_health and get_prover_metrics, it doesn't differentiate the scope of data returned.
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 is provided on when to use this tool versus alternatives. With 24 sibling tools, including several other statistics tools, the absence of context or exclusions forces the agent to infer usage, reducing clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current account nonce for transaction ordering
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | Account address (optional, uses prover address if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It states only the action and purpose, omitting whether it is read-only, permission requirements, or error handling. Essential behavioral context is missing.
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?
Description is extremely short and front-loaded with the verb 'Get'. Every word is purposeful, but the brevity sacrifices completeness, making it slightly under-specified.
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 one optional parameter, the description covers the core purpose. However, it lacks behavioral details and return value hints, making it minimally adequate.
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 'address' described. The tool description adds no additional meaning beyond the schema's parameter description. 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 action 'Get current account nonce' and specifies the resource 'account nonce' with purpose 'for transaction ordering'. This distinguishes it from siblings like get_account_balance or get_account_info, as nonce is a specific concept.
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 or not use this tool versus alternatives. The description implies usage for retrieving nonce before transactions, but does not exclude other tools or provide context on prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get status of a proof request
| Name | Required | Description | Default |
|---|---|---|---|
| requestId | Yes | Proof request ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only says 'Get status', implying idempotent read, but lacks details on possible statuses, response format, or side effects.
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 phrase with no unnecessary 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?
Adequate for a simple status tool, but lacks details about status values or response behavior; could benefit from more contextual information.
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% and the description adds no extra meaning beyond the schema's 'Proof request ID' for the 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 retrieves status of a proof request, which is distinct from siblings like 'get_prover_status' and 'verify_proof'.
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 (e.g., 'get_filtered_requests'), nor any prerequisites like the need for a valid request ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about PROVE token faucet for testing
| Name | Required | Description | Default |
|---|---|---|---|
| random_string | Yes | Dummy parameter for no-parameter tools |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates read operation but does not disclose return format, auth requirements, or any side effects.
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 no waste. Front-loaded with key verb and resource.
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?
Tool is simple (1 dummy parameter, no output schema). Description states purpose and testing context but lacks details on what information is returned.
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 description 'Dummy parameter for no-parameter tools'. Description adds no additional meaning beyond schema, baseline score 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?
Description clearly states verb ('Get information') and resource ('PROVE token faucet') with context ('for testing'). No similar sibling tool, so distinct purpose is clear.
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 or alternatives. Since no other faucet tool exists, usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed prover performance metrics
| Name | Required | Description | Default |
|---|---|---|---|
| timeRange | No | Time range for metrics (e.g., "24h", "7d", "30d") | 24h |
| proverAddress | No | Prover address (optional, uses configured address if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It only says 'Get detailed prover performance metrics' without mentioning side effects, read-only nature, or output format. This is insufficient for an agent to understand behavior.
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 that efficiently conveys the core action. However, it could be slightly more informative without sacrificing brevity.
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 tool has no output schema and moderate complexity (2 optional params). The description fails to explain what 'detailed metrics' entails or the structure of the response, leaving the agent underinformed.
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 adds no additional meaning beyond what the schema already provides for the two parameters (timeRange and proverAddress).
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 retrieves prover performance metrics, distinguishing it from siblings like get_prover_status (current status) and run_prover (execution). However, it could more explicitly specify that it returns metrics over a time range.
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 versus alternatives such as get_prover_status or get_network_stats. It neither states prerequisites nor gives usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time status, performance metrics, and earnings of your running prover
| Name | Required | Description | Default |
|---|---|---|---|
| containerId | No | Docker container ID (optional - auto-detect if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It indicates a read operation and auto-detection of container ID, but lacks details on authentication, rate limits, or what happens if the prover is not running.
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 one short sentence with 12 words, effectively front-loading the purpose. It is concise but could optionally be structured as bullet points for clarity.
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 one optional parameter and no output schema, the description adequately lists what the tool returns (status, metrics, earnings). Given the tool's simplicity, it is fairly complete. Additional details on output structure would be beneficial but are not essential.
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 covers the parameter fully. The description adds no extra meaning beyond what the 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 retrieves 'real-time status, performance metrics, and earnings' of a running prover, using a specific verb and resource. It differentiates from sibling 'get_prover_metrics' by including status and earnings.
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 used to get comprehensive prover info, but does not explicitly state when to use it versus alternatives like 'get_prover_metrics' or prerequisites (e.g., prover must be running). No exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get MCP system health and status information
| Name | Required | Description | Default |
|---|---|---|---|
| detailed | No | Include detailed component status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It fails to disclose whether the operation is read-only, what 'health' entails, or any side effects. Merely stating 'health and status information' is insufficient.
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 one sentence, no fluff, and front-loads the core purpose. It is appropriately concise for the tool's simplicity.
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 health check tool with one optional parameter and no output schema, the description is minimally adequate but lacks details on what the response contains or how 'health' is measured. It does not explain component status or the meaning of the detailed flag 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?
Schema coverage is 100% for the single parameter, so the baseline is 3. The tool description adds no extra meaning beyond the schema, but the schema itself provides adequate parameter documentation.
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 retrieves system health/status, with a specific verb and resource. It distinguishes from sibling tools that focus on prover-specific metrics or actions, though it doesn't explicitly differentiate.
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 is provided on when to use this tool versus alternatives, nor any context about prerequisites or typical use cases. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a proof request to the network
| Name | Required | Description | Default |
|---|---|---|---|
| vkHash | Yes | Verification key hash | |
| version | No | Circuit version | sp1-v4.0.0-rc.3 |
| deadline | No | Deadline timestamp | |
| stdinUri | Yes | URI to input data | |
| cycleLimit | Yes | Maximum cycles for proof generation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description is minimal and does not disclose behavioral traits like asynchronicity, cost, or side effects. With no annotations, the description fails to provide essential 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?
The description is a single sentence, but it is too brief given the tool's complexity (5 parameters, 3 required); it could be more informative without sacrificing 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?
Does not explain the purpose of parameters beyond schema, the return value (no output schema), or the overall workflow (e.g., asynchronous request submission). Incomplete for the tool's 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 description coverage is 100%, so the description adds no extra meaning beyond what the schema already provides for parameters like 'vkHash' and 'stdinUri'.
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's action ('submit') and resource ('proof request'), but does not differentiate from sibling tools like 'verify_proof' or 'get_proof_status'.
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 (e.g., 'verify_proof') or prerequisites (e.g., account balance, network state).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
🌟 (v2) Complete automated Succinct Prover setup & execution - The ONE CLICK solution to start earning PROVE tokens! Follows official 5-step workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Hardware mode (auto-detect recommended) | |
| privateKey | No | Override the PRIVATE_KEY from .env | |
| autoCalibrate | No | Automatically calibrate hardware before starting | |
| proverAddress | No | Override the PROVER_ADDRESS from .env |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions automation and a 5-step workflow but omits critical details like whether it overwrites existing processes, required resources, or side effects. The agent is left guessing about safety and impact.
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 short but includes marketing fluff (emoji, bold). It is not efficiently structured: it front-loads promotional language instead of crucial operational details. Could be more concise and 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?
Given the complexity of a prover execution tool with 4 parameters and many siblings, the description is extremely inadequate. It does not explain the workflow, expected outputs, error states, or configuration prerequisites. An agent cannot reliably use this tool based solely on the description.
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 no extra meaning beyond parameter descriptions; it does not elaborate on parameter usage or dependencies. No additional value provided.
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 automates prover setup and execution to earn tokens, using a 5-step workflow. It distinguishes from siblings by being the 'one-click' solution, but doesn't explicitly differentiate from similar tools like create_prover or stop_prover.
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. The description lacks context on prerequisites, whether creation must be done first, or when to use calibration tools. Agents have no basis for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
🔴 Show real-time live logs from your running Succinct Prover with extended history and activity monitoring
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | Number of log lines to show (default: 50) | |
| containerId | No | Container ID (optional - auto-detect if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates real-time behavior and extended history, but lacks details on resource impact, authentication needs, or error handling. The description 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 a single sentence with an emoji, concise and to the point. It loses one point for the emoji which may be seen as slightly informal, but overall is efficient.
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 no output schema and a simple purpose, the description adequately conveys the tool's function. It could mention output format or behavior on missing container, but is largely 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?
Input schema has 2 parameters with 100% coverage. The description adds no additional meaning beyond what is in the schema; it essentially repeats the parameter names. 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 shows real-time live logs from the Succinct Prover, specifying 'extended history and activity monitoring' which distinguishes it from sibling tools like 'auto_stream_prover_logs' and 'stream_prover_logs_to_terminal'.
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 is provided on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, leaving the agent without clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
(MANUAL STEP) Provides the URL to stake PROVE tokens to your prover on-chain.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount of PROVE tokens to stake | |
| proverAddress | Yes | Your prover contract address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description indicates it provides a URL rather than executing the staking directly, implying a non-destructive, informational step. However, it does not disclose potential side effects, permissions needed, or whether the URL leads to an external site.
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?
A single sentence that is front-loaded with the manual step indicator. It is concise and contains no unnecessary words, though it could benefit from a brief note on the output.
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 minimal given the lack of output schema and annotations. It does not explain what the URL looks like, how to use it, or prerequisites (e.g., having a prover contract). Error handling and return values are absent. With 2 required params, more context is expected.
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 for both parameters. The description adds no additional semantic meaning beyond what the schema already provides. Baseline score 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 provides a URL for staking PROVE tokens to a prover. The verb 'stake' and resource 'PROVE tokens to your prover' are specific. It distinguishes itself from sibling tools like 'get_prove_faucet' which is for faucet, not staking.
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 includes '(MANUAL STEP)' indicating it's not automated, but provides no explicit guidance on when to use this tool versus alternatives. No exclusions or contexts are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gracefully stop your Succinct Prover with proper cleanup
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Force stop if graceful shutdown fails | |
| containerId | No | Container ID (optional - auto-detect) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'proper cleanup' but does not explain what cleanup entails, whether the operation is reversible, or the implications of the force parameter. Behavioral details are insufficient.
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?
Description is a single, concise sentence with no redundant information. It front-loads the primary purpose, though a slightly more structured format could improve readability.
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 no output schema and no annotations, the description should cover return values, errors, and detailed behavior. It only mentions graceful stopping and cleanup, leaving gaps in what the agent needs to know for safe invocation.
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%, with both 'force' and 'containerId' described. The description adds no extra meaning beyond the schema, 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?
Description clearly states action (stop) and resource (Succinct Prover) with the phrase 'Gracefully stop your Succinct Prover with proper cleanup', effectively distinguishing it from sibling tools like run_prover or get_prover_status.
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 like run_prover or get_prover_status. No prerequisites or exclusions are mentioned, leaving the agent 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.
🔴 Get the exact docker logs -f terminal command for classic live streaming UX (copy & paste to terminal)
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | Number of log lines to show (default: 50) | |
| containerId | No | Container ID (optional - auto-detect if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description transparently states it returns a command (not actual logs) and is for copy/paste. Lacks mention of errors or prerequisites.
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 with emoji, front-loads key information, no superfluous content.
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 returning a command, description fully explains output and usage; no output schema needed.
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; description adds no extra meaning beyond schema. 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 returns a docker command for streaming logs, distinguishing it from siblings like auto_stream_prover_logs which likely auto-stream.
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?
Implied usage via 'classic live streaming UX' but no explicit when-to-use or when-not-to-use compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a bid for a proof request
| Name | Required | Description | Default |
|---|---|---|---|
| deadline | Yes | Bid deadline timestamp | |
| bidAmount | Yes | Bid amount in PROVE tokens | |
| requestId | Yes | Proof request ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only says 'submit' but does not disclose whether the action is idempotent, what side effects occur, what happens on duplicate bids, or any authentication requirements. This is insufficient for a state-changing operation.
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 that front-loads the purpose. It is not verbose, but could benefit from additional structure (e.g., bullet points for behavior).
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 transactional tool with no output schema and no annotations, the description is too minimal. It does not cover what happens after submission (e.g., response, errors, confirmation). Sibling tools add context but are not referenced.
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 no extra meaning beyond the schema's parameter descriptions (e.g., 'Bid amount in PROVE tokens'). The description does not explain formats or constraints not already 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 the action 'submit' and the resource 'bid for a proof request'. It is specific and distinguishes the tool from siblings like 'request_proof' (which creates a request) and 'verify_proof' (which verifies).
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 is given on when to use this tool versus alternatives (e.g., 'get_filtered_requests' to find requests, 'request_proof' to create one). There is no mention of prerequisites, context, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a proof using its URI and verification key
| Name | Required | Description | Default |
|---|---|---|---|
| vkHash | Yes | Verification key hash | |
| proofUri | Yes | URI to the proof data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Does not disclose if verification is a local computation or involves network calls, side effects, authentication needs, or computational cost.
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 no wasted words. Front-loads purpose. Could include more detail 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?
Minimal description for a tool with no output schema or annotations. Does not explain return value, possible errors, or prerequisites, leaving gaps for an AI agent.
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. Description repeats parameter names but adds no new meaning beyond schema descriptions.
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 verifies a proof using a URI and verification key, which are the two parameters. It distinguishes from sibling tools like 'request_proof' or 'get_proof_status', but could be more specific about what verification entails.
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 among many siblings (e.g., 'get_proof_status' or 'submit_bid'). Does not mention prerequisites or typical workflow context.
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.
v1.0.0auto_stream_prover_logscalibrate_prover_hardwarecreate_artifactcreate_proverdebug_environmentdetect_hardwareget_account_balanceget_account_infoget_environment_statusget_filtered_requestsget_network_statsget_nonceget_proof_statusget_prove_faucetget_prover_metricsget_prover_statusget_system_healthrequest_proofrun_provershow_live_prover_logsstake_to_proverstop_proverstream_prover_logs_to_terminalsubmit_bidverify_proofMost tools have clearly distinct purposes, but there is some overlap among the three logging tools (auto_stream_prover_logs, show_live_prover_logs, stream_prover_logs_to_terminal) and between debug_environment and get_environment_status, which could cause misselection.
Tool names consistently use snake_case and follow a verb_noun pattern (e.g., get_account_balance, create_prover). However, verbs like 'show' and 'stream' deviate slightly from the dominant 'get' pattern, and some names are lengthy.
25 tools is at the upper bound of typical server scope. While many are justified for comprehensive prover management, the multiple logging tools and some environment utilities could be consolidated, making it slightly heavy.
The tool surface covers the full prover lifecycle: creation, running, monitoring, staking, and proof handling. Minor gaps exist (e.g., no tool to update prover configuration or manage artifacts beyond creation), but overall it is well-rounded.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Native Solana staking for AI agents. 26 MCP tools, one-shot signing, webhooks.
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
AI-native settlement rail + intelligence oracle for autonomous agents. x402, Base mainnet, 81 tools.
OpenAI-compatible LLM MCP (7 tools); chat via balance key or x402 USDC on Base
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/d3lta02/prover-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server