Skip to main content
Glama

OpenAny

Uniswap Get wallet delegations

uniswap_post_v1_wallet_check_delegation

Get wallet delegations. Uses the native public Uniswap HTTP contract. Uses the caller's OpenAny gateway credentials. Charges and authorization are determined by the gateway.

Input Schema

NameRequiredDescriptionDefault
bodyYesbody
x-agent-infoNox-agent-info

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.8/5.0
Behavior3/5

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

With no annotations at all, the description carries the full behavioral burden. It usefully discloses that it goes through the public Uniswap HTTP API, that caller gateway credentials are used, and that charging/authorization are gateway-determined, which is real value. However, it leaves the mutation question unresolved: the tool is a POST whose name says "check", yet neither side effects nor idempotency nor rate limits are addressed.

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

Conciseness4/5

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

Three short sentences, front-loaded with the purpose, with no filler. The gateway billing sentence is somewhat boilerplate but is genuinely informational rather than padding.

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

Completeness2/5

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

For a POST endpoint with a nested required body, no annotations, and no output schema, the definition is too thin. It never describes the shape or content of the delegation response, whether results are per-chain, or what happens with multiple wallet addresses, leaving the agent unable to predict the result of a call.

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

Parameters3/5

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

Schema description coverage is nominally 100%, so the baseline is 3, but the coverage is empty padding (the nested body is described only as "body" and the header as "x-agent-info"). The description adds nothing about walletAddresses, the allowed chainIds list, or what x-agent-info should contain, so the agent relies entirely on the JSON Schema structure.

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

Purpose3/5

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

The description states a verb and resource ("Get wallet delegations"), which is better than a tautology, but it never explains what a delegation is in this context (e.g. EIP-7702 delegation), which chains are relevant, or how this differs from siblings like uniswap_post_v1_permissions or uniswap_post_v1_wallet_encode_7702. An agent can guess the general area but cannot confidently distinguish it from adjacent wallet tools.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no mention of prerequisites beyond generic gateway credentials, and no named alternative. The description does not say when this tool should be chosen over uniswap_post_v1_permissions or the other wallet-related siblings.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.