Non-custodial USDC yield vaults on Base mainnet with 9 MCP tools for AI agent treasury.
Scored across 9 tools
Each tool targets a distinct action or read operation, and descriptions clarify the boundaries. The only possible confusion is between `get_forge_rewards` and `claim_forge`, but the former reads the claimable balance while the latter builds claim calldata.
The naming mostly follows a clear verb_noun snake_case pattern like `get_balance`, `get_current_apy`, and `simulate_deposit`. Minor deviations are `deposit` and `withdraw`, which omit the object, but they are still predictable and consistent with each other.
Nine tools is a well-scoped size for a DeFi treasury server. Each tool covers a meaningful user action or read path without redundancy or bloat.
The core lifecycle is covered: deposit, withdraw, balance, APY, rewards, profile listing, and simulation. The only notable gap is the required USDC approval step, but that is explicitly left to the agent wallet rather than the server.
[Advanced] Build calldata to claim weekly $FORGE rewards. Proof is fetched from forgetreasury.com/rewards when omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| epoch | Yes | Reward epoch number | |
| proof | No | Merkle proof array (bytes32 hex strings). Optional — auto-fetched from manifest. | |
| amount | No | FORGE amount to claim (raw wei string). Optional if manifest has allocation. | |
| agentAddress | Yes | Agent wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the external proof-fetching behavior when the proof is omitted, which is valuable, but it does not state whether calldata building is side-effect-free (no transaction submission), what happens if the fetch fails, or any prerequisites. Partial disclosure only.
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 with no fluff: the first establishes the core purpose, the second adds a key behavioral detail. The 'Advanced' prefix is minimal and does not detract from 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?
For an advanced tool with no annotations and no output schema, the description is too thin. It omits that only calldata is built (not submitted), provides no return-value format, and no failure modes or prerequisites. While schema covers parameters, the behavioral and usage context remains incomplete for an agent to invoke it confidently.
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 meaning by specifying the proof fallback source (forgetreasury.com/rewards), which is more concrete than the schema's 'auto-fetched from manifest'. This clarifies behavior around optional parameters and raises it above baseline.
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 states a specific verb ('Build calldata') and a distinct resource ('claim weekly $FORGE rewards'), which clearly separates it from siblings like deposit, withdraw, and get_forge_rewards. The 'Advanced' tag and proof-fetch note add useful context without ambiguity.
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 action verb implies the tool is for claiming rewards, but there is no explicit statement of when to use it versus alternatives, nor any exclusions or routing to sibling tools. It does not clarify that get_forge_rewards is for checking rewards rather than claiming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deposit USDC into a Forge Treasury vault on Base. Returns calldata for the agent wallet to sign. The agent must approve USDC to the vault contract first. Mints yield-bearing fUSDC shares. Conservative deposits Core only (single leg). Balanced returns two legs (50% Core / 50% Middle). Aggressive is not live. Gas: Core 4M, Middle 6M+ on mainnet.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | USDC amount to deposit (human-readable, e.g. "1000" for 1000 USDC) | |
| profile | No | Strategy id (legacy "profile" name). conservative → Core vault. balanced → Core + Middle legs (50/50). aggressive → STRATEGY_NOT_LIVE. Defaults to "conservative". | |
| agentAddress | Yes | Agent wallet address that will receive vault shares |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It transparently states that the tool returns calldata rather than executing the deposit, requires prior approval, mints fUSDC shares, maps strategies to legs, notes that Aggressive is not live, and gives gas estimates.
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?
Every sentence contributes a distinct, useful fact: the target, the return type, the prerequisite, the share minting behavior, strategy routing, live status, and gas costs. The purpose is front-loaded and the description stays compact despite the rich 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 tool with no output schema and no annotations, the description covers all call-critical details: what the tool does, what must happen first, how optional parameters behave, what the result is, and rough resource costs. No significant information needed for correct invocation is missing.
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 baseline is 3. The description adds substantive meaning beyond the schema by explaining profile semantics: conservative maps to Core only, balanced maps to 50/50 Core/Middle, and aggressive is not live. It also enriches the agentAddress context by clarifying the wallet receives vault shares.
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 a specific verb and resource: 'Deposit USDC into a Forge Treasury vault on Base.' It also distinguishes itself from siblings by noting it returns signable calldata and by covering strategy profiles, so it is clearly not a read, claim, or withdrawal tool.
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 gives clear usage prerequisites ('The agent must approve USDC to the vault contract first') and explains when different strategy profiles apply. It does not explicitly name sibling alternatives or say when not to use the tool, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an agent's Forge vault balance: shares held and equivalent USDC value. Read-only, no transaction needed.
| Name | Required | Description | Default |
|---|---|---|---|
| agentAddress | Yes | Agent wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states 'Read-only, no transaction needed,' which is a key behavioral trait for a query tool. It doesn't mention error handling or rate limits, but for a simple balance check, this is sufficient 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?
Two sentences with no filler, the purpose is front-loaded, and the read-only note is immediately stated. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with one parameter and no output schema, the description is complete. It states what the tool returns (shares and USDC value) and its read-only nature. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'agentAddress' parameter. The description adds no additional parameter details, so the baseline of 3 applies as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('agent's Forge vault balance') and specifies the details (shares and USDC value). It clearly differentiates from siblings like deposit, withdraw, and get_vault_stats by focusing on a per-agent balance check.
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 use for checking a balance and explicitly states it's read-only with no transaction needed. However, it doesn't mention when to prefer this over siblings like get_vault_stats or get_current_apy, or provide any exclusions. The usage context is clear but not explicitly contrasted with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the blended target APY for a Forge profile: base USDC yield + FORGE boost. Returns structured JSON with profile metadata, target allocation by adapter, and a disclaimer. Format: "X% USDC + Y% FORGE (blended target)". APY is a blended target across conservative allocation weights; not a guarantee. Sepolia uses MockYieldAdapter until mainnet adapters are live. Conservative deposits Core only (single leg). Balanced returns two legs (50% Core / 50% Middle). Aggressive is not live. Gas: Core 4M, Middle 6M+ on mainnet.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | No | Risk profile. MVP: "conservative" only. balanced/aggressive return PROFILE_NOT_LIVE. Defaults to "conservative". | |
| agentAddress | No | Optional agent address for personalized boost calculation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does this thoroughly: APY is a blended target, not a guarantee; Sepolia uses MockYieldAdapter; conservative and balanced have different allocation legs; aggressive is not live; gas costs are given. This goes well beyond the schema and gives an agent an accurate model of what will happen.
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 information-dense and front-loaded with the core purpose. Each sentence adds value: return format, disclaimer, environment behavior, profile behavior, and gas estimates. It is somewhat long but not redundant; every detail earns its place, making it appropriately sized for a tool with this much nuance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explains the return format ('structured JSON with profile metadata, target allocation by adapter, and a disclaimer') and the exact APY display format. It covers caveats, environment differences, profile availability, and gas. An agent has all the information needed to call this tool correctly and interpret its result.
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 baseline is 3. The description adds meaningful context for the profile parameter by explaining the allocation legs (Core only for conservative, 50% Core / 50% Middle for balanced) and noting aggressive is not live. It also clarifies the FORGE boost component related to agentAddress, adding value beyond the enum and field names.
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 opens with a specific verb and resource: 'Get the blended target APY for a Forge profile: base USDC yield + FORGE boost.' It clearly distinguishes itself from sibling tools (deposit, withdraw, claim_forge) as a read-only informational endpoint. It also states the output shape, removing ambiguity about what the tool returns.
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 gives clear context on when this tool is relevant (querying APY for a Forge profile) and which environments are live (Sepolia vs mainnet). It implicitly tells the agent that aggressive is not live and that only conservative is MVP, but it does not explicitly name alternatives or say 'use this instead of X.' This is clear context without formal exclusions, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Advanced] Get claimable $FORGE reward balance for an agent from the weekly emissions distributor.
| Name | Required | Description | Default |
|---|---|---|---|
| agentAddress | Yes | Agent wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' a balance, implying a read operation, but does not explicitly confirm side-effect-free behavior, mention authentication, rate limits, or what happens when the agent has no claimable rewards. The reference to 'weekly emissions distributor' adds source context but leaves 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?
The description is a single, compact sentence that is front-loaded with the core action and resource. Every word contributes to understanding. The '[Advanced]' prefix is a minor stylistic addition that does not waste space. Efficiency is ideal.
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 tool with only one parameter, no output schema, and no annotations, the description is minimally sufficient but lacks context about the return value (does it return a number? a formatted string?), whether it includes pending rewards, or any prerequisites. It does not explicitly state that this is a read-only call, which is important given the mutation siblings present. Thus it is adequate but not 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?
Schema coverage is 100% with a clear description for agentAddress ('Agent wallet address'). The main description adds no additional meaning to the parameter beyond what the schema already provides, but since coverage is high, the baseline of 3 is appropriate. No extra nuance like format or expectations is conveyed.
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 'claimable $FORGE reward balance', and the source 'weekly emissions distributor'. It differentiates from siblings like get_balance (likely general balance) and claim_forge (action) by specifying 'claimable' and the distributor context. An agent can immediately understand the tool's purpose and how it differs from similar tools.
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 explicit guidance on when to use this tool versus alternatives like claim_forge or get_balance. It neither states conditions for selection nor mentions exclusions. The '[Advanced]' prefix hints at intended audience but gives no operational context. An agent would have to infer usage from the sibling names and the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get live Forge vault TVL on Base (conservative profile in MVP). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Read-only' and 'live', which conveys safety and freshness. With no annotations provided, the description carries the burden, and it does disclose the read-only nature and the conservative profile limitation. It doesn't mention rate limits, caching, or what 'conservative' means exactly.
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 short sentence with no filler. The key facts—live, Forge vault TVL, Base, conservative profile, read-only—are all front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description is mostly sufficient. However, there is no output schema and no mention of return format or units (e.g., USD, wei), and 'conservative profile' is vague. An agent might call it correctly but not know how to interpret the result.
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?
There are zero parameters, so the schema is trivially complete. The description adds context about what the returned stat represents (live TVL on Base, conservative profile), which is useful despite no params.
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?
States a specific verb ('Get') and resource ('live Forge vault TVL on Base'), and notes the conservative profile in MVP. It is distinguishable from siblings like get_current_apy and get_balance, though it doesn't explicitly name them.
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?
Implies usage as a read-only stats query, and the 'conservative profile in MVP' hints at a scope limitation. However, it doesn't explicitly say when to use this over get_current_apy or get_balance, nor 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.
List Forge vaults (Core/Middle/Infra) and agent strategies (Conservative/Balanced/Aggressive). Mainnet: Core and Middle vaults live; conservative and balanced strategies live.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. The verb 'List' clearly implies a non-mutating read operation, and the description adds useful behavioral context about which vaults and strategies are live on mainnet. This goes beyond a bare name and does not hide any surprising 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?
Two compact sentences with no filler. The first sentence delivers the core listing scope, and the second adds mainnet-specific availability context. Every word contributes meaningful information.
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 zero-parameter listing tool, the description adequately conveys what is returned conceptually and adds important environment-specific status. There is no output schema, but the return content is described well enough for an agent to invoke the tool successfully; minor details like response format or testnet behavior are not essential here.
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 tool has zero parameters, so the baseline is 4. The description correctly adds no parameter-specific semantics because there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies two distinct resource types with their explicit categories: Forge vaults (Core/Middle/Infra) and agent strategies (Conservative/Balanced/Aggressive). This makes the tool's purpose immediately clear and distinguishes it from the action-oriented sibling tools like deposit, withdraw, and claim_forge.
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 context is clear: use this tool when you need to know available vaults or strategy profiles, with mainnet-specific liveness information provided. It does not explicitly name alternatives or exclusion conditions, but none of the sibling tools serve the same listing purpose, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Project expected returns for a USDC deposit over 30, 90, and 365 days using the blended target APY. Use for agent reasoning before depositing. APY is a blended target across conservative allocation weights; not a guarantee. Sepolia uses MockYieldAdapter until mainnet adapters are live.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | USDC amount to simulate (e.g. "10000") | |
| profile | No | Risk profile to simulate. MVP: "conservative" only. Defaults to "conservative". balanced/aggressive return PROFILE_NOT_LIVE. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and it delivers meaningful disclosures: APY is not a guarantee, it is a blended target across conservative weights, and Sepolia uses MockYieldAdapter. 'Simulate' plus 'before depositing' also implies this is a non-mutating analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose and stays compact. There is minor repetition of 'blended target APY,' but every sentence adds either usage context, a trust caveat, or an environment caveat.
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 two-parameter simulation tool with full schema coverage, the description covers purpose, usage timing, caveats, and testnet behavior. It does not describe return value format, but the absence of an output schema makes that a minor gap rather than a blocking one.
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 of 3 applies. The description does not add much parameter-level detail beyond the schema, though it reinforces that the calculation is based on blended target APY and conservative allocations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Project expected returns for a USDC deposit over 30, 90, and 365 days.' It also distinguishes the tool from the deposit sibling by framing it as a pre-deposit reasoning step, so an agent can tell it apart from actual deposit or APY-lookup tools.
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?
'Use for agent reasoning before depositing' clearly states when the tool should be called. It does not explicitly name alternative tools or say when not to use it, but the pre-deposit context is enough to avoid obvious misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Withdraw from the Forge Treasury vault by redeeming shares. Returns calldata for the agent wallet. A 15% performance fee may apply on profits above the high water mark.
| Name | Required | Description | Default |
|---|---|---|---|
| shares | Yes | Vault share amount to redeem (raw uint256 string from get_balance) | |
| agentAddress | Yes | Agent wallet address (owner of shares) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool 'Returns calldata for the agent wallet' (indicating it does not execute the transaction itself) and mentions a 15% performance fee. However, it does not state whether this is a read-only operation (constructing calldata) or has side effects, nor does it mention any permission requirements or failure modes. It provides some behavioral context but leaves 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?
The description is three sentences with zero filler. The first sentence states the core purpose, the second clarifies the return type (calldata), and the third adds the fee caveat. It is front-loaded with the most critical information and 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?
For a two-parameter tool with no output schema and no annotations, the description is quite complete. It explains the action, the return format, and the fee policy. The only notable gap is the lack of explicit usage guidance (when to use vs. alternatives) and any note about potential side effects, but given the tool's simplicity and the clear 'returns calldata' statement, it covers most of what an agent needs to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptive comments for both parameters ('shares' as a raw uint256 string from get_balance, and 'agentAddress' as the owner). The description does not add any additional parameter-specific meaning beyond what the schema already provides. Per the calibration rules, with high schema coverage, the baseline is 3, and the description does not exceed that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Withdraw from the Forge Treasury vault by redeeming shares' – a specific verb and resource. It further clarifies the output ('Returns calldata for the agent wallet'), which distinguishes it from siblings like deposit or claim_forge. The purpose is unambiguous and the tool is easily differentiated from its siblings.
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?
There is no explicit guidance on when to use this tool versus alternatives. The description implies usage (redeeming shares) but does not mention conditions, prerequisites, or mention any alternative tools. For example, it does not say 'use deposit to add shares' or 'use claim_forge for rewards'. This leaves the agent without clear direction on tool selection.
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.
claim_forge3 fields changedInput schema / properties / amount / descriptionPrevious value: -"FORGE amount to claim (raw wei string)"New value: +"FORGE amount to claim (raw wei string). Optional if manifest has allocation."Input schema / properties / proof / descriptionPrevious value: -"Merkle proof array (bytes32 hex strings)"New value: +"Merkle proof array (bytes32 hex strings). Optional — auto-fetched from manifest."Input schema / requiredPrevious value: -[
- "epoch",
- "agentAddress",
- "amount",
- "proof"
-]New value: +[
+ "epoch",
+ "agentAddress"
+]claim_forgedepositget_balanceget_current_apyget_forge_rewardsget_vault_statslist_profilessimulate_depositwithdrawUSDC treasury vaults, streaming payments, and DeFi yield for AI agents
Risk regime + treasury for AI agents on Base: free regime reads, signed attestations, idle USDC.
DeFi MCP fleet: oracle, security audit, treasury yield, QA attestation, and compute tools on Base.
Policy-gated MCP treasury for AI agents — x402 subscribe, 50+ tools, multi-chain.
Add one secure layer between your agents and this server.