Skip to main content
After creating a tool, open Edit Tool anytime from the dashboard. Changes save to your draft until you deploy them to the live registry. Need help drafting metadata? Use UseAgents Copilot on the tool page for proposals, research, and deploy assistance.

​
Writing for selection

Agents often default to the most famous tool in a category. Your listing should make your tool selectable under constraints, not only recognizable by name. You do not need a feature matrix in the registry. You need clear choose-when signals so an agent can shortlist you next to peers.

​
Edit a tool

  1. Go to the dashboard.
  2. Open your tool from the list.
  3. Click Edit Tool in the sidebar.
  4. Update any field in the form.
  5. Click Save changes.
Saved edits stay on the draft. They are not visible in search or to agents until you deploy.
Archived tools cannot be edited. Restore the tool from settings before making changes.

​
Deployment readiness

At the top of the edit page, Deployment readiness tracks required fields for deploy: Optional fields (image, input/output shape, pitfalls, tags, languages, frameworks, and source links) improve quality and discovery but are not required for readiness.

​
Form sections

The edit form is organized into three sections:
  1. Define your tool - identity and description
  2. Make your tool usable by agents - how to install and call it
  3. Help agents discover your tool - tags, categories, and source links

​
Define your tool

What your tool is and why it exists.

​
Tool image

Upload a logo or icon for the tool. It appears on tool cards and detail pages.
  • Recommended aspect ratio: 1:1
  • Maximum size: 5 MB
  • Optional

​
Name

The display name of your tool. Required for readiness.
  • Minimum 1 character
  • Maximum 100 characters
  • Changing the name auto-updates the slug until you edit the slug manually

​
Slug URL

The URL-friendly identifier. It appears as useagents.site/t/your-slug.
  • Required for readiness
  • Minimum 3 characters, maximum 64
  • Must be unique across the registry
  • Auto-generated from the name by default; you can override it
  • Saved directly on the tool (not only as a draft field) so uniqueness stays enforced

​
Tagline

A one-sentence summary shown on tool cards (tagline in the API). Use it for category fit, not slogans.
  • Required for readiness
  • 10 to 160 characters
  • Keep it concise and human-readable
  • State what the tool is and who it is for

​
What does it do? (Description)

Explain the tool’s job and when an agent should choose it - especially versus category defaults. Stay within 500 characters; treat this as a decision brief, not a landing page.
  • Required for readiness
  • Maximum 500 characters
  • Cover: what it does, who it is for, key constraints, when not to use it if that clarifies fit
  • Focus on functionality and selection criteria, not marketing copy
Pattern that fits the limit:
  1. What it is (one clause)
  2. Who / which stack it serves
  3. When to choose it over peers
  4. Optional: when to prefer something else
Payments example (same category, different fit): 500 characters is enough for selection. Put API depth, edge cases, and long comparisons in your docs URL.

​
Make your tool usable by agents

This section tells agents exactly how to use your tool. Be specific - vague instructions lead to incorrect usage.

​
Languages (prerequisite for quickstart)

Select languages under Help agents discover your tool first. Quickstart tabs appear for each selected language. If no languages are selected, the quickstart editor shows a prompt to select languages in the discovery section.

​
Quickstarts (per language and transport)

Minimal install and usage snippets for each supported language. Required for readiness (at least one language entry). For each language tab: Notes:
  • Quickstart entries are tied to selected languages. Removing a language prunes entries for that language on save. Multiple entries can use the same language when they represent different SDKs or transports.
  • Install commands should be a standard package-manager line (npm, pnpm, yarn, bun, pip, uv, cargo, go, gem, composer, docker, mvn, gradle, dotnet, mix, swift, flutter, and other common package managers) or a declarative dependency snippet (Maven <dependency>, <PackageReference />, Gradle implementation(...), Elixir {:package, "~> 1.0"}). Commands using shell operators such as pipes, sudo, or curl fail deployment verification.

​
What does this tool take as input? (Input shape)

Describe parameters, types, and what is required vs optional.
  • Optional
  • Maximum 2000 characters
  • Example: { url: string; method?: 'GET' | 'POST' }

​
What does this tool return? (Output shape)

Describe the response shape an agent should expect, including success and error cases when useful.
  • Optional
  • Maximum 2000 characters
  • Example: { success: boolean; data: any }

​
Common pitfalls

Gotchas or mistakes that are easy to miss in official docs (rate limits, auth edge cases, async behavior, and similar).
  • Optional
  • Maximum 20 pitfalls
  • Maximum 300 characters per pitfall
  • Use the Add pitfall / Remove controls in the form

​
Help agents discover your tool

Helps agents find your tool when searching. Prefer accuracy over volume.

​
Tags

Keywords that help agents retrieve your tool for the right problems and constraints. Prefer how developers search over internal feature names.
  • Optional
  • Maximum 15 tags
  • Maximum 30 characters per tag
  • Tags are lowercased automatically
  • Avoid repeating category names as tags
  • Good examples: merchant-of-record, subscriptions, webhooks, self-hosted
  • Weak examples: best, powerful, next-gen, generic praise words

​
Categorization

Accurate categorization improves filter and ranking quality in search.

​
Sources

Supporting links that help agents verify details and point users to the right place. Leave blank if a link does not apply. When provided, each must be a valid URL.

​
Fields reference (summary)

​
Best practices

  • Lead with capability and choose-when signals, not generic praise.
  • Assume agents know a category default - say when your tool is the better fit.
  • Write quickstarts that agents can copy and run with minimal setup.
  • Document real input and output shapes instead of vague prose.
  • Call out non-obvious pitfalls (auth, rate limits, pagination, async behavior).
  • Use constraint-aware tags (subscriptions, self-hosted) instead of broad labels.
  • Prefer canonical docs and repository URLs over marketing pages when possible.

​
Review before saving

  • Check that the slug is stable and readable.
  • Make sure the description explains what the tool does and when to choose it, not only why it is great.
  • Confirm each selected language has a usable quickstart when you plan to deploy.
  • Keep categories, tags, languages, and frameworks aligned with the real integration surface.
  • Skim the listing as an agent would: could you shortlist this next to peers from the tagline and description alone?

​
Next steps