aave-mcp

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 successfully identifies the operation as a write function, discloses potential access control restrictions requiring specific permissions, and notes the return type (address). It lacks details on revert conditions or gas implications, but covers critical safety characteristics.

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?

Four sentences efficiently convey: (1) the function called, (2) write classification and access risk, (3) prerequisite action, and (4) return value. No redundant words or filler content; every sentence provides essential information for safe invocation.

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

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

Given the absence of an output schema, the description compensates by stating 'Returns address.' It adequately covers the necessary context for a single-function contract call: purpose, mutability, authorization requirements, and return value. Missing minor details like error scenarios, but sufficient for correct usage.

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 contains zero parameters. According to evaluation criteria, 0 parameters establishes a baseline score of 4. The description appropriately does not invent parameter semantics where none exist.

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 the tool 'Calls admin()' and 'Returns address', clearly identifying the specific contract function and return type. The 'Write function' classification distinguishes its state-changing nature, though it could further clarify what 'admin' represents (e.g., proxy administrator address) to distinguish from sibling upgrade functions.

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 warns about access control restrictions (e.g., onlyOwner) and instructs users to 'Check contract source for modifier requirements before calling.' While it doesn't explicitly contrast usage with sibling tools like upgradeTo, the prerequisite guidance provides clear safety context for invocation.

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 carry full behavioral burden. While it discloses access control risks and return type, it fundamentally misclassifies the operation as a 'Write function' when it likely performs a read (querying the implementation address). This misclassification could lead an agent to incorrectly treat this as state-modifying.

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 compact at four sentences. The opening 'Calls implementation()' is filler, but the remaining content efficiently conveys access control warnings and return value without 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?

Without an output schema, the description compensates by stating 'Returns address.' It addresses access control but omits context about what 'implementation' refers to (the logic contract address in an upgradeable proxy pattern) and fails to correct the mutability misclassification.

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 contains zero parameters. With no parameters requiring semantic clarification, the baseline score applies. The description correctly implies no arguments are needed beyond the implicit contract interaction.

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

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

The description states it returns an address and mentions access control, but begins with the tautology 'Calls implementation()' which restates the tool name. More critically, it incorrectly labels the tool as a 'Write function' when implementation() is typically a view/read operation in proxy contracts, confusing the tool's purpose.

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

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

Provides prerequisite guidance ('Check contract source for modifier requirements before calling') and warns about access control restrictions (e.g., onlyOwner). However, it fails to distinguish when to use this getter versus sibling mutation tools like upgradeTo or upgradeToAndCall.

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 effectively carries the full burden by disclosing: write function nature, ETH requirement, potential access control restrictions (onlyOwner), and absence of return value. It successfully communicates the critical safety considerations for this state-changing operation.

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

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

Four efficient sentences with no filler. Critical information (ETH requirement, write nature, access control risks) is front-loaded. The signature mention in sentence one is slightly redundant but acceptable for clarity.

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

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

Given the proxy pattern context (evident from sibling tools) and absence of output schema, the description adequately covers the essential behavioral traits: ETH requirement, access control warnings, and return value status. It provides sufficient context for safe invocation of this initialization function.

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

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

The input schema has 100% description coverage (address and hex-encoded bytes), establishing a baseline of 3. The description mentions parameters in the function signature but does not add semantic context beyond what the schema already provides (e.g., that _logic is the implementation contract address).

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 identifies this as an initialization function with specific parameters (_logic address and _data bytes) and distinguishes it by noting the ETH value requirement. While 'Calls initialize...' slightly restates the tool name, the inclusion of parameter types and ETH requirement adds necessary specificity.

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 important prerequisites (ETH must be sent, check contract source for modifiers/access control) but lacks explicit guidance on when to use this versus sibling upgrade functions (upgradeTo, upgradeToAndCall). The access control warning implies restricted usage but doesn't contrast with 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?

