StartupHub.ai

Request a listicle test

request_listicle_test

Ask StartupHub.ai to test a product and add it to one of its lists (the "best X" roundups at startuphub.ai/ai-news/reviews). Free in the standard queue (two tests a week). A priority test ($400, run within 14 days) or a private pre-test ($1,500, never published) returns a payment link for a person to pay. The vendor must give a working trial account; it is stored encrypted and never shown. The test runs unannounced with the same kit as every other tool on the list, a fee never changes a score or a position, a low score never removes an entry (the vendor may post one response), and a free re-test follows three months later. Read https://www.startuphub.ai/tested first. Returns the request id and its status page. Free, no credits. Needs a StartupHub.ai API key with credit (pay as you go).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "list_url": "<list_url>",
      "company_name": "<company_name>",
      "website": "<website>",
      "pitch": "<pitch>",
      "contact_name": "<contact_name>",
      "contact_email": "<contact_email>",
      "trial_login": "<trial_login>",
      "trial_notes": "<trial_notes>",
      "agree": "<agree>"
    },
    "name": "request_listicle_test"
  }
}

Input Schema

Name	Required	Description
`agree`	Yes	true: the account owner accepts the agreement at https://www.startuphub.ai/tested#agreement
`order`	No	standard (free), priority ($400) or pretest ($1,500, private)
`pitch`	Yes	What the product does, 40 to 600 characters, plain text
`website`	Yes	The product website
`list_url`	Yes	The list page URL or slug on startuphub.ai the product should join
`trial_login`	Yes	Login details for the trial account (URL, email, password or API key). Stored encrypted.
`trial_notes`	Yes	What the trial includes: plan level, limits, anything switched on for the test
`company_name`	Yes	The product or company name
`contact_name`	Yes
`contact_email`	Yes	A work address the editor can reach
`trial_expires_at`	No	YYYY-MM-DD; the account must stay valid 45 days
`free_tier_available`	No	Whether the product has a free tier (the kit also runs on a fresh free account when it does)

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations: payment-link flow for paid orders, encrypted and never-displayed credentials, an unannounced test with a uniform kit, a fee never affecting score or position, a low score never removing an entry, one vendor response allowed, and a free re-test after three months. It also states the return value and the billing/auth requirement (API key with pay-as-you-go credit).

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?

Purpose and pricing are front-loaded and every clause carries a distinct fact (pricing, credential handling, editorial independence, return value). It is a dense paragraph rather than structured, which makes the policy caveats slightly harder to scan.

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 12-parameter, non-read-only request tool with no output schema, the description covers who does what, cost tiers, credential handling, editorial rules, and what is returned (request id and status page). Nothing an agent needs to call it responsibly 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 already 92%, so the schema carries most of the load. The description still adds meaning by explaining why trial_login/trial_notes matter (encrypted storage, never shown, same kit as every other tool) and by tying 'agree' to the agreement it references.

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

Purpose4/5

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

States a specific verb and resource: ask StartupHub.ai to test a product and add it to one of its 'best X' roundups, with a concrete URL. It is clearly distinguishable from submission siblings like submit_product or submit_list, though it never names an alternative explicitly.

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

Usage Guidelines4/5

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

Gives the prerequisites plainly: read the /tested page first, supply a working trial account, and pick between standard (free, two a week), priority ($400, 14 days) and private pre-test ($1,500). It does not state when an agent should choose submit_product or submit_list instead of a paid test request.

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

All StartupHub.ai 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?