Forge Treasury

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

The description adds some behavioral context by disclosing that proof is fetched externally when omitted. However, without annotations, it does not clarify whether this operation is read-only, what the calldata will contain, or what the return value looks like.

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, immediately states purpose, no filler. Ideal length.

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 no annotations. The description explains the purpose and proof fetching but omits the return format, side effects, or how to use the calldata, which is critical for an '[Advanced]' tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the optional proof behavior ('fetched from forgetreasury.com/rewards when omitted'), going beyond the schema's simple description.

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

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

The description clearly states a specific action ('Build calldata to claim weekly $FORGE rewards') and distinguishes itself from sibling tools like get_forge_rewards by specifying it constructs calldata rather than merely retrieving reward 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 explicit guidance on when to use this tool vs alternatives. The '[Advanced]' prefix and note about proof fetching provide minimal context, but there is no when/when-not statement or mention of sibling tools.

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

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

With no annotations provided, the description carries the full burden and discloses key behaviors: the tool returns calldata to be signed (not an on-chain execution), requires prior USDC approval, mints fUSDC shares, and details the leg structure for conservative/balanced profiles. It also includes gas costs, providing valuable operational information.

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?

Each sentence is purposeful: the opening sentence states the core action, followed by the sign-return nature, approval prerequisite, shares minted, profile behavior, and gas costs. It is structured logically and front-loaded, with no fluff.

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, the description covers the return value ('Returns calldata'), prerequisites (approval), behavior (shares, profile legs), and limitations (aggressive not live, gas costs). It supplies all the contextual information an agent needs to safely invoke the tool.

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

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

The schema already covers all parameters with descriptions, but the description adds extra meaning: it explains the profile enum values in more detail (Conservative=Core only, Balanced=50/50 Core/Middle, Aggressive not live) and mentions gas costs tied to the profile choice. This goes beyond the schema's baseline, so a 4 is warranted.

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 ('Deposit USDC into a Forge Treasury vault on Base') and adds specifics (returns calldata, mints fUSDC shares) that distinguish it from siblings like claim_forge, withdraw, and simulate_deposit. It immediately and unambiguously names the target resource.

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: the agent must approve USDC first, and it warns that 'aggressive' is not live. However, it does not explicitly name alternatives (e.g., simulate_deposit for preview) or state when not to use the tool, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden of disclosure. It explicitly states the tool is read-only and requires no transaction, which is critical behavioral context. It also discloses what the tool returns (shares and USDC value), giving the agent a clear expectation of the output. While it doesn't mention edge cases like non-existent agents, it covers the essential behavior for a simple balance read.

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

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

The description is two sentences: the first states the purpose and output, the second adds a concise behavioral note. Every sentence earns its place with no redundancy or fluff, making it highly efficient for an agent to process.

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

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

Given the tool's simplicity (one parameter, no output schema), the description is fully adequate. It explains the purpose, the return value, and the read-only nature. No output schema is present, but the description's mention of 'shares held and equivalent USDC value' compensates for that. The sibling context further clarifies its role among balance-related operations.

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 schema already provides 100% coverage for the single parameter 'agentAddress' with a description 'Agent wallet address'. The tool description adds context about Forge vault balance but does not introduce new parameter semantics. This meets the baseline for high schema coverage.

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

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

The description clearly states the verb 'Get' and the resource 'agent's Forge vault balance', specifying the exact output (shares and USDC value). It distinguishes itself from sibling tools like get_current_apy, get_forge_rewards, and get_vault_stats by focusing on the agent's balance rather than APY, rewards, or vault-level statistics.

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 phrase 'Read-only, no transaction needed' implies this is a query tool, useful when the agent needs to check a balance without performing a transaction. While it does not explicitly list alternatives or exclusions, it provides clear context that this is a non-mutative operation, which helps differentiate it from deposit/withdraw tools.

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

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

With no annotations, the description carries the full burden and excels. It discloses the return format (structured JSON with metadata and disclaimer), the non-guarantee nature of APY, environment-specific behavior (MockYieldAdapter), profile-specific allocation details (Core only, 50/50 legs), and gas estimates. This is rich behavioral context beyond a simple 'getter'.

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 dense but every sentence adds value, covering format, network nuances, profile states, and gas. It is somewhat long, but the structure is logical and front-loaded with the core purpose. Slightly trimmed wording could make it more concise without losing 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?

Given the complexity of profiles, network differences, and gas costs, and no output schema, the description provides substantial context: it explains what the return value looks like, which profiles are live, and environmental caveats. This is sufficient for an agent to understand the tool's behavior in common scenarios.

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 per-parameter descriptions, meeting the baseline of 3. The description adds further meaning by explaining profile behavior (aggressive not live) and the purpose of agentAddress for personalized boost, which goes beyond the schema's bare description.

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

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

The description opens with a clear verb and resource: 'Get the blended target APY for a Forge profile'. It also enumerates specific outputs (base USDC yield + FORGE boost) and provides a format example, making it unmistakably distinct from sibling tools like get_forge_rewards or get_vault_stats.

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?

Usage context is implied through details like network differences (Sepolia vs mainnet) and profile availability, but the description never explicitly states when to choose this tool over alternatives or when not to use it. The sibling tool 'get_forge_rewards' exists, and a direct comparison would improve guidance.

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

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

