Skip to main content
Glama
Sign In

keyfo

by xyz.keyfo
OverviewDiscussionsAdmin

Token approvals

stock_approvals
Read-onlyIdempotent

Open token approvals of a wallet on Robinhood Chain: the stock tokens keyfo lists, USDG and WETH, checked against the spenders keyfo knows, such as LI.FI and Permit2. It does not scan the wallet’s whole approval history. Unlimited approvals come first.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "wallet": "<wallet>"
    },
    "name": "stock_approvals"
  }
}

Input Schema

NameRequiredDescriptionDefault
walletYesWallet address on Robinhood Chain.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so safety is covered. The description adds genuinely useful context beyond that: the results are limited to keyfo's known token and spender sets rather than full history, and unlimited approvals are ordered first, which shapes how an agent should read the output.

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

Conciseness5/5

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

Three short sentences, each earning its place: scope, limitation, ordering. The core purpose is front-loaded in the first clause and nothing is repeated from the title or annotations.

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

Completeness4/5

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

For a one-parameter read tool with no output schema, the description does what matters: it defines the coverage envelope and hints at result ordering. It could say slightly more about the shape of each approval entry, but the ordering note covers the main interpretive need.

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 coverage is 100% with a single documented wallet parameter, so the schema already carries the parameter meaning, and the baseline is 3. The description reinforces the chain context ('wallet on Robinhood Chain') but adds no format, validation, or casing details beyond what the schema states.

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

Purpose5/5

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

The description names a specific verb and resource ('Open token approvals of a wallet') plus the chain (Robinhood Chain) and the exact scope covered: keyfo's listed stock tokens, USDG, WETH, checked against known spenders like LI.FI and Permit2. An agent can tell this apart from a generic approval-history scan without opening the schema.

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

Usage Guidelines4/5

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

'It does not scan the wallet's whole approval history' explicitly sets a boundary on when this tool is and is not sufficient, and the mention of unlimited approvals coming first signals prioritization. It stops short of naming an alternative (e.g. a broader scan or the revoke builder) for the cases this tool does not cover.

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

All keyfo toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources