Skip to main content
Glama

WhatAreYouBuilding.AI

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. One product per builder, and 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

TableJSON 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?

Annotations only cover the safety profile (not read-only, open-world, non-idempotent, non-destructive); the description adds far more: an auth token is required and the call refuses without it, the result is created as PENDING and reviewed, the return is an id plus status 'pending' rather than a live listing, one product per builder, and duplicates are refused by website host or name. That is exactly the beyond-annotation context the dimension asks for.

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 correctly — purpose, then auth requirement, then outcome, then field guidance. It is long, but the complexity (15 params, nested objects) justifies most of it. Some duplication costs it a point: 'Do not call it to add somebody else's product' is restated as 'Submit the builder's OWN product', and 'never a live listing' is restated as 'Do not report it as published'.

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 mutation with nested objects and no output schema, the description still tells the agent what comes back (an id and a 'pending' status) and warns against misreporting it. Nothing needed to call the tool correctly appears to be 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% and the schema descriptions are themselves unusually rich, so the baseline is 3. The description still adds meaning the schema does not: the closed-vocabulary values are rejected rather than corrected, and funding fields are tri-state with an explicit instruction not to infer or to use false as a stand-in for 'did not say'.

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 and resource ('Add a product to the directory') and immediately qualifies it with the actor scope ('on behalf of the builder whose agent token this call carries'). That scope framing cleanly separates it from read-side siblings like get_product and search_products.

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 positive triggers ('when the person you are working for has asked to be listed here') and explicit negative ones ('Do not call it to add somebody else's product, and do not call it speculatively'). It also names a prerequisite tool call — list_filters first — which is the kind of routing guidance agents usually have to guess at.

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