Skip to main content
Glama
Deconstruct2021

cryptopunks-mcp-server

get_collection_bids

Retrieve EIP-712 signed bids for CryptoPunks collections with summarized metadata including bidder, amount, and status to analyze market activity.

Instructions

Get collection bids from bids.cryptopunks.app — EIP-712 signed bids that cover sets of punks. Returns summarized bid metadata (UUID, bidder, amount, punk count, status) to avoid payload overflow. For full punk lists and proofs, use get_bid_proofs with a specific bid UUID.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bidderNoFilter by bidder Ethereum address
statusNoFilter by status. Try 'pending' for active bids.
limitNo
chain_idNo

Implementation Reference

  • The handler logic for "get_collection_bids", which fetches bids via the API and applies summarization to avoid payload overflow.
    case "get_collection_bids": {
      const raw = await api.getBids({
        bidder: args.bidder,
        status: args.status,
        limit: args.limit ?? 50,
        chainId: args.chain_id ?? 1,
      });
      // Bug 5 fix: summarize to avoid payload overflow
      return ok(summarizeBidsResponse(raw));
    }
  • The definition and input schema for the "get_collection_bids" tool.
    get_collection_bids: {
      description:
        "Get collection bids from bids.cryptopunks.app — EIP-712 signed bids that cover sets of punks. Returns summarized bid metadata (UUID, bidder, amount, punk count, status) to avoid payload overflow. For full punk lists and proofs, use get_bid_proofs with a specific bid UUID.",
      inputSchema: z.object({
        bidder: ethAddress.optional().describe("Filter by bidder Ethereum address"),
        status: bidStatus.optional().describe("Filter by status. Try 'pending' for active bids."),
        limit: z.number().int().min(1).max(100).optional().default(50),
        chain_id: z.number().int().optional().default(1),
      }),
    },
Behavior4/5

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

With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it specifies the data source ('bids.cryptopunks.app'), describes the return format ('summarized bid metadata'), explains the rationale ('to avoid payload overflow'), and mentions the bid types ('EIP-712 signed bids that cover sets of punks'). It doesn't cover rate limits or authentication needs, but provides substantial context.

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 front-loaded with the core purpose, followed by usage guidance and alternatives in two efficient sentences. Every sentence adds value without redundancy, making it appropriately sized and well-structured.

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 tool with 4 parameters, 50% schema coverage, no annotations, and no output schema, the description does well by clarifying the tool's scope, return format, and sibling differentiation. It could improve by addressing missing parameter details or authentication, but it's largely complete given the context.

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 50%, and the description adds no specific parameter information beyond what the schema provides. It mentions filtering by 'bidder' and 'status' implicitly through the example of 'get_bid_proofs', but doesn't explain parameters like 'limit' or 'chain_id'. The baseline is 3 since the schema covers half the parameters adequately.

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 tool's purpose: 'Get collection bids from bids.cryptopunks.app' specifies both the verb ('Get') and resource ('collection bids'), and it distinguishes from siblings by explaining this returns summarized metadata versus full details available through 'get_bid_proofs'.

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

Usage Guidelines5/5

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

The description explicitly provides when to use this tool ('Returns summarized bid metadata... to avoid payload overflow') and when to use an alternative ('For full punk lists and proofs, use get_bid_proofs with a specific bid UUID'), offering clear guidance on tool selection.

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/Deconstruct2021/cryptopunks-mcp-server'

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