With no annotations, the description carries the full burden. It successfully notes that 'implementation' is indexed/filterable (critical for log filtering), but omits whether this returns historical events, streams new ones, or pagination behavior. It doesn't describe the return format or subscription lifecycle.

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 sentences with zero waste: identifies the entity (event), highlights the key parameter characteristic (indexed/filterable), and states the mechanism (log filters). Front-loaded with the most important distinction (event vs function).

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 single-parameter event subscription tool without output schema annotations, the description adequately covers the filtering capability and subscription method. It could improve by mentioning return format or whether this captures historical vs future events, but it's sufficient 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 has 100% coverage with clear typing, but the description adds valuable semantic context that the implementation field is 'Indexed' and 'filterable'—crucial metadata for blockchain log filtering that the schema's technical 'address' type doesn't convey. It elevates the parameter from a mere string to a filter key.

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 identifies this as an event ('Event emitted by the contract') rather than an action, distinguishing it from siblings like upgradeTo/upgradeToAndCall which likely perform upgrades. However, it frames the tool's purpose passively (describing the event) rather than actively stating it queries/subscribes to the event, though 'Subscribe via log filters' partially addresses this.

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 via 'Subscribe via log filters' and the event context suggests it's for monitoring upgrades, but lacks explicit when-to-use guidance contrasting it with the upgradeTo functions (e.g., 'Use this to monitor upgrades rather than execute them'). No prerequisites or alternative approaches mentioned.

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 behavioral disclosure. It effectively warns about access control requirements and explicitly states 'No return value', covering important behavioral traits that structured fields do not provide.

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?

Four sentences, each earning its place: function signature identification, operation type/access warning, prerequisite instruction, and return value disclosure. Front-loaded with the essential call pattern and appropriately dense.

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 single-parameter, no-output schema, the description adequately covers the critical safety considerations (access control) and return behavior. Could be improved by explicitly mentioning this is for proxy contract upgrades or describing side effects (old implementation replacement).

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% (the single parameter is well-documented as an Ethereum address). The description references the parameter in the function signature but adds no semantic meaning beyond the schema's specification, meeting the baseline for high-coverage schemas.

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?

Identifies the specific function call pattern 'upgradeTo(newImplementation: string)' and labels it as a 'Write function', clarifying the mutation nature. However, it assumes domain knowledge about proxy upgrade patterns without explicitly stating 'upgrades contract implementation', and does not differentiate from the sibling 'upgradeToAndCall' 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?

Provides clear prerequisite guidance ('Check contract source for modifier requirements before calling') and warns about access control restrictions ('onlyOwner'). Lacks explicit comparison to sibling 'upgradeToAndCall' to help users choose between the two upgrade methods.

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 behavioral disclosure. It effectively communicates critical traits: ETH value requirement, write/mutation nature, potential access control modifiers, and absence of return values. This provides good safety context for a high-stakes 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?

Despite the weak opening sentence, the remaining sentences are high-value and appropriately ordered: ETH requirement, access control warning, operational guidance, and return value disclosure. No redundant phrases beyond the initial tautology.

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 high-stakes proxy upgrade operation with no annotations, the description covers critical safety aspects (authentication, ETH). However, it omits important context about what the 'AndCall' semantics entail (delegatecall behavior), revert conditions, or the relationship between the implementation address and the subsequent call.

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 type descriptions for both parameters. The description mentions the parameters by name but adds no semantic meaning beyond the schema (e.g., it does not explain that 'data' contains ABI-encoded initialization calls or delegatecall details). Baseline 3 is appropriate when schema handles syntactic documentation.

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

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

The description opens with a tautology ('Calls upgradeToAndCall') that restates the function name without explaining the behavior. While it mentions ETH requirements and write operations, it fails to distinguish this tool from sibling 'upgradeTo' (the key difference being the delegatecall capability via the 'data' parameter).

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 implied usage context by noting ETH value requirements and access control restrictions (e.g., onlyOwner). However, it lacks explicit guidance on when to choose this over 'upgradeTo' or what prerequisites must be met beyond checking contract source.

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