Skip to main content
Glama

run_tracxn_unicorns_search

List unicorn startups by country from Tracxn Unicorn Club, with rank, funding, investors, and join date. Sorted newest first.

Instructions

List the unicorn startups of a country from Tracxn Unicorn Club (newest first): rank, name, description, founded year, location, stage, sectors, time to unicorn, top investors, employees, total funding, join date. 1 point per returned record.

Input Schema

NameRequiredDescriptionDefault
countryYesCountry. e.g. India
max_itemsNoMax items (up to 250)
start_pageNoStarting page

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.1

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It adds real context beyond the name: the source table, newest-first ordering, the exact field set returned, and the cost model ("1 point per returned record"). It omits pagination behavior, whether max_items bounds billing, and any permission requirements.

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?

A single front-loaded sentence: verb + resource + source first, then the returned fields. The long field enumeration is dense but earns its place because no output schema exists. No filler.

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

Completeness4/5

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

With no output schema and no annotations, the enumerated return fields are the only documentation of results, and the description supplies them, which is exactly what is needed. Gaps remain around pagination and billing interaction with max_items.

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 100%, with country, max_items and start_page all documented including bounds, so the schema does the heavy lifting and a 3 baseline applies. The description contributes "newest first" ordering context relevant to start_page but nothing else parameter-specific.

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?

The description names a specific verb and resource ("List the unicorn startups of a country") and identifies the data source ("Tracxn Unicorn Club"), which cleanly separates it from generic siblings like run_tracxn_companies_search. It does not explicitly route against those siblings, so it stops short of a 5.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: an agent can infer you call this to enumerate unicorns for one country, and "newest first" hints at ordering intent. There is no explicit when-to-use, when-not-to-use, or named alternative among the many tracxn_* siblings.

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

Deploy Server

Other Tools