Forge Treasury

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

With no annotations, the description carries full burden. It clarifies that the tool builds calldata (not executes a transaction) and labels it advanced. However, it lacks details on error handling, safety, or whether the calldata is for a write operation.

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

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

Two sentences with no redundancy. The first sentence front-loads purpose, the second gives key prerequisite. 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?

Given no output schema, the description should clarify return value (e.g., raw calldata hex). It does not. Also, it could connect to sibling get_forge_rewards for workflow completeness. These gaps lower the score.

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

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

Input schema has 100% description coverage. The description adds context that proof comes from an API, slightly augmenting parameter meaning. Nonetheless, it does not significantly add beyond schema descriptions.

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

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

The description explicitly states the tool builds calldata to claim weekly $FORGE rewards, with a specific verb and resource. It distinguishes from siblings like get_forge_rewards (viewing) and deposit/withdraw (different actions).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions the prerequisite of a Merkle proof from the Forge rewards API, giving some context. However, it does not explicitly state when to use this tool vs alternatives, nor does it provide exclusions or when-not scenarios.

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 provided, but the description fully discloses return type (calldata), required approval, that it mints shares, strategy details (single leg, two legs, not live), and gas costs on mainnet.

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?

Five sentences, each containing essential information. Front-loaded with the main action; no wasted words or redundancy.

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

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

Despite no output schema, it explains the return format (calldata) and covers prerequisites, strategy options, and gas costs, making it self-contained for an agent.

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

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

Schema coverage is 100%, so baseline is 3. The description repeats schema explanations for 'profile' and 'amount' without adding new parameter-specific information; gas costs are behavioral, not parameter.

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

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

The description explicitly states the action ('Deposit USDC'), the target ('Forge Treasury vault on Base'), and the output ('Returns calldata'), clearly distinguishing it from sibling tools like 'withdraw' 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?

It specifies the prerequisite ('must approve USDC to the vault contract first'), notes that 'Aggressive is not live', and explains strategy options, but does not explicitly contrast with alternatives like 'simulate_deposit'.

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?

Despite no annotations, the description discloses 'Read-only, no transaction needed', clearly indicating no side effects. It lacks further details like authentication requirements or data freshness, but for a simple read operation, the disclosure is adequate.

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

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

The description is concise: two short sentences that front-load the core purpose and add a safety note. No extraneous information, 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 simple tool with one parameter and no output schema, the description covers purpose, safety, and output contents (shares and USDC value). It lacks explicit output structure (e.g., field names), but this is a minor gap 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?

Schema coverage is 100%, with the parameter described as 'Agent wallet address'. The description does not add new semantic details about the parameter, focusing instead on output. Baseline score of 3 is appropriate since the schema already provides sufficient meaning.

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', resource 'agent's Forge vault balance', and specifics 'shares held and equivalent USDC value'. This distinguishes it from sibling tools like get_current_apy or get_vault_stats, which focus on different aspects.

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 by stating 'Read-only, no transaction needed', suggesting it's safe for balance checks. However, it does not explicitly guide when to use this tool versus alternatives (e.g., when to use get_balance vs get_vault_stats) or provide when-not-to-use scenarios.

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 fully discloses behavioral traits: APY is a blended target (not a guarantee), Sepolia uses MockYieldAdapter, conservative vs balanced vs aggressive status, and gas estimates. This covers safety and behavior comprehensively.

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 four sentences, each adding important details (purpose, output format, profile notes, gas). It front-loads the main function. While efficient, it could be slightly more concise by combining some details. Well-structured overall.

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 (2 params, no output schema), the description covers constraints (profile not live), environment (Sepolia), output shape (JSON with metadata, allocation, disclaimer), and gas costs. It omits explicit error cases but is sufficiently complete for a query 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?

Input schema covers both parameters with descriptions. The tool description adds value by explaining the profile options in detail (e.g., 'Conservative deposits Core only...') and clarifying that agentAddress is optional. Since schema coverage is 100% and description enhances it, score is above baseline 3.

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

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

The description clearly states the tool returns the blended target APY for a Forge profile, including base USDC yield and FORGE boost, and specifies the output format. It distinguishes itself from sibling tools like deposit or withdraw, which are actions, not queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions interactive constraints like Sepolia using MockYieldAdapter and profile availability (conservative only for MVP, balanced/aggressive return NOT LIVE), and gas costs. However, it does not explicitly state when to use this tool versus alternatives or provide a when-not-to-use scenario. The context is clear but lacks explicit 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 present, so the description carries the full burden. It mentions the source (weekly emissions distributor) and that it's a get operation, but does not disclose any behavioral traits such as permissions, state changes, or rate limits. The description is minimal but not misleading.

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

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

