Skip to main content
Glama

Submit a product to the directory

submit_product

Add a product to the directory on behalf of the builder whose agent token this call carries. Call this when the person you are working for has asked to be listed here, or has asked you to add a product they built. Do not call it to add somebody else's product, and do not call it speculatively — a listing is a public claim about a real builder. REQUIRES A TOKEN: send Authorization: Bearer wayb_…. A builder creates one at /mine while signed in; without it this tool refuses and every other tool here still works. The listing is created as PENDING and is reviewed before it appears — a successful call returns an id and a status of "pending", never a live listing. Do not report it as published. Submit the builder's OWN product. A builder can list more than one product, but the directory refuses a second copy of a product it already lists (by website host or by name) with a message saying so. Call list_filters first: category and region are closed vocabularies, and a value outside them is rejected rather than corrected. Funding fields are optional and tri-state — omit activelyRaising, or send null, where the builder has not said. Do not infer it, and do not send false to mean "did not say".

Input Schema

NameRequiredDescriptionDefault
mrrNoMonthly recurring revenue, only where the builder chose to publish it.
cityNoCity, or null.
nameYesThe product name, up to 80 characters.
openToNoWhat the builder invited contact about. Omit for none.
regionYesREQUIRED. Country name from list_filters. Closed vocabulary. Use "Global" where the builder is not anywhere in particular or would rather not say — that is a real answer on this list, and it is the one to send rather than guessing a country or omitting the field.
builderYesAttribution. `name` is required; the rest is optional.
logoUrlNoAn https URL to a square logo, or null.
socialsNoThe PRODUCT's own accounts, keyed by platform — not the builder's, which go under `builder.socials`. Keys: `x`, `linkedin`, `instagram`, `tiktok`, `youtube`, `facebook`, `github`, `email`. Each is `{ "url": "…" }` except `x`, which is `{ "handle": "…" }`, and `email`, which is `{ "address": "…" }` and should be a business address (support@, hello@) rather than a person's. `github` is the PRODUCT's repository — the code somebody would clone. The builder's own GitHub account is a different thing and goes in `builder.socials.github`.
categoryYesREQUIRED. The product's MAIN category, from list_filters. Closed vocabulary. This is the one a row, a card and the sharing image show.
oneLinerYesOne sentence saying what it does, up to 80 characters. Not a tagline.
categoriesNoOptional. Up to 3 categories from list_filters, MAIN FIRST — for a product that is honestly more than one thing (an AI agent that is also a dev tool). The first must be the same value as `category`; send it first or leave it out of the list and it is put there. A listing is findable and filed under all of them, so send only the ones the builder would claim: three loosely-related categories are worse for them than one true one. Ask the builder rather than inferring from their site.
websiteUrlYesREQUIRED. The product's own https URL — the address a reader opens. A code repository or an app store page counts. REFUSED: a shared document (Drive, Docs, Dropbox, Notion), and a free platform deploy subdomain (vercel.app, netlify.app, github.io, web.app, railway.app and the like) — the builder needs a domain of their own first. Never invent one: ask the builder.
descriptionYesREQUIRED, up to 800 characters. A short paragraph in the builder's OWN words about what the product is and who it is for, shown on the listing's own page. Plain text — links are not rendered, so put the address in websiteUrl. Never write it yourself, and never pad it to a length: ask the builder for it, the way you would ask for the URL. A short answer in their words is worth more here than a long one in yours. It became required on 2026-09-03 because a listing without one has nothing on its page a search engine can tell apart from every other listing.
fundingStageYesFunding stage. Use "undisclosed" where the builder has not said — never guess.
activelyRaisingNotrue, false, or null for "would rather not say". Default null.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well past the annotations: requires an Authorization bearer token and states what happens without it, discloses that the listing is created PENDING and reviewed, warns 'Do not report it as published', and describes duplicate refusal by host or name. For a non-idempotent, open-world write tool this is exactly the missing context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and the token requirement, and nearly every sentence carries a rule the agent needs. It is longer than necessary in places — 'Submit the builder's OWN product' restates an earlier prohibition, and the token/duplicate material could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter, nested-object mutation with no output schema, the description covers auth, the pending-not-published return shape, duplicate handling, vocabulary closure and the data-provenance rules (never invent a URL, never write the description). Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds cross-parameter semantics the schema states only locally — closed vocabularies being rejected rather than corrected, and the tri-state funding rule (omit or null, never false for 'did not say'). It also reinforces builder-vs-product attribution, though some of that duplicates schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Add a product to the directory') and immediately scopes it to the builder represented by the calling token. This cleanly separates it from siblings like search_products, get_product and fetch, which are all read paths.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when ('the person you are working for has asked to be listed'), explicit when-not ('do not call it to add somebody else's product', 'do not call it speculatively'), and a concrete prerequisite (call list_filters first because category/region are closed vocabularies).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources