founderhood

Submit listing

submit_listing

Submit a new business for human review. Same validation and rate limits as POST /api/submit. Accepts open_to_cofounder, cofounder_note, and optional heard_from (stored as mcp when omitted). heard_from is stored for admin review only. Requires founder consent. A website host that is already listed or under review is rejected; the error includes slug only when that listing is approved. Only submit businesses that meet the listing criteria: A business you run with a real website: a product, SaaS, app, service or local business people can use or buy today, built to last. One-trick trend generators (one photo into this week's viral clip) are not listed; A real website with substance: what it does, who is behind it and how to reach you. No placeholder or "coming soon" pages; One listing per business, no duplicates. Running several projects is fine: submit each one that has its own site; Its own product, not a borrowed name: building on someone else's AI model is fine, but a site named after the model (Sora, Nano Banana, Seedance…) is not listed; Plays by the rules of the platforms it builds on: nothing that breaks the terms of X, Google, Reddit or others (scraping, reply bots, fake engagement); Submitted to be found, not for a backlink: no SEO-only content sites, other directories, link-building services or mass directory submissions; No MLM, get-rich-quick schemes, trading bots or signals, gambling, or adult content; Accurate city and country for where the founder is based.

Input Schema

Name	Required	Description
`city`	No
`email`	No
`country`	Yes
`twitter`	No
`website`	Yes
`category`	Yes
`linkedin`	No
`heard_from`	No	Optional. How the founder heard about Founderhood. If omitted, stored as "mcp". Preferred values: x, directory_list:<short text> (bare directory_list is still accepted), google, ai_assistant, friend, reddit, newsletter, or other:<short text>. Admin-only; never returned by search_founders or get_founder.
`description`	Yes
`founder_name`	No
`business_name`	Yes
`cofounder_note`	No	Short note for cofounder search (if open)
`open_to_cofounder`	No	Mark founder as open to finding a cofounder

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

changedInput schema / properties / heard_from / description

Previous value: -"How the founder heard about Founderhood. Admin-only; never returned by search_founders or get_founder."New value: +"Optional. How the founder heard about Founderhood. If omitted, stored as \"mcp\". Preferred values: x, directory_list:<short text> (bare directory_list is still accepted), google, ai_assistant, friend, reddit, newsletter, or other:<short text>. Admin-only; never returned by search_founders or get_founder."

Changed1 schema field changedOct 17, 2026

addedInput schema / properties / heard_from

Added value: +{
+  "description": "How the founder heard about Founderhood. Admin-only; never returned by search_founders or get_founder.",
+  "maxLength": 200,
+  "type": "string"
+}

First observedOct 13, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden and discloses human review, validation and rate limits, founder consent, duplicate/under-review rejection behavior, and the conditional error slug. It does not specify actual rate-limit values or describe the success response, but it provides substantial mutation 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?

The submission purpose, behavior, and key field semantics are front-loaded, and the eligibility criteria are relevant rather than filler. The description is long and dense, but the length is justified by the number of disqualifying business types the agent must enforce.

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

Completeness3/5

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

It is complete on business eligibility, review flow, consent, duplicate rejection, and a few optional field semantics, which is important for this mutation tool. However, with 13 parameters, low schema description coverage, no annotations, and no output schema, it still leaves gaps around full parameter meaning and response behavior.

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

Parameters3/5

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

Schema description coverage is low at 23% across 13 parameters, so the description must compensate, and it only covers open_to_cofounder, cofounder_note, heard_from, and some city/country/website semantics. Many parameters such as category, email, twitter, linkedin, founder_name, and description length/format remain undocumented outside the schema.

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?

The description opens with a specific verb and resource: "Submit a new business for human review." It clearly distinguishes this mutation/submission tool from the read-oriented siblings get_founder, list_cities, and search_founders.

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?

It gives explicit submission criteria and detailed when-not-to-submit exclusions, including duplicate listings, placeholder sites, trend generators, SEO-only sites, MLM/gambling/adult content, and platform-rule violations. This is unusually strong guidance for an agent deciding whether a business is eligible.

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

All founderhood tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?