No annotations are provided, so the description carries the burden. It states it 'gets' a balance, implying a read-only operation, and names the source. However, it does not explicitly state that it doesn't claim rewards or describe any side effects or permissions.

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 of about 12 words, front-loaded with the [Advanced] tag and then the action. No unnecessary verbiage.

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, the description should explain return values, units, or error behavior, but it only states the action. The tool may return a balance, but the agent would not know the format (e.g., wei vs token) or what happens on invalid addresses.

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 schema documents agentAddress as 'Agent wallet address' with 100% coverage. The description adds no additional meaning to the parameter beyond what the schema provides, so baseline 3 applies.

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 identifies the resource ('claimable $FORGE reward balance') and source ('weekly emissions distributor'). This clearly distinguishes it from siblings like claim_forge or get_balance.

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 checking claimable rewards, but does not explicitly state when to use it over alternatives or mention exclusions. No reference to sibling tools is made.

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

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

With no annotations provided, the description explicitly states 'Read-only' and 'live' which are key behavioral traits. The 'conservative profile in MVP' caveat adds methodological context, though it is vague. No permissions, rate limits, or error behavior are mentioned.

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 14-word sentence that front-loads the core action and adds two brief qualifiers. No wasted words.

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

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

For a zero-parameter, no-output-schema read tool, the description covers the primary action and network scope but does not specify TVL denomination or return type. Given the simplicity, it is adequately complete.

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

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

The tool has zero parameters and the schema is empty, so no parameter documentation is needed. The description correctly omits parameter details.

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 ('Forge vault TVL') along with network scope ('on Base'), clearly distinguishing it from sibling mutation tools like deposit/withdraw and other read tools like get_current_apy.

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 it is a safe read-only query but provides no explicit guidance on when to use it versus sibling tools like get_balance or get_current_apy. There is no mention of alternatives or exclusion criteria.

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

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

No annotations are provided, so the description carries the full burden. It clearly describes the tool's behavior (listing vaults and strategies) and adds valuable context about mainnet live status. It does not explicitly state read-only, but 'List' implies no side effects. The mainnet note goes beyond a simple listing statement.

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 primary action and scope, followed by a useful note. Every word earns its place with no redundancy or fluff.

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 parameterless, simple listing tool, the description fully captures what the tool does and adds operational context (mainnet availability). No output schema exists, but the return is a list, and the description sufficiently names all categories. It is complete given the tool's simplicity.

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

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

The tool has zero parameters, and the schema is empty. The description explains what the tool produces, which is the primary semantic content. With 0 params, the baseline is 4, and the description meets that by clarifying the content being listed.

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 the specific verb 'List' and clearly names the resources: Forge vaults (Core/Middle/Infra) and agent strategies (Conservative/Balanced/Aggressive). It distinguishes this tool from sibling tools, which are all actions (deposit, withdraw, claim) or specific queries (get_balance, get_current_apy), whereas this is the only listing 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?

It provides clear context by listing what the tool returns and gives a mainnet-specific availability note, which helps users decide when to use it (e.g., to see which vaults/strategies are live). It does not explicitly state exclusions or alternatives, but the purpose is obvious compared to sibling tools.

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

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

No annotations exist, so the description carries the burden. It usefully discloses that APY is a blended target, not a guarantee, and that Sepolia uses MockYieldAdapter. However, it does not describe the output format or behavior for unsupported profiles (though the schema covers profile limitations).

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?

Three concise sentences, with the core purpose front-loaded. Every sentence adds value: what it does, when to use, and a caveat. No redundant phrasing.

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

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

Given the simplicity of the tool (2 parameters, no output schema), the description covers purpose, usage, and a key assumption (blended APY) plus testnet behavior. It could mention return value structure but is otherwise complete for the complexity level.

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 little beyond the schema: it mentions 'USDC deposit' but does not explain parameter formats or constraints beyond what the schema already provides. The example '10000' is 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 uses a specific verb ('Project expected returns') tied to a resource (USDC deposit) and time horizons (30, 90, 365 days). It distinguishes from siblings like 'deposit' or 'get_current_apy' by focusing on projection rather than execution or current rates.

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 states 'Use for agent reasoning before depositing', giving clear when-to-use guidance. It does not name alternative tools but the context is clear. The mention of Sepolia MockYieldAdapter also sets expectations for test environments.

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

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

With no annotations, the description carries the full burden. It discloses a critical behavioral trait: the tool returns calldata rather than executing a transaction. It also warns about the 15% performance fee, adding useful context. It does not mention prerequisites like approvals or share balance, but the reference to get_balance helps.

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, front-loaded with the verb and resource. Every phrase earns its place, including the high water mark fee warning, which is essential context for the agent.

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 or annotations, so the description must cover return behavior and caveats. It does, noting the calldata output and fee. It does not explain how to use the calldata or high water mark, but for a 2-parameter tool, it is reasonably complete.

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

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

The schema already provides full descriptions for both shares and agentAddress (100% coverage), so the baseline is 3. The description's mention of redeeming shares and the calldata return aligns with the parameters but does not add new semantic nuance 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 clearly states the action (Withdraw), the specific resource (Forge Treasury vault), and the mechanism (redeeming shares). It also implies the output type (calldata), which differentiates it from sibling tools like deposit or 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 description implies the tool is for withdrawing shares but gives no explicit guidance on when to use it versus alternatives like claim_forge or deposit. No exclusions or conditions are mentioned, though the purpose is clear enough to infer usage.

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