Find the startup credits, perks and deals a company qualifies for, across 1,000+ cited programs.
Scored across 3 tools
The three tools have clearly distinct purposes: find_startup_perks ranks programs against a company profile, search_startup_perks looks up providers/topics without a profile, and get_startup_perk returns full terms for one program. Each description explicitly states when to use the alternatives, leaving little room for misselection.
All three names follow a predictable verb_noun pattern around the same domain object (find_startup_perks, search_startup_perks, get_startup_perk). The only minor deviation is the singular 'perk' in get_startup_perk versus plural 'perks' elsewhere.
Three tools is well-scoped for a read-only startup-perks catalog: discovery, lookup, and detailed terms each earn their place. There is no redundant or trivial tool padding the surface.
The surface covers the core discovery lifecycle: finding qualified perks, searching the catalog, and inspecting full program terms. Minor gaps exist, such as no explicit category-enumeration or side-by-side comparison operation, but agents can work around these via search and ranking results.
Rank the startup credits, perks and deals one specific company can claim, from a catalog of 2,800+ programs (AWS Activate, Google for Startups, Microsoft for Startups, NVIDIA Inception, Anthropic, Stripe Atlas, Mercury, HubSpot and more). Use it when the user describes their own startup and asks what they can get or qualify for; use search_startup_perks to look up a provider or topic without a company profile, and get_startup_perk for one program's full terms. It checks each program's stated eligibility (stage, funding gate, raised-amount cap, company age, region) against the profile, ranks the categories the user needs first and takes each need in turn, and leaves out programs whose applications are paused or closed. Returns up to 25 programs, each with the value as the provider states it, whether the company qualifies and why, how to claim it, and a link to the StartupPerks page (where to check the full terms and apply; a direct apply link where StartupPerks has one), plus a realistic claimable total (one program per provider, cloud counted once). Read-only; values are headline maximums, not guarantees.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many programs to return (default 10). | |
| needs | No | Perk categories the startup wants, ranked above everything else: cloud-infra (Cloud & Infrastructure), databases-data (Databases & Data), ai-ml (AI & ML), banking-fintech (Banking & Fintech), finance-ops (Finance & Ops), dev-tools (Developer Tools), productivity-saas (Productivity & SaaS), marketing-sales (Marketing & Sales), security-legal-hr (Security, Legal & HR). Omit for all categories. | |
| stage | No | Company stage. | |
| region | No | Where the company is based: a country, city or region such as "US", "UK", "Germany", "EU", "India" or "Singapore". | |
| funding | No | How the company is funded: bootstrapped (no outside investors), vc-backed (angel or VC money), or accelerator (in an accelerator or incubator portfolio). | |
| priority | No | Ranking emphasis: balanced (default), value (biggest benefit first), eligibility (easiest to qualify first), reputable (best-verified first). | |
| provider | No | Only programs from this provider, e.g. "AWS", "Google Cloud", "Stripe". Leave empty unless the user asked about a specific provider. | |
| raised_usd | No | Total outside funding raised so far, in USD (0 if none). Programs with a raised-amount cap are checked against it. | |
| description | No | The startup in the user's own words, e.g. "pre-seed AI startup in Berlin, bootstrapped, needs GPU credits and a business bank account". Anything not given in the structured fields below is read from this text. | |
| include_gated | No | Also include referral-only and accelerator-only programs the startup may not reach on its own. | |
| only_qualifying | No | Only return programs the startup fully qualifies for. | |
| company_age_years | No | Years since the company was founded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description still adds substantial behavior: eligibility dimensions checked (stage, funding gate, raised-amount cap, company age, region), needs-first ranking, exclusion of paused/closed programs, a 25-result ceiling, dedup rules ('one program per provider, cloud counted once'), and the caveat that values are headline maximums not guarantees.
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 routing are front-loaded and most sentences carry information. The parenthetical provider roster (AWS Activate, Google for Startups, NVIDIA Inception, Stripe Atlas, Mercury, HubSpot...) is longer than needed to convey scope, and the single dense block would scan better split into routing/behavior/returns.
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 12-parameter tool with no output schema, the description covers the eligibility model, ranking order, exclusions, result cap, per-result payload (value, qualify + why, how to claim, link) and the claimable-total caveat. An agent has everything needed to call it correctly and describe results to a user.
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 baseline is 3, but the description adds real meaning by mapping the eligibility logic onto specific parameters (stage, funding, raised-amount cap, company age, region) and explaining that 'needs' drives category ranking. It does not explain the priority enum tradeoffs or include_gated/only_qualifying interaction beyond what the schema says.
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 startup credits/perks/deals a given company can claim from a 2,800+ program catalog — and names the two sibling tools and how they differ. An agent can distinguish it from search_startup_perks and get_startup_perk 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 an explicit trigger ('when the user describes their own startup and asks what they can get or qualify for') and explicit alternatives with their selecting conditions ('search_startup_perks to look up a provider or topic without a company profile', 'get_startup_perk for one program's full terms'). Routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full terms of one startup program. Use it after find_startup_perks or search_startup_perks by passing the slug from a result's details_url, or with a program or provider name when the user asks about one program (for example "What are the terms of AWS Activate Founders?"). Returns what the program gives, every eligibility gate (stages, funding requirement, raised-amount and company-age caps, regions), other requirements, expiry, how to claim, the application status and when it was last verified, the StartupPerks page to apply from (and a direct apply link where StartupPerks has one), up to 3 open alternatives from other providers in the same category, and the category guide. Returns an error when nothing matches; search_startup_perks can then find the program. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The program or provider name when no slug is known, e.g. "NVIDIA Inception". | |
| slug | No | The program's StartupPerks slug or page URL, as returned in details_url by the other tools (e.g. "aws-activate-founders-package"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent/non-destructive, and the description adds substantial context on top: the error-on-no-match behavior, that results include eligibility gates, expiry, claim steps, application status, last-verified time, apply links, and up to 3 alternative programs. With no output schema, this return-content disclosure is exactly the burden the description should carry.
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?
One front-loaded paragraph that opens with the outcome, then routing, then return payload — no filler sentences. The return-field enumeration is long, but with no output schema each item is doing work; slight trimming of the parenthetical apply-link detail would tighten it.
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 two-optional-parameter read tool with no output schema, the description covers routing, fallback behavior, error case, and returned fields. The one gap is that both parameters are optional and it never states what a zero-argument or both-arguments call does, which an agent needs to know before invoking.
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 baseline is 3, but the description adds real semantics: the slug provenance (details_url) and the precedence rule that name is the fallback "when no slug is known", with realistic example values. It stops short of saying what happens if both are supplied, so not a 5.
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 ("Return the full terms of one startup program") and immediately contrasts with the sibling list/search tools that produce the identifier it consumes. An agent can distinguish it from find_startup_perks and search_startup_perks 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 explicit routing rules: call after find_startup_perks/search_startup_perks with the slug from details_url, or use a name when the user asks about a single program, with a concrete example query. It also names the recovery path ("Returns an error when nothing matches; search_startup_perks can then find the program"), which is a when-not condition plus alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the catalog of 2,800+ startup programs by provider, program or topic. Use it for questions like "Does Stripe have a startup program?" or "Which providers give GPU credits?", or to browse a category, a benefit type, or programs open to any startup without investor or accelerator backing; use find_startup_perks instead when the user wants what a specific company qualifies for. A provider or program name returns only programs that carry that name; a topic (CRM, banking, GPU, payroll) also matches the category that covers it, and rarer words weigh more. Programs whose applications are paused or closed are left out. Returns up to 25 programs with the stated value, the primary eligibility gate and links, plus a page to browse more. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many programs to return (default 10). | |
| query | No | A provider, program or topic, e.g. "AWS Activate", "Stripe", "GPU credits", "free CRM", "business bank account". Leave empty to list by filters only. | |
| category | No | Limit to one category. | |
| benefit_type | No | Limit to one kind of benefit. | |
| min_value_usd | No | Only programs whose stated value is at least this many USD. | |
| open_to_any_startup | No | Only programs with no investor, accelerator or referral requirement. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, and the description still adds substantive context: paused or closed programs are omitted, provider/program names match only programs carrying that name while topics also match the covering category, rarer words weigh more, and results are capped at 25 with a page link. These are non-obvious retrieval behaviors an agent could not infer from the annotations or schema.
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 usage examples are front-loaded, and the matching rules and result shape follow in logical order. The middle sentence is a dense semicolon-chained run-on that takes a second pass to parse, but no sentence is 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?
For a six-parameter search tool with no output schema, the description supplies what the agent needs: how matching works, what is filtered out, and what a result row contains (stated value, primary eligibility gate, links, plus a page to browse more). Nothing material is left to inference.
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 baseline is 3, and the description genuinely adds meaning beyond it: it explains how the query string is interpreted (name match vs topic-to-category expansion, rare-word weighting) and clarifies that open_to_any_startup means no investor, accelerator or referral requirement. It does not restate the limit, min_value_usd or enum semantics, but those are already well documented in the schema.
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 opens with a specific verb and resource ("Search the catalog of 2,800+ startup programs") and names the facets it searches over (provider, program, topic). It explicitly routes the agent away from the sibling find_startup_perks for the alternate case, so the tool is distinguishable 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?
Concrete example questions ("Does Stripe have a startup program?", "Which providers give GPU credits?") plus browsing scenarios (category, benefit type, open-to-any-startup) cover the main intents. The exclusion is explicit: use find_startup_perks when the user wants what a specific company qualifies for.
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.
find_startup_perksget_startup_perksearch_startup_perksStartup credits, programs and perks from checked sources, with saved plans and reported balances.
Search 470+ verified startup deals, discounts and credits on SaaS tools, with claim links.
Find and win startup funding: programs, investors, perks, and an AI autopilot for applications
Search startups and founders, match companies to products, and manage outreach lists.
Add one secure layer between your agents and this server.
