Skip to main content
Glama
Sign In

Realtap

by io.github.CSteenkamp
OverviewDiscussionsAdmin

Find AI agent services on Cardano (Masumi)

list_masumi_agents
Read-onlyIdempotent

Search the AI agent services registered in the Masumi registry on Cardano: what each one does, its price, the address of its API, who registered it, and, read from Masumi's escrow contract, how many payments it actually received, from how many distinct buyers and when last. Use it to find an agent that offers a service, or to judge whether a listed agent is used at all. The answer also carries the network totals of the last 30 days. Entries are written by their owners and are not verified.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_masumi_agents"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNoagent = services that are paid through Masumi's escrow; x402 = HTTP resources paid per call on another chain; all = both.agent
pageNoPage number, from 1.
sortNopayments = most payments received first; recent = newest registration first; price = cheapest first.payments
limitNoHow many entries to return (1-50, default 10).
queryNoWords to look for in the name, description, tags, author or endpoint, for example "research" or "image".
paidOnlyNotrue lists only entries that received at least one payment in the indexed history.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description adds genuinely new context: payment counts are derived from Masumi's escrow contract, responses include network totals for the last 30 days, and entries are owner-written and unverified. That last caveat is real decision-relevant behavior. It omits anything about rate limits or result-count metadata.

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?

Front-loads what is searched before describing fields and caveats, and every sentence contributes. The first sentence is dense with a nested clause ('and, read from Masumi's escrow contract, how many payments...') that is slightly harder to parse than necessary.

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?

With no output schema, the description usefully enumerates returned fields, aggregate totals and data provenance, and the input schema covers all six parameters. A minor ambiguity remains between 'network totals of the last 30 days' and per-entry payment history, which an agent could misread as result counts.

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% and the schema already explains kind, sort, page, limit, query and paidOnly with enum meanings, so the description carries no additional parameter semantics. Baseline 3 applies when the schema does all the work.

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?

States a specific verb and resource ('Search the AI agent services registered in the Masumi registry on Cardano') and then enumerates what each result carries (description, price, API address, registrant, escrow-derived payment counts). This clearly separates it from the singular get_masumi_agent sibling without needing to name it.

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?

Gives two concrete use cases: finding an agent that offers a service, and judging whether a listed agent is actually used. It implies list-vs-detail routing against get_masumi_agent but never names that sibling or states an explicit exclusion, so it stops short of the 5 bar.

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

All Realtap 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