Codex Pets
Codex Pets is a community gallery and platform for animated pets. Here's what you can do:
Public Users
Browse and view the public gallery of approved animated pets
Submit new pet packages for moderation
Request generated pets via a text brief and optional reference image
Register, log in, and manage a local account
Logged-in Users
View and delete your own submitted pets and generation requests
Administrators
Approve, reject, or delete pending pet submissions
Review generation requests and link them to existing pets
Agent & Programmatic Access (Read-Only MCP Tools)
search_pets— Search approved pets by query, kind, tags, author, or compatibilityget_pet— Fetch full details of a specific approved pet by slugget_install_instructions— Get CLI install commands (npx @astandrik/codex-pets install <slug>)get_badge_code— Generate Markdown/HTML README badge snippetsget_embed_code— Generate iframe embed snippets for websitesget_card_code— Generate animated GIF card snippets for READMEsget_pet_request_info— Read info about the public pet request workflow (read-only)HTTP endpoints:
/api/pets,/api/pets/[slug],/api/manifest,/api/tags
Codex Pets
Community gallery for Codex-compatible animated pets with local accounts, manual moderation, public generation requests, YDB-backed asset storage, and public detail pages for approved and pending pets.
Public site: https://pets.ydb-qdrant.tech/.
Stack
Next.js 16 App Router, React 19, TypeScript strict
Gravity UI + SCSS/BEM
local-ydb / YDB native gRPC via
ydb-sdkApp-owned email+password auth with YDB-backed users and sessions
Pet assets stored in YDB as binary blobs
Dynamic
robots.txt,sitemap.xml,llms.txt,llms-full.txt, and OpenAPI JSONAgent-facing HTTP access through
llms.txt/llm.txt,/llms-full.txt,/mcp, JSON routes, and TOON mirrors for core registry dataOptional read-only browser WebMCP tools in supported browser runtimes
Yandex Metrika using the same counter as
ydb-qdrant-ui(104844437), with optional server-side aggregate MCP metricsJSZip + Sharp for package validation
Related MCP server: mcp-registry-interface
Development
nvm use 24
npm install
cp .env.example .env.local
npm run devOpen http://localhost:3000.
Agent access
Codex Pets exposes a public read-only MCP server so coding agents can search, inspect, install, and share approved pet packs.
Primary public surfaces:
Best guide: https://pets.ydb-qdrant.tech/guides/best-codex-pets-for-ai-coding-agents
LLM discovery: https://pets.ydb-qdrant.tech/llms.txt
MCP endpoint: https://pets.ydb-qdrant.tech/mcp
Public manifest: https://pets.ydb-qdrant.tech/api/manifest
CLI install:
npx @astandrik/codex-pets install <slug>
Connect Codex:
codex mcp add codexPets --url https://pets.ydb-qdrant.tech/mcpRun a local stdio MCP server that proxies the public gallery:
npx @astandrik/codex-pets mcpAvailable MCP tools:
search_pets— discover approved pets when you need candidates or lack an exact slugget_pet— fetch one public pet card when you already have an approved slugget_install_instructions— get install commands without incrementing metricsget_badge_code— generate README badge snippets for a known slugget_embed_code— generate iframe embed snippets for a known slugget_card_code— generate animated GIF snippets for a known slug, defaulting to sprite-only modeget_pet_request_info— discover the public new-pet request workflow; it does not submit or inspect private requests
HTTP fallback routes are public too:
/openapi.json/api/openapi.json/llms-full.txt/guides/best-codex-pets-for-ai-coding-agents/guides/best-codex-pets-for-ai-coding-agents.md/api/manifest/api/manifest.toon/api/pets/api/pets.toon/api/pets/<slug>/api/pets/<slug>.toon/pets/<slug>/markdown/api/tags/api/tags.toon/api/pets/<slug>/share/badge/<slug>.svg/card/<slug>.gif/embed/<slug>
The crawlable HTML gallery lives on /; numbered pages use /?page=2,
/?page=3, and so on. The legacy /pets catalog URL permanently redirects
to the equivalent homepage URL, while pet details remain on /pets/<slug>.
/api/pets and /api/pets.toon accept optional page and pageSize
parameters. Supplying either parameter enables the additive pagination
metadata object; requests without them retain the legacy response shape.
In paginated responses, top-level total is the number of returned pets and
pagination.totalItems is the full filtered count.
If you deploy under a subpath such as /codex-pets, set:
NEXT_PUBLIC_BASE_PATH=/codex-pets
NEXT_PUBLIC_APP_URL=https://example.com/codex-petsThe public gallery renders without secrets. For account login, submit, moderation,
and metrics you need YDB_PETS_ENDPOINT, YDB_PETS_DATABASE, and auth env.
Optional server-side MCP metrics also need YANDEX_METRIKA_MP_TOKEN and
YANDEX_METRIKA_MP_CLIENT_ID.
Optional IndexNow notifications are enabled by INDEXNOW_KEY; the app serves
/<key>.txt and pings IndexNow after an admin approves a pet.
Optional semantic search uses Yandex AI Studio text embeddings and exact cosine
ranking in YDB. Query mode defaults to PET_SEARCH_MODE=lexical; shadow
computes semantic ranking without changing public order, and hybrid combines
lexical and text-semantic ranks. An independent
PET_SEARCH_VISUAL_MODE=off|shadow|hybrid adds an offline visual-caption rank
from four fixed sprite frames. Captions and their provenance remain internal;
public JSON, TOON, homepage, MCP, and WebMCP shapes do not change. Configure
YANDEX_AI_STUDIO_FOLDER_ID,
YANDEX_AI_STUDIO_API_KEY_FILE, and
PET_SEARCH_MODEL_REVISION=yandex-text-embeddings-v2-768-2026-07. The v2
runtime uses the managed text-embeddings-v2-doc/query models at 768
dimensions. Set
PET_SEARCH_VISUAL_MODEL_REVISION=yandex-text-embeddings-v2-768-pet-vision-qwen3.6-v1
for the compatible Qwen visual rank. Legacy 256-dimensional revisions remain
registered for rollback. The API key is accepted only through the secret-file
setting. Provider failures and timeouts fall back to lexical results;
visual-only failures preserve the text-hybrid order.
To run without YDB on generated sample data:
CODEX_PETS_DATA_SOURCE=mock AUTH_MODE=single-user \
AUTH_SINGLE_USER_EMAIL=local-admin@example.com \
NEXT_PUBLIC_APP_URL=http://localhost:3000 \
npm run dev -- --port 3000Production notes
For a dedicated public subdomain such as https://pets.example.com, prefer:
NEXT_PUBLIC_APP_URL=https://pets.example.com
NEXT_PUBLIC_BASE_PATH=If the app container talks to YDB by Docker hostname, for example
grpc://ydb-local:2136, run the app on the same Docker network as the YDB
containers:
docker run --network ydb-net ...Telegram and similar preview crawlers are handled by lightweight preview routes:
/api/preview/site/api/preview/pets/[slug]
The reverse proxy should rewrite preview-bot requests for / and /pets/<slug>
to those endpoints before proxying to the normal App Router pages. See:
Local YDB quickstart
For local app development, a plain local-ydb root database at /local is enough;
you do not need a CMS tenant or dynamic node. The app runs on the host, so the
local-ydb container must publish gRPC on 127.0.0.1:2136.
If you use the local-ydb MCP, start from a clean root database with
local_ydb_destroy_stack(confirm=true) and
local_ydb_bootstrap_root_database(confirm=true). If the resulting container
does not publish 127.0.0.1:2136, recreate only the container on the same
volume with a host gRPC port:
docker rm -f ydb-local
docker run -d --name ydb-local --no-healthcheck --network ydb-net \
--restart unless-stopped \
-p 127.0.0.1:2136:2136 \
-p 127.0.0.1:8765:8765 \
-v ydb-local-data:/ydb_data \
-e GRPC_PORT=2136 \
-e MON_PORT=8765 \
-e GRPC_TLS_PORT= \
-e YDB_GRPC_ENABLE_TLS=0 \
-e YDB_ANONYMOUS_CREDENTIALS=1 \
-e YDB_LOCAL_SURVIVE_RESTART=1 \
ghcr.io/ydb-platform/local-ydb:26.1.1.6Use these local app env vars:
AUTH_MODE=single-user
AUTH_SINGLE_USER_ID=local-admin
AUTH_SINGLE_USER_EMAIL=local-admin@example.com
AUTH_SINGLE_USER_NAME="Local Admin"
SESSION_COOKIE_SECRET=dev-cookie-secret
PASSWORD_PEPPER=dev-password-pepper
INITIAL_ADMIN_EMAILS=local-admin@example.com
YDB_ANONYMOUS_CREDENTIALS=1
YDB_ENDPOINT=grpc://127.0.0.1:2136
YDB_PETS_ENDPOINT=grpc://127.0.0.1:2136
YDB_PETS_DATABASE=/local
NEXT_PUBLIC_APP_URL=http://localhost:3000YDB_ENDPOINT is needed for local host-to-Docker runs because ydb-sdk
otherwise follows discovery endpoints that may contain the Docker container
hostname.
Apply schema, seed data, and start the app:
docker cp ydb/schema.yql ydb-local:/tmp/codex-pets-schema.yql
docker exec ydb-local /ydb -e grpc://localhost:2136 -d /local scripting yql -f /tmp/codex-pets-schema.yql
npm run db:migrate
npm run seed:dev:reset
npm run dev -- --port 3000Open http://localhost:3000. The local YDB monitoring UI is
http://127.0.0.1:8765.
For a remote or tenant-backed deployment, point the app at a reachable tenant endpoint, for example:
YDB_PETS_ENDPOINT=grpc://ydb-host:2137
YDB_PETS_DATABASE=/local/your-tenant
YDB_STATIC_CREDENTIALS_USER=appuser
YDB_STATIC_CREDENTIALS_PASSWORD_FILE=/run/secrets/app.password
YDB_STATIC_CREDENTIALS_AUTH_ENDPOINT=grpc://ydb-host:2136For local development without a full account flow:
AUTH_MODE=single-user
AUTH_SINGLE_USER_ID=local-admin
SESSION_COOKIE_SECRET=dev-cookie-secret
PASSWORD_PEPPER=dev-password-pepper
INITIAL_ADMIN_EMAILS=local-admin@example.comFor the normal built-in account flow:
AUTH_MODE=app-session
SESSION_COOKIE_SECRET=change-me
PASSWORD_PEPPER=change-me-too
INITIAL_ADMIN_EMAILS=admin@example.comCreate tables manually on the existing local-ydb tenant:
ydb -e "$YDB_PETS_ENDPOINT" -d "$YDB_PETS_DATABASE" scripting yql -f ydb/schema.yqlApply migrations to an existing database:
npm run db:migratePreview and apply the approved-pet text and visual backfills after the migrations:
npm run search:backfill -- --dry-run
npm run search:backfill -- --apply
npm run search:backfill -- --apply --slug orbit-otter --force
npm run search:backfill-vision -- --dry-run
npm run search:backfill-vision -- --apply --slug orbit-otter
npm run search:backfill-vision -- --apply
npm run search:eval:calibrate
npm run search:eval:holdoutBoth backfills require an explicit --dry-run or --apply; visual --force
is valid only with --apply. They never print document text, captions, images,
embeddings, prompts, or secrets. Dry-run still reads and hashes spritesheets
but never calls either AI provider and never writes YDB. A safe rollout is
base lexical and visual off → additive migrations → backfills → visual
shadow → calibration → untouched holdout → human review of the combined
sexy top five → both modes hybrid.
An applied text or visual backfill that changes vectors prints the required related-pet snapshot follow-up. Run the full V24 derived-data sequence after embedding maintenance completes so snapshot rankings do not remain stale:
npm run related:backfill-description-query -- --dry-run
npm run related:backfill-description-query -- --apply
npm run related:backfill-description-document -- --dry-run
npm run related:backfill-description-document -- --apply
npm run related:backfill-annotations -- --dry-run
npm run related:backfill-annotations -- --apply
npm run related:backfill-annotation-query -- --dry-run
npm run related:backfill-annotation-query -- --apply
npm run related:backfill-annotation-document -- --dry-run
npm run related:backfill-annotation-document -- --apply
npm run related:rebuild -- --dry-run
npm run related:rebuild -- --apply
npm run related:verify:v24Related-pets description similarity uses separate query and document revisions
built from the same normalized name + kind + description text. Tags are
excluded from both embedding inputs. The query revision uses the query role and
the document revision uses the document role of the same 768-dimensional model.
Run model backfills sequentially so they share the AI Studio rate budget. V24
combines description similarity with controlled entity, franchise, collection,
and archetype annotations. Visual similarity contributes to ordering inside the
qualified tier and also orders shared-topic sparse-fallback candidates after
topic count and kind. Visual evidence alone cannot qualify or rescue a match.
The relation policy adds verified parent families and known numbered-series
roots without replacing entity/franchise identifiers or stored annotations.
It preserves explicit family-field overrides. Registry changes require a new
relation-policy revision and generation, not new annotation embeddings.
The current ranking revision stores eight ordered slugs per approved pet. Pet
detail pages render all eight immediately (four columns on desktop, three on
tablet, and two on mobile); the private Markdown twin intentionally keeps the
first four. Its persisted revision is immutable so the active generation can be
checked against the exact current implementation.
Text and visual backfills resolve their embedding provider independently from their active revision. Visual ranking is disabled safely when the text and visual revisions use incompatible embedding models.
Admin approval can queue an atomic preparation that refreshes the ordinary
search document, description query/document vectors, controlled annotation and
both annotation-vector roles, plus visual input. It publishes the pet, review,
and prepared generation in one transaction only after every input is current.
Failures leave the pet pending and the previous generation active. When
PET_RELATED_PREAPPROVAL_ENABLED is not exact true, approval fails closed
instead of publishing a pet without current V24 inputs.
Atomic generation activation also rotates the related-candidate and sitemap
cache keys, so the standalone worker does not depend on a Next request context.
npm run related:verify:v24 is read-only: it recomputes V24 from stored inputs
and checks coverage, integrity, the active revision, and exact ordered snapshot
parity without calling AI Studio.
The first rollback is PET_SEARCH_VISUAL_MODE=off; use
PET_SEARCH_MODE=lexical to disable the text-semantic contour too. The additive
caption and embeddings tables may remain.
The checked-in eval queries live in
src/lib/pets/search-eval-fixtures.json with frozen calibration and
holdout splits. Calibration evaluates all observed visual scores against
weights 0.25, 0.50, 0.75, and 1.00; the holdout command requires a
committed revision-bound profile and must not be used for tuning. Live eval
requires configured YDB and AI Studio access and prints aggregate results plus
the public slugs in the final sexy review list.
Seed local development data after the schema exists:
npm run seed:devUse npm run seed:dev:reset to replace only the fixed dev_* seed records.
Current behavior
Public users can browse the gallery and open
/pets/[slug].Public users can submit a pet without logging in by providing files and an optional contact email.
Public users can request a generated pet without logging in by providing a contact email, text brief, and optional reference image.
Logged-in users can see only their own pets under
/my-pets.Logged-in users can see their own pet generation requests under
/my-requests.Admins are determined by
INITIAL_ADMIN_EMAILS.Admins can approve, reject, and delete pending pets from
/admin/submissions.Admins can review generation requests and link them to existing pets from
/admin/requests.Owners can delete their own pets from
/my-pets.Admins can delete any pet from the pet detail page.
Deleted pets disappear from owner lists, public listings, and
sitemap.xml.
SEO, agents, and analytics
robots.txtis served fromsrc/app/robots.ts.sitemap.xmlis dynamic and includes all currently approved pets.llms.txtis dynamic and provides a curated AI-readable map of the gallery, manifest, and approved pet pages./llm.txtis a direct plain-text alias for fetchers that request the singular filename.llms-full.txtis dynamic and provides expanded AI-readable docs with API reference links, auth notes, examples, and webhooks status./openapi.jsonis the canonical OpenAPI 3.1 specification for the public agent/developer contract subset. It intentionally omits public metric mutation and download redirect routes./api/openapi.jsonis an alias for scanners that probe predictable API paths./developersand/docs/apiare indexed developer-resource pages for API, OpenAPI, MCP, auth, and webhooks discoverability./mcpis a public read-only Streamable HTTP MCP server for coding agents. Codex can connect with:codex mcp add codexPets --url https://pets.ydb-qdrant.tech/mcp.Official MCP Registry name:
tech.ydb-qdrant.pets/codex-pets-ydb-qdrant.server.jsonand/.well-known/mcp/server.jsonexpose MCP Registry metadata for the public remote server./.well-known/mcp-registry-authexposes the public HTTP domain auth record used bymcp-publisher.HTTP agent access is the primary public machine contract:
/mcp— Streamable HTTP MCP endpoint with read-only tools:search_pets,get_pet,get_install_instructions,get_badge_code,get_embed_code,get_card_code, andget_pet_request_info/openapi.jsonand/api/openapi.json— OpenAPI 3.1 public agent/developer contract subset/llms-full.txt— expanded LLM-readable API, auth, MCP, package, and webhooks documentation/developersand/docs/api— developer portal and API docs pages/server.jsonand/.well-known/mcp/server.json— MCP Registry metadata pointing to the public Streamable HTTP remote/.well-known/mcp-registry-auth— public MCP Registry HTTP auth record/api/manifest— approved pet list with page URLs, install commands, and asset URLs/api/manifest.toon— TOON mirror of the public manifest for LLM-friendly retrieval/api/pets?q=<query>&kind=all|creature|object|character— approved pet list/search JSON without private contact emails/api/pets.toon?q=<query>&kind=all|creature|object|character— TOON mirror of approved pet list/search without private contact emails/api/pets/<slug>— public detail JSON for one approved pet without private contact emails/api/pets/<slug>.toon— TOON mirror of public detail data without private contact emails/api/tags— current tag counts for approved pets/api/tags.toon— TOON mirror of current tag counts/api/pets/<slug>/share— sanitized install, badge, and embed snippets/api/pets/<slug>/install— read-only install instructions with no metric mutation/badge/<slug>.svg— README badge SVG/card/<slug>.gif— animated GIF share surface. Supportsmode=sprite|card,state, andscale; default sharable output is sprite-only./embed/<slug>— iframe embed page. Supportsmode=sprite|card,state,scale,theme,compact, and visibility toggles.npx @astandrik/codex-pets install <slug>— CLI install command format
Browser WebMCP is a read-only progressive enhancement. It only works in browser runtimes that expose
navigator.modelContext; ordinary HTTP crawlers and ChatGPT browsing sessions should use the endpoints above. Supported browser WebMCP tools:search_codex_pets— search approved pets through/api/petsget_codex_pet— fetch one approved pet through/api/pets/[slug]get_codex_pets_manifest— fetch/api/manifestget_current_codex_pet— inspect the approved pet open in the current tab
WebMCP intentionally does not expose submit, like, download/install counters, auth, admin, moderation, or delete actions.
The sitemap updates automatically after moderation changes; no cron or manual rebuild is needed for new approved pets to appear there.
Yandex Metrika is loaded in production only and tracks:
account register/login success and error
pet submit success and error
pet generation request success and error
moderation approve/reject/delete
related-pet impressions at 50% visibility and detail-navigation clicks, including source slug, target slug, and one-based position
related install-command copies and downloads, both directly on the card and for matching detail-page actions within a 30-minute browser session
Server-side MCP aggregate metrics are optional. They are enabled only when
YANDEX_METRIKA_MP_TOKENandYANDEX_METRIKA_MP_CLIENT_IDare configured. MCP metrics use a dedicated technical Metrika ClientID and send a synthetic/mcppageview before themcp_tool_callgoal event. The payload includes only aggregate tool dimensions such as tool name, status, safe slug, kind, result count, and limit; it does not include raw MCP search text, IP address, user-agent, origin header, contact email, owner email, or owner identifiers.IndexNow is optional. Set
INDEXNOW_KEYin the runtime env to enable the public key file and approval-time notifications for the gallery, the new pet detail page,sitemap.xml,llms.txt, and/api/manifest.
Main routes
/— public gallery/request— public pet generation request flow/submit— public submit flow/login,/register,/logout— local account flow/my-pets— owner view/my-requests— logged-in user generation request view/admin/submissions— admin moderation queue/admin/requests— admin pet generation request queue/pets/[slug]— pet detail page/agents— agent and MCP connection guide/developers— Codex Pets Developer Portal/docs/api— Codex Pets API docs/guides/best-codex-pets-for-ai-coding-agents— category guide for Codex pet selection/guides/codex-pets-vs-vscode-pets— comparison guide for editor pet use cases/mcp— public read-only Streamable HTTP MCP endpoint/openapi.json,/api/openapi.json— public OpenAPI specification/server.json,/.well-known/mcp/server.json— MCP Registry metadata/api/manifest— public agent/CLI manifest/api/manifest.toon— TOON mirror of the public manifest/api/pets— public approved pet list/search JSON/api/pets.toon— TOON mirror of approved pet list/search/api/pets/[slug]— public approved pet detail JSON/api/pets/[slug].toon— TOON mirror of public pet detail data/api/tags,/api/pets/[slug]/share,/api/pets/[slug]/install— read-only agent/share JSON/api/tags.toon— TOON mirror of approved tag counts/badge/[slug].svg,/card/[slug].gif,/embed/[slug]— share surfaces/robots.txt,/sitemap.xml,/llms.txt,/llm.txt,/llms-full.txt— SEO and AI-readable outputs
Agent-facing checks
Use CODEX_PETS_DATA_SOURCE=mock npm run dev -- --port 3000 to smoke-check
agent-facing routes without local YDB. Expected public endpoints:
curl -I http://localhost:3000/
curl -I http://localhost:3000/api/pets
curl -I http://localhost:3000/api/pets.toon
curl -I http://localhost:3000/api/manifest
curl -I http://localhost:3000/api/manifest.toon
curl -I http://localhost:3000/openapi.json
curl -I http://localhost:3000/api/openapi.json
curl -I http://localhost:3000/api/tags
curl -I http://localhost:3000/api/tags.toon
curl -I http://localhost:3000/llms.txt
curl -I http://localhost:3000/llm.txt
curl -I http://localhost:3000/llms-full.txt
curl -I http://localhost:3000/developers
curl -I http://localhost:3000/docs/api
curl -I http://localhost:3000/guides/best-codex-pets-for-ai-coding-agents
curl -I http://localhost:3000/guides/codex-pets-vs-vscode-pets
curl -i http://localhost:3000/mcpFor a JSON-response MCP smoke test:
curl -s http://localhost:3000/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
--data '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'For WebMCP itself, use a WebMCP-capable Chrome or lab browser and check that
navigator.modelContext exposes the read-only tools listed above. In normal
browsers without WebMCP, the client registrar is a no-op; this is expected and
does not affect the HTTP agent contract.
Private deployment notes
Concrete per-host instructions, local paths, and operational notes should live
under a gitignored private/ directory. The public docs in this repo should stay
generic and safe to commit.
Pet Package
Each pet is distributed as:
pet.jsonspritesheet.webporspritesheet.pngdownloadable ZIP containing both files at the root
The registry accepts both Codex atlas versions, each using 192x208 cells:
v1: omit
spriteVersionNumberor set it to1; use an 8x9 atlas at1536x1872.v2: set
spriteVersionNumberto2; use an 8x11 atlas at1536x2288, including the 16 clockwise look directions in rows 9 and 10.
CLI install
Approved gallery pets can be installed into Codex from npm:
npx @astandrik/codex-pets install zero-two-2The CLI reads /api/manifest from https://pets.ydb-qdrant.tech by default
and writes to ${CODEX_HOME:-~/.codex}/pets/<slug>/. Use --force to replace
an existing local pet folder, or CODEX_PETS_URL / --url to point at another
deployment. If Codex is already running, restart it before selecting the new pet
in Settings -> Appearance -> Pets.
Available Tools
7 toolsget_badge_codeGet README badge codeARead-onlyIdempotent
Use for a known approved pet slug when the user needs README badge Markdown, HTML, or SVG URL. Do not use for animated README cards, website iframe embeds, install instructions, or pet discovery; use get_card_code, get_embed_code, get_install_instructions, or search_pets instead.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Exact slug of an approved public Codex pet. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds that output includes Markdown, HTML, or SVG URL, which are behavioral details not covered by annotations. Could mention more about prerequisites or error handling, but sufficient given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, second sentence providing exclusions and alternatives. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers what it returns, constraints (approved pet slug), and when to avoid. Complete given the tool's simplicity and rich annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter 'slug' is fully documented. The description reinforces that it must be an exact slug of an approved pet but adds no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating README badge Markdown, HTML, or SVG URL for a known approved pet slug. It distinguishes from siblings by explicitly naming alternatives for other use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (known approved pet slug, need badge code) and when not to use (animated cards, iframe embeds, install instructions, pet discovery), listing specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_card_codeGet animated README card codeARead-onlyIdempotent
Use for a known approved pet slug when the user needs animated README card Markdown, HTML, or GIF URL. Do not use for simple badges, website iframe embeds, install instructions, or pet discovery; use get_badge_code, get_embed_code, get_install_instructions, or search_pets instead.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Exact slug of an approved public Codex pet. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe, read-only, idempotent behavior. The description adds context that the input must be an 'approved' pet slug and that the output includes Markdown, HTML, or GIF URL, which is useful beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose and conditional usage. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one parameter, rich annotations, no output schema), the description sufficiently covers input and output types. It could mention the exact format of the returned code but is complete enough for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'slug' is well-described in the schema. The description reinforces the requirement ('known approved pet slug') but does not add significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving animated README card code (Markdown, HTML, or GIF URL) for a known approved pet slug. It distinguishes itself from siblings by listing specific alternative tools for other use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use (for a known approved pet slug needing animated README card code) and when not to use (badges, embeds, install instructions, pet discovery), with named alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_embed_codeGet website embed codeARead-onlyIdempotent
Use for a known approved pet slug when the user needs website iframe embed HTML or an embed URL. Do not use for README badges/cards, install instructions, or pet discovery; use get_badge_code, get_card_code, get_install_instructions, or search_pets instead.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Exact slug of an approved public Codex pet. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description mentions 'approved public Codex pet' which adds context about authorization, but does not disclose additional behavioral traits beyond the schema and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. The key information is front-loaded and every sentence earns its place, providing purpose and exclusions efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, good annotations, and no output schema, the description covers when to use, what it returns, and what not to use it for. No gaps given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single required 'slug' parameter, which has a description. The description does not add extra semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves website embed HTML or URL for a known approved pet slug. It uses specific verbs ('get website iframe embed HTML or an embed URL') and distinguishes from sibling tools like get_badge_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (known approved pet slug, needs embed) and when not to use (README badges/cards, install instructions, pet discovery) with named alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_install_instructionsGet install instructionsARead-onlyIdempotent
Use for a known approved pet slug when the user wants CLI or manual install instructions. Do not use to search for pets or inspect general metadata; use search_pets or get_pet instead. This tool is read-only and does not increment install or download counters.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Exact slug of an approved public Codex pet. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, destructiveHint, and idempotentHint. The description adds useful context that it does not increment install/download counters, going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information, front-loaded with the primary purpose, and each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, good schema, and clear description that covers purpose, usage boundaries, and behavioral traits, it is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear description of the 'slug' parameter. The description does not add new details about the parameter, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides CLI or manual install instructions for a known approved pet slug, and distinguishes from sibling tools search_pets and get_pet by stating what it should not be used for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (user wants install instructions for approved pet slug) and when not to use (search/inspect metadata), with named alternative tools (search_pets, get_pet).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_petGet Codex petARead-onlyIdempotent
Use when you already have an exact approved pet slug and need the sanitized public pet card, asset URLs, page URL, and install command for that one pet. Use search_pets first when you only have a name/query or need multiple results. Do not use for focused install, badge, embed, card, or request workflow details; use the matching get_* tool instead.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Exact slug of an approved public Codex pet. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the return types (sanitized card, asset URLs, page URL, install command), providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and usage condition. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter, rich annotations, and clear return behavior described, the description is fully sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (slug) with 100% schema coverage. Description confirms it expects an exact approved pet slug, adding no new syntax or constraints beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a specific pet's public card, assets, page URL, and install command using an exact approved slug. It distinguishes itself from sibling tools like search_pets by specifying the exact slug requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use when you have an exact slug and need pet details; advises to use search_pets first for name/query or multiple results. Also warns against using for other specific get_* tools, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pet_request_infoGet pet request infoARead-onlyIdempotent
Use when the user wants to request a new Codex pet or understand the public request form fields and reference image limits. Do not use to create, submit, update, or inspect private generation requests; no MCP tool exposes those operations. Use search_pets or get_pet for existing approved pets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false. The description adds clarity by stating it does not create/submit/update private requests, reinforcing non-destructive behavior. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the primary use, the second clarifies exclusions. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple info-retrieval tool with no parameters and no output schema, the description sufficiently explains the tool's scope and boundaries. Could mention return format but not essential given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema covers everything. Baseline score of 4 is appropriate as description doesn't need to add parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'request' and resource 'pet info', clearly stating the tool's purpose. It distinguishes from siblings like get_pet and search_pets by focusing on request-related info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use (user wants to request a new pet or understand form fields) and when not to (create, submit, update, or inspect private requests). Mentions alternatives (search_pets, get_pet) for existing pets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_petsSearch Codex petsARead-onlyIdempotent
Use to discover one or more approved public Codex pet packs by query, kind, tags, author, or Codex compatibility. Prefer this over get_pet when you do not already have an exact slug or need multiple candidates. Do not use for private generation requests or known-slug install/share snippets; use get_pet_request_info or a slug-specific get_* tool instead.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional text matched against approved pet names, descriptions, tags, and authors. | |
| kind | No | Optional pet kind filter. Use all or omit the field to include every kind. | |
| tags | No | Optional tag filter as a comma-separated string or array. All provided tags must match. | |
| author | No | Optional author name text matched against the public submitter name. | |
| compatibleWith | No | Optional compatibility filter. Use codex for Codex-compatible pets; other values return no matches. | |
| limit | No | Optional maximum result count. Defaults to 10 and is clamped to 1-60. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, idempotent, non-destructive hints. The description adds that it searches only approved public Codex packs, which is beyond annotations. It does not mention pagination or response structure, but the schema's limit parameter addresses pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then usage guidelines. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the tool's purpose and usage well. It could briefly mention what the returned packs contain, but the lack of output schema means this is not strictly required. The parameter count and enum are handled adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have descriptions in the schema (100% coverage), so the description adds minimal param-specific information. It provides context for how parameters work together but does not clarify beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers approved public Codex pet packs by various filters, using specific verbs and resource. It distinguishes itself from the sibling get_pet by noting it's for when an exact slug is unknown or multiple candidates are needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to prefer this tool (no exact slug, need multiple candidates) and when not to (private requests, known-slug snippets), naming alternatives like get_pet_request_info or slug-specific get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
6 tool updates
v0.1.1- Changed
get_badge_code1 field changed- changed
Input schema / properties / slug / descriptionPrevious value: -"Approved Codex pet slug."New value: +"Exact slug of an approved public Codex pet."
- Changed
get_card_code1 field changed- changed
Input schema / properties / slug / descriptionPrevious value: -"Approved Codex pet slug."New value: +"Exact slug of an approved public Codex pet."
- Changed
get_embed_code1 field changed- changed
Input schema / properties / slug / descriptionPrevious value: -"Approved Codex pet slug."New value: +"Exact slug of an approved public Codex pet."
- Changed
get_install_instructions1 field changed- changed
Input schema / properties / slug / descriptionPrevious value: -"Approved Codex pet slug."New value: +"Exact slug of an approved public Codex pet."
- Changed
get_pet1 field changed- changed
Input schema / properties / slug / descriptionPrevious value: -"Approved Codex pet slug."New value: +"Exact slug of an approved public Codex pet."
- Changed
search_pets6 fields changed- added
Input schema / properties / author / descriptionAdded value: +"Optional author name text matched against the public submitter name." - added
Input schema / properties / compatibleWith / descriptionAdded value: +"Optional compatibility filter. Use codex for Codex-compatible pets; other values return no matches." - added
Input schema / properties / kind / descriptionAdded value: +"Optional pet kind filter. Use all or omit the field to include every kind." - added
Input schema / properties / limit / descriptionAdded value: +"Optional maximum result count. Defaults to 10 and is clamped to 1-60." - added
Input schema / properties / query / descriptionAdded value: +"Optional text matched against approved pet names, descriptions, tags, and authors." - added
Input schema / properties / tags / descriptionAdded value: +"Optional tag filter as a comma-separated string or array. All provided tags must match."
7 tool updates
v0.1.0- First observed
get_badge_code - First observed
get_card_code - First observed
get_embed_code - First observed
get_install_instructions - First observed
get_pet - First observed
get_pet_request_info - First observed
search_pets
TDQS
Scored across 7 tools
Each tool has a clear, distinct purpose: badge, card, embed, install instructions, pet details, search, and request info. Descriptions explicitly cross-reference others to avoid confusion.
All tools follow a consistent verb_noun pattern: get_* for fetching specific resources and search_* for discovery. Naming is uniform and predictable.
Seven tools cover the full range of user interactions with approved Codex pets, from getting code snippets to searching. The count feels well-scoped without unnecessary tools.
The tool set covers all likely user needs for approved pets: discovery, details, all common embed forms (badge, card, embed, install), and request info. Missing creation/editing are intentionally out of scope.
Maintenance
Related MCP Connectors
Search, preview, install community Codex pet packs, and discover the pet request flow.
Registry of MCP servers, agent skills and plugins: search, filter, comments, likes, publish.
Registry of MCP servers, agent skills and plugins: search, filter, comments, likes, publish.
Search MCP servers, MCP clients and AI agents, and retrieve listing details. Free, read-only access.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceA hosted Model Context Protocol (MCP) server for game-dev spritesheet workflows. Connect it to Claude or any MCP-compatible AI client and pack, split, trim, and animate sprites through natural language — no local tools required.MIT
- AlicenseAqualityDmaintenanceMCP server for interfacing with the official Model Context Protocol registry. Enables Claude and other MCP clients to dynamically discover, browse, search, and manage MCP servers directly from GitHub.52MIT

io.github.OnticX/open-mcpofficial
FlicenseAqualityDmaintenanceA registry that enables MCP clients to discover and install MCP servers.1-- FlicenseAqualityBmaintenanceA read-only MCP server for discovering, curating, and monitoring updates for ARK: Survival Ascended mods via the CurseForge API.8-