Skip to main content
Use this page as the reference while editing a listing. Every field should answer a question an agent has before recommending or integrating your tool.

​
Identity

​
Name and slug

Name is the human-facing product name. Slug is the stable identifier used by the API, MCP, and CLI (context <slug>). Keep the slug lowercase, short, and stable after publishing.
Do not put a version, language, or marketing slogan in the slug.

​
Image

Use a recognizable logo or product mark. It helps people scan search results; it does not replace a useful description.

​
Selection copy

​
Tagline (tagline)

Write one concrete sentence describing what the tool does and who it is for. Keep it short enough for search cards. Avoid claims such as “best” or “powerful.”

​
Description

This is the full decision brief agents use to choose between similar tools. Explain what the tool does, the intended stack or audience, when to choose it, and important constraints or when another option is better. Use the full available limit; do not repeat the tagline as a fragment.

​
Discovery metadata

​
Categories

Choose the smallest set of primary categories that describe the product (for example email, api, or notifications). Categories are constrained filter values and affect browse and search ranking.

​
Tags

Use short, searchable constraints and use cases that do not fit categories: webhooks, self-hosted, merchant-of-record, or bun. Do not use generic praise or duplicate every category.

​
Languages

List languages with an official SDK or documented integration. Languages unlock quickstart entries and language filters. Use the exact values offered by the editor.

​
Transports

List how developers or agents access the tool: api, cli, or mcp. A tool can support more than one transport. This is separate from the programming languages used by its SDKs.

​
Frameworks (legacy discovery metadata)

Frameworks remain available for compatibility and optional stack filtering, but they are not required and should not be an exhaustive catalog. Add only frameworks with a documented, meaningful integration. Put long-tail frameworks in tags and description instead of guessing or listing every compatible framework.

​
Quickstarts

Create one named quickstart for each useful language/transport combination. Multiple SDKs in the same language are supported: give each a distinct name such as TypeScript REST SDK and TypeScript Node SDK. Each entry contains: Keep the code minimal and runnable. Never invent package names or commands. Use the docs URL for the most specific official page, not only the homepage.

​
Inputs, outputs, and pitfalls

​
Input shape

Describe required arguments, authentication, environment variables, and request fields in compact schema-like prose.

​
Output shape

Describe the response or return value, important fields, errors, streaming behavior, and side effects.

​
Common pitfalls

Add actionable warnings such as required auth setup, async job polling, rate limits, or a common incorrect import. Keep each item focused on one mistake.

​
Sources

Sources are canonical links agents can use to verify metadata:
Use the official website, documentation, and canonical repository when available. A quickstart’s docsUrl can point to a more specific language or transport page than the listing-level sources.docsUrl.

​
Verification

Only add facts you can verify from the official docs, repository, or package documentation. Set lastVerifiedAt through the publishing workflow; do not type a date to make a listing look newer. See Editing Your Tool for the form workflow and Publishing Changes for deployment requirements.