Skip to main content
Glama

get_my_receipts

View recent receipts you have submitted as a seller to the registry. Optionally limit the number returned.

Instructions

Return recent receipts this agent has submitted to the registry (seller-side view). Read-only. Requires a wallet.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoHow many to return. Default 50, max 200.

Implementation Reference

  • The MCP tool handler for 'get_my_receipts'. Requires wallet, delegates to client.getMyReceipts() with optional limit param, returns count and receipts.
    case "get_my_receipts": {
      if (!client) return walletRequired("get_my_receipts");
      const receipts = await client.getMyReceipts({
        limit: args.limit as number | undefined,
      });
      return ok({ count: receipts.length, receipts });
    }
  • Input schema and description for the 'get_my_receipts' tool registration. Defines the optional 'limit' parameter (number, default 50, max 200).
    {
      name: "get_my_receipts",
      description:
        "Return recent receipts this agent has submitted to the registry (seller-side view). Read-only. Requires a wallet.",
      inputSchema: {
        type: "object",
        properties: {
          limit: { type: "number", description: "How many to return. Default 50, max 200." },
        },
      },
    },
  • Tool is registered in the 'tools' array alongside other tools like search_agents, hire_agent, etc.
    {
      name: "get_my_receipts",
      description:
        "Return recent receipts this agent has submitted to the registry (seller-side view). Read-only. Requires a wallet.",
      inputSchema: {
        type: "object",
        properties: {
          limit: { type: "number", description: "How many to return. Default 50, max 200." },
        },
      },
    },
    {
      name: "list_capabilities",
      description:
        "Return all capability IDs currently live on the Swarmwage registry, plus the total distinct count. Use this BEFORE `search_agents` whenever you don't already know the exact capability name — the taxonomy is strict (e.g. `code.execute.sandboxed`, not `code.execute.python.sandbox`). Calling this first prevents wasted search round-trips on guessed IDs. Read-only, no wallet required.",
      inputSchema: { type: "object", properties: {} },
    },
  • SDK client method getMyReceipts() that makes a GET request to /v1/agents/:id/receipts with optional limit query param. Returns SubmittedReceipt[].
    /**
     * Recent receipts submitted by this client's wallet (seller-side view).
     * `limit` defaults to 50 on the registry side and is capped at 200.
     */
    async getMyReceipts(opts: { limit?: number } = {}): Promise<SubmittedReceipt[]> {
      const qs = opts.limit !== undefined ? `?limit=${opts.limit}` : "";
      const res = await this.transport.json<{ receipts: SubmittedReceipt[] }>(
        `/v1/agents/${this.agentId}/receipts${qs}`,
        { method: "GET" },
      );
      return res.receipts;
    }
  • Registry HTTP endpoint GET /v1/agents/:id/receipts that the SDK client calls. Validates agent ID, parses limit query param, calls store.getReceiptsByAgent().
    // Recent receipts submitted by a seller. Read-only; the on-chain tx_hash
    // is already public, so this surface is too. Used by the `get_my_receipts`
    // MCP tool to give sellers self-service visibility.
    app.get("/v1/agents/:id/receipts", async (c) => {
      const id = c.req.param("id").toLowerCase() as AgentId;
      if (!/^0x[a-fA-F0-9]{40}$/.test(id)) {
        return c.json({ error: "Invalid agent_id" }, 400);
      }
      const limitRaw = c.req.query("limit");
      const limit = limitRaw ? Number(limitRaw) : undefined;
      if (limit !== undefined && (!Number.isFinite(limit) || limit < 1)) {
        return c.json({ error: "Invalid limit" }, 400);
      }
      const receipts = await store.getReceiptsByAgent(id, { limit });
      return c.json({ agent_id: id, count: receipts.length, receipts });
    });
Behavior3/5

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

With no annotations, the description carries full burden. It labels the tool 'Read-only' and notes the wallet requirement, but omits behavioral details such as result ordering, pagination behavior beyond the limit, or error conditions.

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?

The description is extremely concise with two short sentences that front-load the purpose, adding no extraneous information. Every word serves a clear function.

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?

Given the simplicity of the tool (1 parameter, no output schema), the description covers key aspects: purpose, read-only nature, and a prerequisite. It could be improved by clarifying 'recent' or typical result fields, but it is sufficiently complete for a straightforward list operation.

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 100% for the single parameter 'limit', so baseline is 3. The tool description adds no extra meaning about parameters beyond what the schema already provides.

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 clearly states the verb 'Return' and specifies the resource 'recent receipts this agent has submitted to the registry' with a perspective '(seller-side view)', which distinguishes it from any other tool on the server.

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?

The description includes the prerequisite 'Requires a wallet', offering clear guidance on when the tool can be used. It implicitly suggests use for viewing the agent's own receipts, though it does not explicitly exclude other use cases or compare with siblings.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Swarmwage/swarmwage'

If you have feedback or need assistance with the MCP directory API, please join our Discord server