A catalogue of indie products, not a registry of MCP servers. Reading needs no credential.
Scored across 9 tools
Tools have distinct core purposes, but there are two parallel retrieval paths: generic search/fetch versus specific search_products/search_communities and get_product/get_community. The descriptions explicitly distinguish them with do/don't guidance, so an attentive agent can select correctly, though the overlap creates some risk.
Mostly consistent snake_case verb_noun pattern (get_product, search_products, submit_product). Two tools, fetch and search, are bare verbs without a noun, a minor deviation from the otherwise predictable pattern.
Nine tools is well within the sweet spot and each covers a distinct capability: discovery, targeted search, retrieval, filters, leaderboard, and submission. No tool feels redundant or missing from the core scope.
The read surface is robust (search, specific search, get, fetch, filter, leaderboard) and supports product submission, but there is no update/delete/withdraw for listings and no community submission path. These are minor gaps that can be handled through the website or future work.
Fetch the full text of one directory record by an id returned from search. Ids are prefixed to say which collection they belong to: "product:" or "community:". Call this after search, on the ids it returned, when the lightweight result is not enough to answer the question. It is the second half of the search/fetch pair that deep-research clients expect. Do not call it with an id you constructed yourself or took from a URL — use get_product or get_community for those, which take a bare id and return structured fields instead of text. Prose in, prose out: this returns a readable record, not a typed object.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A prefixed id from search, e.g. "product:unkey". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, non-destructive and closed-world, so the safety profile is handled. The description adds genuinely new behavioral context: the output is untyped prose rather than a structured object, and ids must originate from search rather than be hand-constructed. It stops short of mentioning truncation, size limits, or pagination on long records.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core action and the search-pairing rule are front-loaded, and each subsequent sentence carries distinct information (prefix vocabulary, exclusion, return type). It runs slightly long at six sentences, but none are filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by stating the return shape ('prose in, prose out ... a readable record, not a typed object'). Combined with rich annotations, a single fully-documented parameter, and explicit sibling routing, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the single id parameter, so the baseline would be 3. The description adds meaning the schema does not: the two prefix namespaces ('product:<id>' or 'community:<id>') that determine which collection is queried, plus the provenance rule that the id must come from search output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetch the full text of one directory record') plus the scoping constraint that the id must come from search. It explicitly differentiates itself from siblings get_product and get_community by contrasting bare-id structured lookups against prefixed-id prose fetches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('call this after search, on the ids it returned, when the lightweight result is not enough') and an explicit when-not-to-use ('Do not call it with an id you constructed yourself or took from a URL'), naming the alternative tools for that case. Both the trigger and the exclusion are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one community by its directory id, including its join link, platform, region, topic and member count where one was given. Call this to answer a specific question about one group, or after search_communities when a shortlist needs the join links filled in. Do not call it to discover communities: it takes an id and nothing else. Search first. An unknown id returns not-found rather than a guess.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Community id, e.g. "indie-tlv". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, non-open-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: an unknown id returns not-found rather than a guess, and the tool accepts only an id. Return format/pagination is not described, which is the only real gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with what is retrieved, then usage, then the exclusion. Four tight sentences with no filler; the anti-pattern warning is placed where it matters most.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly enumerates the returned fields, plus the not-found behavior for unknown ids. For a single-parameter read tool this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema itself supplies an example ('indie-tlv'), so the baseline is 3. The description adds a real constraint beyond the schema: 'it takes an id and nothing else', telling the agent no other filters are accepted on this path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Retrieve one community by its directory id') and enumerates the returned fields (join link, platform, region, topic, member count). It also contrasts itself against search_communities, so an agent can distinguish it from siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('to answer a specific question about one group', or after search_communities to fill in join links) and explicit when-not ('Do not call it to discover communities... Search first'). The alternative tool is named, and the ordering constraint is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank products by engagement on the directory — upvotes, outbound clicks, impressions, shares or verified backlinks — optionally narrowed to one region or category to get a sub-league. Call this for any question about relative standing: what is getting attention, what is doing well in a country or category, what to look at first in an unfamiliar segment. Two orderings, and they answer different questions. sort=score (the default) ranks on the lifetime counter and answers "what is biggest" — it is stable, and a listing collecting clicks for six months outranks one that arrived on Tuesday. sort=movers ranks on clicks gained during the LAST COMPLETED WEEK and answers "what is happening"; it is the only view where something new can be first, and it is the right call for "what is rising", "what is new", or "what changed this week". Be careful what you claim from it. This is attention on this directory and nothing else — not revenue, not users, not growth, and not a judgement about quality. MRR is never a ranking axis here. A product can rank highly because it was interesting to click on. Nothing on this board is bought: no badge, streak or payment moves a listing up it. The movers board describes the week that closed last Sunday, not the last seven days, and the week field in the response names it — do not report it as live. Listings with no reading a week ago are not in it at all; the unmeasured count says how many that was. metric=backlinks is different in kind from the browsing axes: it ranks people who link back to their listing from their own site, scored on the traffic that link actually sent (stats.referrals) and counted only where our crawler independently found the link. Use it for "who is actually promoting their listing" rather than "who is getting attention here". A listing with referrals but backlink.verified false scores zero on it. Do not call it to filter or find products by their attributes; that is search_products. The board is empty until real engagement accumulates, and an empty board means no traffic yet, not that no products exist.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | score ranks on the lifetime counter (default). movers ranks on clicks gained during the last completed week — use it for what is rising rather than what is biggest. | |
| limit | No | How many ranks to return. Defaults to 10. | |
| metric | No | Ranking axis for sort=score. Defaults to clicks. upvotes is the only axis a person chooses rather than one measured from browsing — one vote per person per listing per week, so it ranks distinct backers. backlinks ranks on referred visits arriving through a crawler-verified link on the builder's own site. Ignored when sort is movers, which is always clicks gained in the week. | |
| region | No | Country name, e.g. "Israel", "United States", "Nigeria". Case-insensitive. Omit for all regions. | |
| category | No | Narrow to one category. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: it states the board measures directory attention only, not revenue/users/growth/MRR; that no payment or badge affects rank; that movers covers the last completed week rather than the last seven days and that the `week` field names it; and that an empty board means no traffic yet rather than no products. These are exactly the interpretive traps an agent would otherwise fall into.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well front-loaded and organized, with purpose first, then ordering, then caveats, then exclusions. However it is long and makes the same 'attention only, not revenue' point three separate ways ('not revenue, not users, not growth', 'MRR is never a ranking axis here', 'no badge, streak or payment moves a listing up'), which costs it conciseness credit despite the useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by naming response fields that matter (`week`, `unmeasured`) and explaining what an empty board means. For a 5-parameter, enum-driven ranking tool, an agent has everything needed to call it and to interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already defines every parameter and the baseline is 3. The description adds real meaning on top: that metric is ignored under sort=movers, that a listing with backlink.verified false scores zero, and that MRR is never a ranking axis — semantic constraints the schema does not carry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('rank products by engagement on the directory') and enumerates the exact axes (upvotes, outbound clicks, impressions, shares, verified backlinks). It explicitly carves itself away from the sibling search_products ('Do not call it to filter or find products by their attributes'), so an agent can distinguish it without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit use trigger ('Call this for any question about relative standing'), a named alternative for the excluded case (search_products), and disambiguates the two orderings by question type — sort=score for 'what is biggest' vs sort=movers for 'what is rising/what changed this week'. The when-not guidance is as strong as the when guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one product by its directory id, with full builder attribution, links, funding state and engagement stats. Returns strictly more per record than a search result: the builder's own accounts and the product's, the website, the city, opt-in MRR where the builder published one, and all-time clicks and impressions. Call this to answer anything specific about a single product — how to reach the builder, where they are, whether they are raising, what the listing actually claims — and call it once per product after a search when a shortlist needs filling out. Do not call it to discover products: it takes an id and nothing else, so it cannot answer "find me X". Search first. Ids are the slug in the product URL, not the display name. An unknown id returns not-found rather than a guess.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Product id, e.g. "unkey". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds genuinely new behavior: an unknown id returns not-found rather than guessing, and the record carries more fields than a search hit (builder accounts, website, city, opt-in MRR, all-time clicks/impressions). It stops short of describing auth, rate limits, or pagination, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the returned-field summary are front-loaded, then usage guidance, then the id-format caveat and error behavior. It is somewhat long at six sentences with mild redundancy between "anything specific about a single product" and the field enumeration, but every sentence carries actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the return-value burden and does so by enumerating the notable fields (attribution, links, funding state, engagement stats). Combined with the not-found behavior and id-format rule, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is already documented with an example, so the baseline is 3. The description goes further by clarifying that ids are the slug in the product URL, not the display name, and that the id is the only accepted input, adding real disambiguation value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Retrieve one product by its directory id") and immediately scopes it against the sibling search_products by declaring it returns strictly more per record than a search result. An agent can distinguish this from search_products and fetch without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ("anything specific about a single product", filling out a shortlist after a search) and explicit when-not-to-use ("Do not call it to discover products... it cannot answer 'find me X'. Search first."). The alternative tool is named and the condition that selects it is spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every region, category, funding stage and platform that currently has listings, with counts. Call this before the first search of a conversation, and whenever a filter value is in doubt. The vocabularies are closed and curated — a region or category that is not on this list matches nothing, and an empty result from a guessed filter is indistinguishable from a genuinely empty directory. The counts are also the fastest way to see the shape of the directory: which markets are represented, where the listings actually are, and which filters are worth offering someone. Takes no arguments and is cheap. There is no reason to avoid calling it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to add the traits that matter here: the vocabularies are closed and curated, an off-list value matches nothing, and a guessed-filter empty result is indistinguishable from a genuinely empty directory. That last point is a real behavioral trap the agent would otherwise fall into, and 'cheap, takes no arguments' removes cost anxiety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core instruction and the closed-vocabulary warning are front-loaded, and the 'shape of the directory' framing earns its space. The closing 'Takes no arguments and is cheap. There is no reason to avoid calling it.' slightly overlaps with the earlier guidance, so it is a touch longer than it needs to be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still tells the agent exactly what a call returns (the four filter dimensions plus counts) and what those counts are good for. For a zero-parameter, read-only tool this is complete — nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters the baseline is 4, and the description explicitly confirms 'Takes no arguments,' which is all that can be said. There is no parameter surface left to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (list) and enumerates the exact resources returned — regions, categories, funding stages, platforms — with counts. Its role as the vocabulary/prerequisite tool is unambiguous against siblings like search, search_products, and search_communities, which consume the values this tool produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use triggers ('before the first search of a conversation', 'whenever a filter value is in doubt') and closes the door on hesitation with 'There is no reason to avoid calling it.' No alternative tool is named, but none is needed since this is the only vocabulary-listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across both products and communities at once, returning lightweight results — id, title, url — for retrieval with fetch. Call this when you do not know which collection the answer lives in, or when you are a deep-research client that expects the conventional search/fetch pair. It is deliberately thin: it is the discovery half, and fetch is the other half. Do not call it when you already know you want products or communities specifically — search_products and search_communities take real filters (region, category, funding stage, raising status, platform) and return structured fields instead of prose, which is almost always the better answer. Ids come back prefixed as "product:" or "community:"; pass them to fetch unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to look for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety bar is low. The description adds real behavioral context beyond that: results are deliberately thin and discovery-only, the ids come back prefixed as 'product:<id>'/'community:<id>', and they must be passed to fetch unchanged, which is an operational constraint not in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and return shape, then usage and exclusions, then the id-format footnote. It is longer than strictly necessary — the 'deliberately thin / two halves' framing is repeated — but every sentence carries actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by naming the returned fields, the id prefix convention, and the required follow-up call. For a single-parameter search tool this leaves no gap an agent needs filled before invoking it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter and schema coverage is 100%, so the schema fully documents 'query'. The description adds nothing about query syntax, matching behavior or multi-term handling, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search across both products and communities at once') plus the exact shape of the return ('id, title, url'). It explicitly distinguishes itself from the sibling filters tools, so an agent can select it without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives both when-to-use ('when you do not know which collection the answer lives in', 'deep-research client that expects the conventional search/fetch pair') and explicit when-not, naming search_products and search_communities as the alternatives with the conditions that select them (known collection, need real filters).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search builder communities — the Slack workspaces, WhatsApp groups and meetups that independent builders actually gather in — by free text, region, topic and platform. Each result carries a real join link. Call this when someone wants to reach a scene rather than a person: where founders in a given country talk to each other, which group covers a topic, where to go to meet builders in a region. Do not call it to find products or their builders — that is search_products. Communities and products are separate records; a community is a group of people, not something someone shipped. Member counts appear only where the organisers stated one, so a null count means unknown, not small.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-100. | |
| query | No | Free text matched against name and one-liner. | |
| offset | No | Results to skip, for paging. | |
| region | No | Country name, e.g. "Israel", "United States", "Nigeria". Case-insensitive. Omit for all regions. | |
| category | No | Topic, e.g. "AI", "Fintech", or "General". | |
| platform | No | Where the community lives. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real behavioral content: every result carries a join link, and member counts are only present when organisers stated one, so null means unknown rather than small. It does not discuss pagination or result ordering, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded — what it searches comes first, then when to use it, then the anti-pattern — and every sentence carries routing or data-semantics value. The 'Communities and products are separate records; a community is a group of people, not something someone shipped' sentence partially restates the preceding do-not-call clause, which is the only mild redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by stating that results include a real join link and how to interpret member counts. Combined with the exhaustive when/when-not guidance for a zero-required-parameter search tool, an agent has enough to call it correctly; only paging behavior is left entirely to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters with examples and an enum for platform. The description restates the filter axes ('by free text, region, topic and platform') but adds no syntax, default, or interaction detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Search builder communities') and enumerates exactly what a community is — Slack workspaces, WhatsApp groups, meetups — plus the axes searched (free text, region, topic, platform). It explicitly distinguishes itself from the sibling search_products, so an agent can select it without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete positive triggers ('where founders in a given country talk to each other', 'which group covers a topic', 'where to meet builders in a region') and an explicit negative trigger plus the named alternative: 'Do not call it to find products or their builders — that is search_products.' The routing decision is fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the directory of builder products. Filter by free text, region, category, funding stage, whether the builder is actively raising, and what they are open to. Returns the matching products with their builder attribution and engagement stats. Call this whenever someone wants to find products or the people behind them by any of those axes — "who is building fintech in Nigeria", "indie AI tools whose founders are raising", "what has this person shipped". It is the right tool for deal sourcing and scouting: raising_status and open_to together answer "who wants to hear from an investor", and region is the axis this directory is organised around. Do not call it to rank or compare products by traction — that is get_leaderboard. Do not call it when you already hold a product id; get_product returns more per record. Funding is opt-in: funding_stage may be "undisclosed" and actively_raising may be null, both meaning the builder declined to say rather than that the answer is no.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Result ordering. Defaults to recent. | |
| limit | No | Max results, 1-100. Defaults to 25. | |
| query | No | Free text matched against product name, one-liner, builder name, category, region and city. Every word must match. | |
| offset | No | Results to skip, for paging. | |
| region | No | Country name, e.g. "Israel", "United States", "Nigeria". Case-insensitive. Omit for all regions. | |
| open_to | No | Return only products open to this kind of contact. | |
| category | No | Product category, e.g. "AI", "Fintech", "Dev Tools". Call list_filters for the full list. A listing may carry up to three, and this matches any of them. | |
| funding_stage | No | Funding stage of the product. "undisclosed" means the builder chose not to state a stage; it is not a stage between or below the others, and it does not imply bootstrapped. | |
| raising_status | No | Whether the builder is raising, as three distinct answers. "raising" = they said yes. "not_raising" = they said no. "undisclosed" = they declined to say, which is NOT the same as no and must never be reported as no. Independent of funding_stage. Prefer this over actively_raising. | |
| actively_raising | No | Two-value shorthand for raising_status: true is "raising", false is "not_raising". Neither value returns builders who declined to disclose; ask for raising_status="undisclosed" to see those. raising_status wins if both are sent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only/idempotent profile, so the bar is lower. The description still adds real behavioral context: the opt-in funding caveat that 'undisclosed' and null mean the builder declined to say rather than 'no', and that results carry builder attribution and engagement stats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Reasonably long but well-structured and front-loaded: purpose, then filter axes, then return, then usage rules. The examples and exclusion sentences earn their place; only slight tightening would reach 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter, zero-required search tool with no output schema, the description covers filtering axes, return contents (products with builder attribution and engagement stats), and the subtle tri-state funding semantics. Nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it frames region as the directory's organizing axis and explains that raising_status and open_to together answer 'who wants to hear from an investor', and reinforces the undisclosed semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search the directory of builder products') and enumerates the filtering axes. It explicitly distinguishes itself from siblings get_leaderboard and get_product, so an agent can route correctly without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use with concrete user-phrasing examples, plus when-NOT-to-use with named alternatives ('Do not call it to rank or compare products by traction — that is get_leaderboard', 'when you already hold a product id; get_product'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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".
| Name | Required | Description | Default |
|---|---|---|---|
| mrr | No | Monthly recurring revenue, only where the builder chose to publish it. | |
| city | No | City, or null. | |
| name | Yes | The product name, up to 80 characters. | |
| openTo | No | What the builder invited contact about. Omit for none. | |
| region | Yes | REQUIRED. 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. | |
| builder | Yes | Attribution. `name` is required; the rest is optional. | |
| logoUrl | No | An https URL to a square logo, or null. | |
| socials | No | The 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`. | |
| category | Yes | REQUIRED. The product's MAIN category, from list_filters. Closed vocabulary. This is the one a row, a card and the sharing image show. | |
| oneLiner | Yes | One sentence saying what it does, up to 80 characters. Not a tagline. | |
| categories | No | Optional. 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. | |
| websiteUrl | Yes | REQUIRED. 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. | |
| description | Yes | REQUIRED, 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. | |
| fundingStage | Yes | Funding stage. Use "undisclosed" where the builder has not said — never guess. | |
| activelyRaising | No | true, false, or null for "would rather not say". Default null. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
fetchget_communityget_leaderboardget_productlist_filterssearchsearch_communitiessearch_productssubmit_productCurated, trust-first index of vetted MCP servers — scored tiers, monthly re-verified. Read-only.
The MCP server index that vets servers, not just lists them. Advisory screen before you install.
Quality-ranked, cross-platform directory of AI coding skills, plugins and MCP servers.
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
Add one secure layer between your agents and this server.
