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., "@ProofYield MCP find high-yield DeFi opportunities on Base"
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 Enterprise-Grade Model Context Protocol (MCP) Server for Verifiable DeFi Yield Discovery and Algorithmic Portfolio Planning.
ProofYield MCP bridges the gap between Large Language Models (LLMs) and decentralized finance by providing AI agents with standardized, secure tools to discover yield opportunities, formulate execution plans, and verify cryptographic proof-of-work receipts. Built on top of the Model Context Protocol (MCP), it acts as a modular middleware pipeline that enables assistants (such as Claude, Cursor, and custom agents) to interact safely with blockchain yield protocols.
Discovery Engine: Query real-time, risk-adjusted yield opportunities across decentralized protocols using standardized MCP tools.
Algorithmic Planning: Generate multi-step, risk-mitigated DeFi allocation strategies and execution paths tailored to user parameters.
Cryptographic Receipts & Evidence Tracking: Every discovery and planning action generates auditable proof receipts and evidence logs stored in persistent repositories.
Hardened Auth & Security Pipeline: Built-in middleware for request validation, authentication, and secure interaction modeling.
Interactive UI Widgets: Embedded modern frontend components (built with Next.js & React) designed to render rich DeFi dashboards directly inside MCP-client chat interfaces.
Smart Contract Integration: Includes Solidity smart contracts (e.g., MockYieldVault) deployed and tested using Foundry for on-chain verification and simulation.
Related MCP server: Universal Crypto MCP
The project is structured into modular layers with clear separation between MCP protocol handling, core business logic, on-chain contracts, and frontend widget rendering:
proofyield-mcp/
├── contracts/ # Solidity smart contracts & Foundry suites
│ ├── MockYieldVault.sol # Mock yield vault for testing & simulation
│ └── test/ # Foundry test cases (.t.sol)
├── deployments/ # Chain deployment artifacts (e.g., Base Sepolia)
├── scripts/ # Automation, deployment, and testing scripts
│ ├── deploy-vault.ps1 # PowerShell script for vault contract deployment
│ ├── dev-browser.mjs # Helper to launch UI widgets in browser dev mode
│ └── live-smoke.mjs # Smoke testing script against live/test environments
├── src/ # Core TypeScript MCP Server Application
│ ├── app.module.ts # Root application module defining DI & bootstrapping
│ ├── index.ts # Application entry point
│ ├── health/ # Health check endpoints and system monitoring
│ ├── modules/ # Domain specific feature modules
│ │ ├── discovery/ # Yield opportunity discovery (Tools, Prompts, Resources)
│ │ ├── planning/ # Strategy planning (Tools, Prompts, Resources)
│ │ └── shared/ # Shared services, schemas, & repositories
│ │ ├── config.service.ts # Environment & configuration management
│ │ ├── evidence.repository.ts # Persistence layer for audit/evidence logs
│ │ ├── receipt.repository.ts # Persistence layer for proof-of-work receipts
│ │ └── schemas.ts # Zod / data validation schemas
│ └── widgets/ # Next.js frontend widgets for MCP UI rendering
│ ├── app/ # Next.js App Router (Dashboard pages & layouts)
│ ├── lib/ # Browser MCP client utilities
│ └── out/ # Static HTML exports for UI embeds
├── tests/ # Integration and security test suites
│ └── core-security.test.mjs # Core auth & security validation tests
├── foundry.toml # Foundry configuration for smart contracts
├── package.json # Node.js dependencies & NPM scripts
└── tsconfig.json # TypeScript compiler configurationEnsure your development environment meets the following requirements:
Node.js: v18.x or v20.x (LTS recommended)
Package Manager: npm, pnpm, or yarn
Foundry: Required for smart contract compilation and testing (forge, cast, anvil)
Git: For version control and submodule management
git clone https://github.com/your-org/proofyield-mcp.git
cd proofyield-mcpInstall the root server dependencies as well as the UI widget dependencies:
# Install root MCP server dependencies
npm install
# Install Next.js UI widget dependencies
cd src/widgets && npm install && cd ../..Copy the example environment file and configure your local variables:
cp .env.example .envOpen .env and configure your RPC URLs, private keys (for testnets), and MCP server port configurations.
Compile the TypeScript server, build the frontend UI widgets, and compile the Foundry smart contracts:
# Build the TypeScript MCP server
npm run build
# Build the Next.js UI Widgets
cd src/widgets && npm run build && cd ../..
# Compile Solidity contracts using Foundry
forge buildRun the MCP server locally with hot-reloading enabled for rapid development:
npm run devTo test or develop the interactive UI widgets in your browser, launch the widget dev server:
node scripts/dev-browser.mjsTo run the compiled production server:
npm startThe server exposes two primary AI-facing modules via the Model Context Protocol:
/src/modules/discovery)Tools (discovery.tools.ts): Allows agents to query yield vaults, filter by APY/TVL, and assess smart contract risk scores.
Resources (discovery.resources.ts): Exposes live feeds of verified protocol metrics.
Prompts (discovery.prompts.ts): Pre-configured system prompts that instruct LLMs on how to analyze yield data objectively without hallucinating APYs.
/src/modules/planning)Tools (planning.tools.ts): Provides algorithmic step-by-step route generation for capital allocation (e.g., Bridge → Swap → Stake → Deposit).
Resources (planning.resources.ts): Access to historical execution strategies and gas optimization models.
Prompts (planning.prompts.ts): Guides agents in presenting risk-adjusted financial strategies and requesting user confirmation before execution.
Every action taken by the Discovery and Planning modules is cryptographically recorded:
receipt.repository.ts: Stores verifiable proof-of-work receipts for completed tool calls.
evidence.repository.ts: Maintains audit logs and data snapshots used to justify AI recommendations.
The /contracts directory contains the on-chain components powering ProofYield:
MockYieldVault.sol: An ERC-4626 compatible mock yield vault used to simulate staking, yield generation, and withdrawal flows on testnets (e.g., Base Sepolia).
Use the provided deployment scripts or Foundry directly:
# Deploy using Foundry (example for Base Sepolia)
forge script contracts/deploy/Deploy.s.sol:Deploy --rpc-url $BASE_SEPOLIA_RPC --broadcast
# Or use the provided automation script
./scripts/deploy-vault.ps1We enforce strict test coverage across smart contracts, server logic, and security pipelines.
Execute the Solidity test suite to verify vault mechanics and math:
forge test -vvvRun the Node.js test suites to validate middleware pipelines, authentication guardrails, and tool execution:
# Run core security and authentication tests
node tests/core-security.test.mjs
# Execute a live smoke test against running endpoints
node scripts/live-smoke.mjsProofYield MCP includes pre-configured agent skill profiles and configuration rules for major AI coding assistants and environments.
Claude / Cursor / Copilot / Gemini / OpenCode: Check the .agents/, .claude/, .cursor/, and .gemini/ directories for specialized SKILL.md instructions covering:
auth-security: Best practices and rules for authentication and key management.
mcp-app-architecture: Guidelines on extending modules and tools.
middleware-pipeline: How to inject custom interceptors and logging into request lifecycles.
ui-widgets: Instructions for building and embedding Next.js widgets into chat streams.
To connect this server to your local MCP client (e.g., Claude Desktop), add the following to your claude_desktop_config.json:
{
"mcpServers": {
"proofyield": {
"command": "node",
"args": ["/absolute/path/to/proofyield-mcp/dist/index.js"],
"env": {
"NODE_ENV": "production"
}
}
}
}Return only the exact unsigned transaction produced by the latest non-expired simulation. The server does not sign or submit it and never accepts caller-provided targets or calldata.
| Name | Required | Description | Default |
|---|---|---|---|
| planHash | Yes |
| Name | Required | Description |
|---|---|---|
| to | Yes | |
| data | Yes | |
| from | Yes | |
| kind | Yes | |
| value | Yes | |
| planId | Yes | |
| chainId | Yes | |
| warning | Yes | |
| gasLimit | No | |
| planHash | Yes | |
| expiresAt | Yes | |
| preparedAt | Yes | |
| description | Yes | |
| simulationHash | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) by detailing that the server does not sign/submit and rejects caller-provided data. No contradiction with 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?
Two concise sentences, front-loaded with the primary action, 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?
Given low complexity (1 param, no nested objects) and the presence of an output schema, the description fully covers the tool's behavior for an AI agent to decide and invoke correctly.
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?
Only parameter is planHash, but the description does not explain its purpose or format beyond the schema pattern. With 0% schema description coverage, the description should provide meaning, but it only says 'latest non-expired simulation' without linking to 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?
Clearly states the tool returns the exact unsigned transaction from the latest non-expired simulation. Distinguishes from sibling tools like plan_simulate by specifying output nature and constraints.
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?
Explicitly says the server does not sign or submit the transaction and never accepts caller-provided targets or calldata, implying it is for retrieval only after simulation. Could be more explicit about alternatives, but the context from sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the live transaction and receipt, prove that sender, target, calldata, value, chain, and postconditions match the prepared plan, and never report success without on-chain evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | ||
| planHash | Yes | ||
| transactionHash | Yes |
| Name | Required | Description |
|---|---|---|
| kind | Yes | |
| status | Yes | |
| chainId | Yes | |
| gasUsed | No | |
| planHash | Yes | |
| errorCode | No | |
| blockNumber | No | |
| errorMessage | No | |
| confirmations | Yes | |
| postConditions | Yes | |
| transactionHash | Yes | |
| observedTimestamp | Yes | |
| postConditionsPassed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context: it reads on-chain data, requires on-chain evidence before reporting success, and never reports success without evidence. This complements annotations (idempotent, non-destructive). However, the readOnlyHint=false annotation suggests potential state modification, which the description doesn't clarify, causing a minor inconsistency.
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 action and constraints.
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 verification tool with an output schema, but lacks mention of prerequisites or error conditions. Does not reference sibling tools or 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?
The description does not explain any of the three parameters (chainId, planHash, transactionHash) beyond vague mentions of 'chain', 'plan', and 'transaction'. With 0% schema coverage, the description fails to add meaning to 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 verifies a signed transaction against a plan using on-chain data, with specific details on what is proven (sender, target, etc.). It distinguishes itself from sibling tools like 'execution_prepare' and 'plan_simulate'.
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. It does not mention prerequisites (e.g., existing plan, signed transaction) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare a stored executed/planned decision with a fresh validated opportunity scan. It can recommend a new proposal but never moves funds automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| planHash | Yes | ||
| currentOpportunities | Yes |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| planHash | Yes | |
| triggers | Yes | |
| observedAt | Yes | |
| proposedFollowUp | Yes | |
| selectedOpportunityId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: 'never moves funds automatically' clarifies readOnlyHint. It explains the tool can recommend proposals but does not execute trades. This is valuable behavioral insight not fully covered by 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?
Two sentences, no fluff. First sentence states the core action; second adds a critical safety guarantee. Information is front-loaded and each 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?
Description covers core purpose and safety, but lacks prerequisite context (e.g., need a planHash from strategy_createPlan or opportunities from opportunities_scan). Output schema exists, so return format is not required. Adequate but not fully 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 0%. The description implicitly maps planHash to stored decision and currentOpportunities to fresh scan, but provides no details on formats, constraints, or how to obtain these inputs. Parameter names are somewhat descriptive but insufficient for correct invocation.
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 function: compare a stored decision with a fresh opportunity scan, and optionally recommend a proposal. The verb 'compare' and resource 'stored executed/planned decision' are specific. It distinguishes from siblings like opportunities_scan or plan_simulate.
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: use after a stored plan and fresh scan. It states what the tool does not do ('never moves funds'), which guides safe usage. However, it does not explicitly mention when not to use it or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query only configured allowlisted adapters for test-USDC opportunities. Live Aave rates are read on-chain; controlled vault rates are explicitly labeled simulated; DO_NOTHING is always included.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| assetId | Yes | ||
| walletAddress | Yes | ||
| allowedChainIds | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral details beyond annotations: it explains that live Aave rates are read on-chain, controlled vault rates are explicitly labeled simulated, and DO_NOTHING is always included. This complements the readOnlyHint and openWorldHint annotations without contradiction.
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 relatively concise with two sentences, but the second sentence is dense and could be better structured for readability. It front-loads the core purpose effectively.
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 4 parameters with no schema descriptions and an output schema, the description fails to explain the role of inputs like walletAddress and amount. Without parameter guidance, agents cannot use the tool correctly, making it incomplete.
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?
Despite 0% schema description coverage, the description provides no explanation for any of the four parameters (amount, assetId, walletAddress, allowedChainIds). Agents cannot infer what these inputs represent or how they affect the scan, leaving a critical gap.
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 allowlisted adapters for test-USDC opportunities, and the title 'Research approved yield opportunities' accurately reflects the purpose. It effectively distinguishes from sibling tools like strategy_createPlan or plan_simulate by focusing on research rather than planning or execution.
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 context on scope (test-USDC, adapters) and mentions DO_NOTHING inclusion, but lacks explicit guidance on when to use versus alternatives. It does not state prerequisites or when not to use, leaving agents to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revalidate a stored plan and trusted adapter against live chain state. If allowance is insufficient, safely simulate and return only an exact approval transaction; otherwise simulate the protocol action and expected postconditions.
| Name | Required | Description | Default |
|---|---|---|---|
| planHash | Yes |
| Name | Required | Description |
|---|---|---|
| planId | Yes | |
| status | Yes | |
| chainId | Yes | |
| success | Yes | |
| planHash | Yes | |
| errorCode | No | |
| expiresAt | Yes | |
| timestamp | Yes | |
| blockNumber | Yes | |
| errorMessage | No | |
| estimatedGas | Yes | |
| preConditions | Yes | |
| postConditions | Yes | |
| simulationHash | Yes | |
| nextTransaction | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses conditional logic (allowance insufficient vs. sufficient) but leaves ambiguity about actual state changes: 'simulate' may imply no mutation, yet readOnlyHint=false suggests otherwise. Key behavioral details are unclear.
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 with main action and conditional logic. No redundant or extraneous 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?
Does not explain output format, what 'exact approval transaction' entails, or how to use the result. With output schema present, some context is still needed for effective 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?
No description for the single parameter planHash despite 0% schema description coverage. The description adds no meaning beyond the schema's pattern constraint.
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 uses specific verbs ('revalidate', 'simulate') and identifies the resource ('plan', 'adapter'), clearly distinguishing it from sibling tools like strategy_createPlan or system_getStatus.
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 when-to-use or when-not-to-use guidance. Does not compare to siblings or provide context for selection, leaving the agent to infer usage from behavior alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read live native and configured test-USDC balances for a validated wallet on supported testnets. Returns per-chain failures without fabricating balances.
| Name | Required | Description | Default |
|---|---|---|---|
| chainIds | No | ||
| walletAddress | Yes | EVM wallet address to inspect |
| Name | Required | Description |
|---|---|---|
| chains | Yes | |
| snapshotHash | Yes | |
| walletAddress | Yes | |
| observedTimestamp | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it states 'Returns per-chain failures without fabricating balances', which is a key trait. This complements the readOnlyHint and openWorldHint annotations effectively.
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, front-loaded with the verb and purpose, and contains no extraneous words. 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?
Given the simple parameters, existing annotations, and available output schema, the description covers the essential behavior and return characteristics. A minor gap is the lack of output schema details, but since the schema exists, this is acceptable.
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 50% (walletAddress has description, chainIds does not). The description does not add meaning to parameters beyond the schema, merely referencing 'validated wallet' and 'supported testnets'. 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 specifies the verb 'Read', the resource 'live native and configured test-USDC balances for a validated wallet on supported testnets', and distinguishes the tool's scope from siblings by focusing on testnet portfolio snapshots. It's specific and 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 implies usage when checking testnet wallet balances, but does not explicitly contrast with sibling tools or specify when not to use it. The context, however, is clear enough to avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the complete validated Decision Receipt by receipt ID or plan hash. Receipts persist across restarts only when the optional local hackathon store is configured.
| Name | Required | Description | Default |
|---|---|---|---|
| idOrHash | Yes |
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| stage | Yes | |
| intent | Yes | |
| policy | Yes | |
| approval | No | |
| snapshot | Yes | |
| createdAt | Yes | |
| receiptId | Yes | |
| updatedAt | Yes | |
| policyHash | Yes | |
| simulation | No | |
| opportunities | Yes | |
| verifications | Yes | |
| walletAddress | Yes | |
| receiptVersion | Yes | |
| scoreBreakdown | Yes | |
| finalReceiptHash | Yes | |
| eligibleCandidates | Yes | |
| rejectedCandidates | Yes | |
| preparedTransaction | No | |
| selectedOpportunity | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds a non-obvious behavioral trait: receipts only persist across restarts when the optional local hackathon store is configured. This is valuable beyond the 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?
Two concise sentences with no extraneous content. The first sentence states the core function, the second adds a critical condition. Every sentence 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?
An output schema exists, so return values are not needed. However, the description lacks context on what a 'Decision Receipt' entails or how to obtain the ID/hash. The persistence caveat is helpful, but the tool concept remains somewhat vague.
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 0% description coverage for the single 'idOrHash' parameter. The description explains it can be either a receipt ID or a plan hash, adding meaning beyond the schema's type and length constraints. However, it does not specify format or example.
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 'Retrieve' and the resource 'complete validated Decision Receipt' with two identifier types (receipt ID or plan hash). It is specific and distinct from sibling tools which cover strategy, portfolio, opportunities, 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?
No explicit guidance on when to use this tool versus alternatives is provided. The usage is implied (when needing a receipt), but no context about selection criteria or exclusions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a server-produced wallet snapshot and opportunity set, apply deterministic hard gates before ranking, include the liquid baseline, and create a short-lived typed plan. Caller-provided addresses never become trusted execution targets.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| policy | No | ||
| snapshot | Yes | ||
| opportunities | Yes |
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| stage | Yes | |
| intent | Yes | |
| policy | Yes | |
| approval | No | |
| snapshot | Yes | |
| createdAt | Yes | |
| receiptId | Yes | |
| updatedAt | Yes | |
| policyHash | Yes | |
| simulation | No | |
| opportunities | Yes | |
| verifications | Yes | |
| walletAddress | Yes | |
| receiptVersion | Yes | |
| scoreBreakdown | Yes | |
| finalReceiptHash | Yes | |
| eligibleCandidates | Yes | |
| rejectedCandidates | Yes | |
| preparedTransaction | No | |
| selectedOpportunity | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false) indicate this is a write operation, and the description confirms 'create' implying mutation. The description adds a safety note: 'Caller-provided addresses never become trusted execution targets.' However, it does not disclose other behavioral traits like side effects on the system, rate limits, or authentication requirements. The description neither contradicts nor significantly extends beyond what annotations already imply.
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, front-loading the core process in the first sentence. The second sentence adds a security constraint without extraneous detail. It is concise but could be slightly tighter by removing the phrase 'server-produced' as it is implied.
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 the tool (4 parameters with deep nesting, output schema exists), the description provides a high-level process but lacks important context such as the role of the 'policy' parameter, prerequisites (e.g., that the snapshot must be server-produced), and what happens on validation failure. The output schema is present so return values are not needed, but the description still feels incomplete for an agent to fully understand the tool's operation.
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 0%, meaning no parameter descriptions exist in the schema. The tool description fails to compensate by explaining the meaning or usage of any parameters. For example, 'policy' is not mentioned at all, and 'snapshot' and 'opportunities' are only referenced generically. This leaves agents with insufficient understanding of how to construct valid inputs.
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: 'Validate a server-produced wallet snapshot and opportunity set, apply deterministic hard gates before ranking, include the liquid baseline, and create a short-lived typed plan.' It specifies the resource (snapshot and opportunities) and the outcome (typed plan). This distinguishes it from sibling tools like 'plan_simulate' or 'execution_prepare' which handle simulation or execution, not plan creation.
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 context ('create a short-lived typed plan' after validation) but does not explicitly state when to use this tool instead of alternatives like 'plan_simulate' or 'execution_prepare'. No when-not-to-use or prerequisite conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open the ProofYield treasury dashboard and report public configuration. The connected MCP host LLM is the reasoning brain; deterministic ProofYield code authorizes every financial action.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| brain | Yes | |
| phase | Yes | |
| tools | Yes | |
| version | Yes | |
| timestamp | Yes | |
| application | Yes | |
| architecture | Yes | |
| executionMode | Yes | |
| schemaVersion | Yes | |
| supportedChains | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context beyond annotations by explaining the architecture: the LLM is the reasoning brain and deterministic code authorizes every financial action. This clarifies the tool's non-destructive, informational nature.
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, front-loading the primary function and adding an architectural note in the second sentence. Every sentence contributes 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 no parameters, existing annotations, and an output schema, the description sufficiently covers the tool's purpose. The architectural context adds completeness. However, what 'public configuration' includes could be slightly more explicit.
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?
With zero parameters, schema coverage is 100%, so the description does not need to explain parameter semantics. The baseline for 0 parameters is 4, and the description adds no irrelevant parameter information.
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 opens the ProofYield treasury dashboard and reports public configuration. This specific verb-resource combination distinguishes it from sibling tools focused on strategy creation, receipts, snapshots, scanning, simulation, and execution.
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 its siblings. It does not mention prerequisites, context for invocation, or scenarios where this tool is preferred over others like monitor_check or receipt_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct financial action: plan creation, system status, receipt retrieval, portfolio snapshot, opportunity scanning, plan simulation, unsigned transaction preparation, execution verification, and post-execution monitoring. No two tools overlap in purpose.
All tools follow a consistent noun_verb pattern (e.g., strategy_createPlan, portfolio_getSnapshot, execution_prepare). The verb portion is uniformly a verb or verb phrase, and the noun prefix clearly identifies the domain area.
With 9 tools, the server covers the entire lifecycle of a yield strategy—from opportunity scanning and planning to simulation, preparation, verification, and monitoring—without unnecessary redundancy.
The tool set provides a complete workflow for testnet yield management: scanning opportunities, creating plans, simulating, preparing unsigned transactions, verifying on-chain execution, and monitoring outcomes. No obvious gaps exist for the intended domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Passive income opportunity scanner. Yield analysis and portfolio optimization for AI agents.
Crypto yield data for AI agents: lending, savings, staking, borrowing & stablecoin rates. 18 tools.
USDC treasury vaults, streaming payments, and DeFi yield for AI agents
Non-custodial DeFi tools for AI agents on Solana: swaps, perps, lending, staking, equities.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AshutoshVatsg/proofyield-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