The description is a single sentence with a brief tag, front-loaded with the purpose. Every word earns its place; no unnecessary 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 simple tool with one parameter and no output schema, the description adequately explains the purpose and parameter meaning. However, it lacks any mention of the return format or behavior, which would be helpful given no output schema.

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

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

Schema description coverage is 100% with the parameter 'agentAddress' described as 'Agent wallet address'. The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool gets the claimable $FORGE reward balance for an agent from the weekly emissions distributor. It uses a specific verb and resource, and distinguishes from siblings like claim_forge and 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 includes an '[Advanced]' tag, implying it may be for advanced users, but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or explicit context are provided.

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 full burden. It states 'Read-only,' indicating safety and non-destructive behavior, but lacks details on authorization, rate limits, or error handling. Adequate but minimal.

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, front-loaded sentence with no wasted words. Perfectly concise for a simple read tool.

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

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

Given no parameters and no output schema, the description covers the tool's purpose and safety. Minor missing context about the return format or what 'conservative profile' means, but overall sufficient.

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

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

No parameters exist, and schema coverage is 100% vacuous. Baseline for zero parameters is 4, and the description adds no parameter info but is not needed.

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

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

The description clearly states it retrieves live Forge vault TVL on Base, using specific verb and resource. It distinguishes itself from sibling tools like get_balance and get_current_apy, though not explicitly.

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 reading vault stats but provides no explicit guidance on when to use this tool versus alternatives like get_balance or get_forge_rewards. No exclusions or context provided.

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?

Without annotations, the description clearly implies a read-only operation through the verb 'List'. It also provides additional context about mainnet status for vaults and strategies. However, it does not explicitly state that the tool is read-only or that no state changes occur, which is acceptable for this straightforward listing task.

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

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

The description is extremely concise—only two sentences—with the first sentence stating the core purpose and the second adding contextual detail about mainnet. Every word serves a purpose, with no redundancy.

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

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

Given there is no output schema, the description adequately explains what the tool returns (vaults and strategies with mainnet status). It does not specify data format, pagination, or other details, but for a simple list tool, this is sufficient. It covers the essential information an agent needs.

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 schema coverage is 100%, so the description does not need to elaborate on parameters. It adds no extra parameter information, which is appropriate given the absence of 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 lists Forge vaults (Core/Middle/Infra) and agent strategies (Conservative/Balanced/Aggressive), with specific mainnet availability. It uses a specific verb ('List') and directly distinguishes itself from sibling tools that perform actions (e.g., deposit, withdraw) or query other data (e.g., get_balance, 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 does not provide any guidance on when to use this tool versus its siblings. For example, it does not clarify how list_profiles differs from get_vault_stats or when one should be preferred. No when-not-to-use conditions or alternative tool mentions are given.

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?

Discloses that APY is a blended target and not a guarantee, and mentions Sepolia uses MockYieldAdapter. But misses describing output format or behavior for invalid profiles beyond what's in param description. Without annotations, more detail would be beneficial.

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, each essential: function, usage hint, and caveats. No redundant information; front-loads the core purpose.

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?

Lacks description of the return value structure (e.g., a breakdown by period). While parameters are well-covered, the lack of output schema means the description should clarify what the agent receives. Presently incomplete for a reasoning tool.

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

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

Schema coverage is 100% with param descriptions. The tool description adds value by specifying simulation periods (30, 90, 365 days) not present in the schema, enhancing understanding beyond the input schema alone.

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

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

The description clearly states it projects expected returns for a USDC deposit over 30, 90, and 365 days using a blended target APY. It distinguishes from sibling tools (deposit, withdraw, get_balance) by being a simulation for reasoning before depositing.

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 'Use for agent reasoning before depositing,' providing clear when-to-use guidance. However, it lacks explicit when-not-to-use or alternative tool references, though the sibling list implies alternatives.

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 must fully cover behavioral traits. It discloses the performance fee and that it returns calldata, but lacks details on potential reverts, authorization, or side effects.

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

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

Two concise sentences front-load the purpose and key condition. 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?

No output schema is provided, and the description only states that it returns calldata. Given the fee and high-water-mark complexity, more detail on return format or failure modes would improve completeness.

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

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

Schema coverage is 100%, and the description adds value by specifying that 'shares' should be a raw uint256 string from get_balance, which is helpful context beyond the schema definition.

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

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

Description clearly states the action (withdraw), resource (Forge Treasury vault), and method (redeem shares). It also specifies that it returns calldata, distinguishing it from siblings 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 mentions a performance fee condition but does not explicitly guide when to use this tool over alternatives. No 'when not to use' or direct sibling differentiation is provided.

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