Do I need an API key before an agent can write the integration?

No. An agent can write and review the whole integration against the published reference without ever making a call. You need a key with a plan attached before it returns data — until then every endpoint answers 402 no_active_plan, which the prompts here tell the agent to handle explicitly.

Why point the agent at llms-full.txt instead of the docs?

It is the same content with the navigation, markup and styling stripped out. That means far fewer tokens, no risk of the model reading a code sample out of its surrounding caveat, and nothing that looks like an instruction to the model but was meant for a human. Every page also has a plain-text twin at .md if you only need one.

Which file should the rules go in?

AGENTS.md is the most portable — Codex reads it and a growing number of other agents do too. Claude Code reads CLAUDE.md, and Cursor reads .cursor/rules/*.mdc. The content is identical in all three, so if you use more than one tool, put the real file in AGENTS.md and have the others reference it in a single line.

Will these prompts work with a local or open-weights model?

The prompts are plain text with no tool-specific syntax, so yes. A smaller model is more likely to drift from the reference, so keep the rules file in context rather than relying on it having fetched the document once, and review the generated client by hand.

Can I use these commercially?

Yes. The prompts and the rules file are yours to copy, edit and ship. No attribution required.

For coding agents

Vibecode a TCG API integration

Point your agent at the real schema, paste a prompt, review the diff. These briefs exist because a model asked to add a card API will otherwise invent the endpoints — and the result compiles, runs and returns nothing.

Browse the prompts Read llms-full.txt

Step one

Give your agent the rules once

One file, saved wherever your tool looks for it. It pins the base URL, the auth header, the response envelope and the handful of rules that are quiet to get wrong — so you are not restating them in every prompt.

Save it as: CLAUDE.md
Then run: claude "Add TCGGraph card search to this project. Follow CLAUDE.md."

Claude Code reads CLAUDE.md from the repository root at the start of every session, and merges any CLAUDE.md it finds in subdirectories it works in.

CLAUDE.md

# TCGGraph

This project uses TCGGraph for trading card game data — one REST and GraphQL
API covering Pokémon, Magic: The Gathering, One Piece, Yu-Gi-Oh!, Disney Lorcana, Star Wars: Unlimited, Digimon and Grand Archive.

Full machine-readable reference: https://tcggraph.com/llms-full.txt
Every page also has a plain-text twin at <path>.md, e.g. https://tcggraph.com/docs/rest.md

## Connection

- REST base URL: https://api.tcggraph.com/v1
- GraphQL endpoint: https://api.tcggraph.com/graphql
- Auth header: `Authorization: Bearer $TCGGRAPH_KEY`
- API version is pinned per key and overridable with the `TCGGraph-Version` header.
  Current version: 2026-08-01

## Rules

- Never put TCGGRAPH_KEY in client-side code. Proxy through a server route.
- Never invent endpoints or fields. Check the reference above; if it is not
  there, say so rather than guessing.
- List responses are `{ data: [...], meta: {...} }`. Pagination lives in meta.
- Use `/v1/cards/search` for fuzzy or partial names. Use `/v1/cards` for
  structured filters. They are not interchangeable.
- Prices are per source, per condition, per finish, each with its own currency
  and timestamp. Never convert between currencies and never sum across sources.
- When filtering or sorting by price, pass `source`. The bounds are in that
  source's currency: `source=cardmarket&minPrice=50` means €50, not $50.
- Seed bulk data with `/v1/bulk/exports`, not by paginating `/v1/cards`.
- Sync incrementally on `updatedAt`. Upsert on `id`; group printings by `oracleId`.
- Card images come in small, normal, large, png and art-crop. Always set
  explicit dimensions — cards are 5:7.

## Errors worth handling explicitly

- `402 no_active_plan` — the account has no plan. Show an actionable message.
- `402 balance_empty` — the prepaid balance will not cover the call.
- `429 rate_limited` — honour Retry-After. Do not retry in a tight loop.

Step two

Paste a prompt

Each one is self-contained: it opens by grounding the agent in the published reference, names the exact endpoints and fields to use, and closes with the constraints that are expensive to retrofit.

First integration

Start hereAny framework

A typed client module plus one working card search, wired into the existing stack.

EU and US prices side by side

PricingCardmarket

A price panel showing Cardmarket in EUR next to TCGplayer in USD, correctly labelled.

Search with autocomplete

SearchUI

A debounced typeahead that tolerates accents, punctuation and half-typed names.

Nightly catalog sync

BackendData

A scheduled job that pulls the full catalog into your own database, incrementally.

Deck builder with legality checks

GameplayRules

A deck list that validates against real format rules instead of a hardcoded guess.

Card images done properly

ImagesPerformance

Fast, correctly-sized card art with no layout shift and no hotlinking surprises.

Webhook consumer

RealtimeBackend

A verified endpoint that reacts to new sets, price moves and ban list changes.

Why the grounding matters

What agents get wrong about card data

None of these fail loudly. Every one produces code that runs, returns plausible output and is quietly wrong — which is why they are worth stating up front rather than catching in review.

Converting EUR to USD

Typically: Reads a Cardmarket quote in EUR, multiplies by a hardcoded rate and shows one price.

Instead: Shows both markets separately in their own currency. Cardmarket and TCGplayer diverge for reasons that have nothing to do with the exchange rate — different supply, different grading conventions, different demand.

Filtering price without a source

Typically: Sends minPrice=50 and assumes dollars.

Instead: Passes source explicitly and reads meta.priceSource back. A silent currency mismatch produces a plausible-looking list that is simply wrong, which is far worse than an error.

Treating card names as unique

Typically: Keys a lookup or a cache on the card name.

Instead: Keys on id, which is stable and unique per printing, and groups with oracleId. Charizard exists hundreds of times across sets, languages and finishes.

Paginating the whole catalog

Typically: Loops /v1/cards to build a local copy, burning credits for hours.

Instead: Requests a bulk export once, then syncs incrementally on updatedAt. Orders of magnitude cheaper and faster.

Ignoring condition and finish

Typically: Takes the first price in the array and calls it the card's price.

Instead: Selects by condition and finish. A near-mint first-edition holo and a played reprint share a name and nothing else.

Shipping the key to the browser

Typically: Calls the API from a client component with the key inlined at build time.

Instead: Calls from a server route. A key in a JS bundle is a public key, and the first sign of it is usually the bill.

Machine-readable

Built to be read by something that is not a browser

Documentation an agent has to scrape is documentation it will get wrong. Every page on this site is available as plain text.

llms.txt

The short index. Every page, what it covers, and where the reference lives.

Open llms-full.txt

The whole reference as one plain-text document. This is what the prompts tell your agent to read first.

Open <path>.md

A plain-text twin of any page. Append .md to any URL on this site to get it without the markup.

Open

Questions

Vibecoding with TCGGraph

Do I need an API key before an agent can write the integration?: No. An agent can write and review the whole integration against the published reference without ever making a call. You need a key with a plan attached before it returns data — until then every endpoint answers 402 no_active_plan, which the prompts here tell the agent to handle explicitly.
Why point the agent at llms-full.txt instead of the docs?: It is the same content with the navigation, markup and styling stripped out. That means far fewer tokens, no risk of the model reading a code sample out of its surrounding caveat, and nothing that looks like an instruction to the model but was meant for a human. Every page also has a plain-text twin at <path>.md if you only need one.
Which file should the rules go in?: AGENTS.md is the most portable — Codex reads it and a growing number of other agents do too. Claude Code reads CLAUDE.md, and Cursor reads .cursor/rules/*.mdc. The content is identical in all three, so if you use more than one tool, put the real file in AGENTS.md and have the others reference it in a single line.
Will these prompts work with a local or open-weights model?: The prompts are plain text with no tool-specific syntax, so yes. A smaller model is more likely to drift from the reference, so keep the rules file in context rather than relying on it having fetched the document once, and review the generated client by hand.
Can I use these commercially?: Yes. The prompts and the rules file are yours to copy, edit and ship. No attribution required.

Your agent can write the integration today

The whole reference is public, so the code can be written and reviewed before you spend anything. Attach a plan when you want it to return data — until then every endpoint answers with TCGGraph’s 402 and tells you exactly why.

See pricing Read the quickstart