> ## Documentation Index
> Fetch the complete documentation index at: https://docs.useagents.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Tool metadata field guide

> How to complete every editable UseAgents field so agents can discover, compare, and use your tool accurately.

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.

```yaml theme={null}
name: Resend
slug: resend
```

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.

```yaml theme={null}
description: >
  Email API for developers. Choose Resend for transactional and marketing
  email with React-based templates and built-in deliverability tooling.
  Prefer SES directly if you need raw SMTP control or are already fully
  inside AWS infrastructure.
```

## 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:

| Field           | Purpose                                            |
| --------------- | -------------------------------------------------- |
| Name            | Short tab label shown to people and agents         |
| Language        | SDK or example language                            |
| Transport       | `api`, `cli`, or `mcp`                             |
| Install command | Verified package or binary installation command    |
| Code            | Minimal copy-pasteable first call                  |
| Docs URL        | Deep link to the exact guide or reference page     |
| Frameworks      | Optional verified framework context for this entry |

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:

```yaml theme={null}
sources:
  website: https://resend.com
  docsUrl: https://resend.com/docs
  repoUrl: https://github.com/resendlabs/resend-node
```

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](/developers/editing-tools) for the form workflow and [Publishing Changes](/developers/publishing) for deployment requirements.