Skip to main content
Glama

RocketList

Hiring statistics

hiring_stats
Read-onlyIdempotent

Aggregate counts over ALL matching public Rocketlist jobs, not a sample: total jobs and companies, the top values by city, country, company, domain (vertical), company stage, work mode (remote/hybrid/on-site), job category and seniority, and published pay with sample sizes. Use it for 'how many', 'which cities/companies hire most', share and pay questions; use search_jobs for the roles themselves.

Questions the Startup Hiring Map can answer (at most one city or country, optionally domain and remote_only) are counted from the same snapshot as getedge.cc/map, so totals match the map exactly (job location; a multi-city role counts in each city). Other filters use the live catalog; the result's source says which.

Takes the same filters as search_jobs except skills, plus:

  • group_by: subset of ['city', 'country', 'company', 'domain', 'stage', 'work_mode', 'category', 'seniority'] (default: all).

  • top: values listed per dimension, 1-50 (default 10).

  • query: free-text over job title, company, location and category. Matched as prefix tokens, so 'engineer' also matches 'Engineering'.

  • domain: exact company industry/vertical, e.g. ['Fintech'].

  • city: substring of the job's city or country.

  • remote_only: keep only remote roles.

  • investor: companies backed by these investors, e.g. ['Index Ventures']. Common aliases resolve ('a16z' finds Andreessen Horowitz). Populated for about 83% of hiring companies, so a company with no recorded investors is never returned when this is set.

  • stage: exact company funding stage from ['Pre-Seed', 'Seed', 'Series A', 'Series B', 'Series C', 'Series D', 'Series D+', 'Series E', 'Series F', 'Series G', 'Growth', 'Public', 'Acquired', 'Bootstrapped'], case-insensitive. About 12% of hiring companies have no stage recorded and are excluded when this is set.

  • min_experience_years / max_experience_years: bounds on the years of experience the role requires at minimum. max_experience_years=5 means 'requires 5 years or fewer'. Only about 56% of jobs state a requirement; the rest are excluded when either bound is set.

  • yc_batch: Y Combinator batches, e.g. ['F26'] or ['Fall 2026'] (W/X/S/F + year). Covers the batches in the reviewed cohort list (currently YC Fall 2026).

  • founder_origin: countries the founders come from (where they grew up or studied), by name or ISO code, e.g. ['Germany'] or ['DE']. Company-level, reviewed for the same cohorts as yc_batch; a company matches if any founder does.

  • near: a place, as an address, a street corner ('3rd and Folsom, San Francisco') or 'lat,lng'. Keeps companies whose office (the reviewed street address on getedge.cc/map) is within radius_m metres (default 1000) or walk_minutes on foot (64 m of straight line per minute). Results carry office_address, distance_m and walk_minutes, nearest first.

  • radius_m / walk_minutes: size of the near area; give one.

Input Schema

NameRequiredDescriptionDefault
topNo
cityNo
nearNo
queryNo
stageNo
domainNo
group_byNo
investorNo
radius_mNo
yc_batchNo
remote_onlyNo
walk_minutesNo
founder_originNo
max_experience_yearsNo
min_experience_yearsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / founder_origin
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Founder Origin"
      +}
    • addedInput schema / properties / near
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Near"
      +}
    • addedInput schema / properties / radius_m
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Radius M"
      +}
    • addedInput schema / properties / walk_minutes
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Walk Minutes"
      +}
    • addedInput schema / properties / yc_batch
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Yc Batch"
      +}
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare the tool is read-only, idempotent, and non-destructive. The description adds substantial behavioral context beyond that: snapshot versus live-catalog behavior, the `source` field, exclusion rules for missing investor/stage/experience data, and coverage percentages that materially affect result interpretation.

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 description is long, but it is front-loaded with purpose and usage before moving into detailed parameter semantics. The density is justified by a 15-parameter tool, though the long list of caveats and parameter notes could be slightly tightened without losing meaning.

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 complex aggregation tool with 15 optional parameters, an output schema, and no schema descriptions, this definition is complete enough to invoke correctly. It explains what is counted, which filters are supported, how missing-data exclusions work, and what special result fields like `source`, `office_address`, `distance_m`, and `walk_minutes` mean.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden and does so comprehensively for all 15 parameters. It defines exact semantics for stage, domain, city, remote_only, investor aliases, experience bounds, yc_batch, founder_origin, near, radius_m, walk_minutes, group_by, and top, including defaults and edge-case behavior.

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 states a specific verb and resource: aggregate counts over ALL matching public Rocketlist jobs, with named breakdown dimensions. It explicitly distinguishes itself from search_jobs, which returns the roles themselves, so the agent can choose 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.

Usage Guidelines5/5

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

It gives explicit selection guidance: use for 'how many', 'which cities/companies hire most', share and pay questions, and use search_jobs for the roles themselves. It also explains the special Startup Hiring Map subset and when the result is counted from the same snapshot versus the live catalog.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.