Skip to main content
Glama

RocketList

Search jobs

search_jobs
Read-onlyIdempotent

Search public active Rocketlist jobs. Returns bounded, non-personal job data only.

All list arguments are arrays of strings; passing a bare string is a validation error.

Filters:

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

  • skills: matched against the job's listed tech stack.

  • 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNo
limitNo
queryNo
stageNo
domainNo
skillsNo
investorNo
remote_onlyNo
max_experience_yearsNo
min_experience_yearsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint), the description discloses many behavioral traits: prefix token matching, substring semantics, exact-match behavior for domain/stage, investor alias resolution, and concrete exclusion behavior when data is missing (83%, 12%, 56% coverage). It also states the array-type validation rule. This significantly exceeds what annotations alone provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, then organized as a clear bulleted filter list. Every sentence adds operational value: matching behavior, coverage percentages, and example values. Despite length, there is no filler or redundancy, and the structure makes scanning easy.

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?

For a 10-parameter search tool with an output schema, the description covers almost everything an agent needs: filter semantics, missing-data side effects, and input validation. The only gap is the limit parameter (pagination/result cap), which is not described; 'bounded' hints at it but does not explain how limit controls it. Otherwise, the caveats and examples make the tool safely callable.

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 it delivers. Every filter parameter except limit gets a detailed semantic explanation including matching rules, examples, and caveats. The global note that list arguments must be arrays of strings clarifies validation. The only omission, limit, is a self-explanatory integer with a default in 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, 'Search public active Rocketlist jobs', immediately stating the operation and scope. It clearly differentiates from siblings by focusing on searching jobs rather than retrieving single entities (get_company, get_job) or searching companies (search_companies). No tautology or ambiguity.

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?

The description gives extensive context on how filters work and what limitations apply, such as non-personal data and partial coverage for investor/stage/experience. However, it never explicitly tells the agent when to prefer search_jobs over get_job or search_companies, nor when not to use it. The routing to alternatives is only implied by the presence of sibling tool names.

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.