Paddock Cards

Read private uploads

read_private_content

Read-onlyIdempotent

List assets and existing card compositions in one private scope after the buyer uploads. Returns asset IDs with their kinds and each composition’s design_key/version. Reuse an existing composition directly; use compose_private_card only for a new face. For a new purchase, prepare_order uses request_id = scope_id and the same token; existing drafts use revise_order. An empty scope returns empty assets and compositions arrays. An expired scope without checkout or payment returns NOT_FOUND; open a new scope to upload again.

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": {
      "scope_id": "<scope_id>",
      "order_access_token": "<order_access_token>"
    },
    "name": "read_private_content"
  }
}

Input Schema

Name	Required	Description	Default
`scope_id`	Yes	Exact scope_id returned by open_private_content for the uploads to list.
`order_access_token`	Yes	Exact private order_access_token returned by open_private_content for this scope. Keep it private and never invent one.

Output Schema

Name	Required	Description	Default
`ok`	Yes
`data`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 29, 2026

changedInput schema / properties / order_access_token / description

Previous value: -"The private capability returned by open_private_content. Never invent one."New value: +"Exact private order_access_token returned by open_private_content for this scope. Keep it private and never invent one."

addedInput schema / properties / scope_id / description

Added value: +"Exact scope_id returned by open_private_content for the uploads to list."

AddedOct 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the read-only/idempotent/non-destructive profile, but the description goes well beyond them by documenting edge-case behavior: an empty scope yields empty assets and compositions arrays, and an expired scope lacking checkout or payment returns NOT_FOUND. It even supplies the remediation ('open a new scope to upload again'), which no structured field conveys.

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-loaded with purpose and packed with zero padding across five sentences; each clause routes or constrains. It loses a point for restating the return payload ('asset IDs with their kinds and each composition's design_key/version') even though an output schema exists.

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

Completeness5/5

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

Given an output schema and rich annotations, the description still supplies everything an agent needs: the empty-state result, the NOT_FOUND condition, the recovery path, and the handoff to prepare_order/revise_order/compose_private_card. Nothing required to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100% and both parameters are documented there, so the baseline would be 3. The description adds genuine cross-tool semantics by explaining that the same scope_id and token are replayed as request_id when calling prepare_order, which is not derivable from the schema alone.

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 ('List assets and existing card compositions in one private scope') plus the precondition 'after the buyer uploads'. It also names the sibling tools that handle adjacent jobs (compose_private_card, prepare_order, revise_order), so the agent can distinguish it without opening other schemas.

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?

Explicit routing: reuse an existing composition directly, call compose_private_card only for a new face, use prepare_order with request_id = scope_id for a new purchase, and revise_order for existing drafts. Both the when and the when-not are stated with named alternatives.

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

All Paddock Cards tools Inspect

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

Need Help?