OpeningsFirst

Search jobs

search_jobs

Read-only

Search every open job with any combination of filters: words and meaning, roles, places, level, exact years, work mode, job type, dates, skills (all / any / none), title words, companies in or out, key employers, YC, hiring system. 25 jobs a page, up to 5 pages.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_jobs"
  }
}

Input Schema

Name	Required	Description
`page`	No	1-5
`sort`	No
`query`	No	Any words: a job title, skill or kind of work ('LLM evaluation', 'SAP FICO', 'ICU nurse'). Matched on titles, skills and meaning.
`roles`	No	Role names from list_filter_options (e.g. 'Data Scientist'); other names are searched as words.
`cities`	No	Cities; means jobs in these cities (remote jobs elsewhere only if work_modes includes 'remote').
`levels`	No	Any of Intern, Entry level, Mid level, Senior, Lead / Manager, Director, Executive. Jobs whose level is not known are left out.
`yc_only`	No	Only Y Combinator startups.
`companies`	No	Only these companies (part of the name is enough).
`countries`	No	Countries, e.g. ['India'] or ['United States'].
`job_types`	No	Any of full_time, part_time, contract, temporary, internship.
`years_max`	No	Most years of experience.
`years_min`	No	Least years of experience the job asks for.
`skills_all`	No	Every one of these skills (e.g. ['go', 'kafka']).
`skills_any`	No	At least one of these skills.
`work_modes`	No	Any of remote, hybrid, onsite.
`skills_none`	No	None of these skills.
`posted_since`	No	Found by us since this date/time (ISO), e.g. 2026-10-20T08:00:00Z.
`years_strict`	No	True: leave out jobs that don't state years. Default false.
`hiring_systems`	No	Only jobs on these hiring systems (e.g. ['workday', 'greenhouse']); see list_filter_options.
`title_words_all`	No	Words that must all be in the title.
`title_words_none`	No	Words that must not be in the title (e.g. ['senior', 'lead']).
`exclude_companies`	No	Leave out these companies.
`include_recruiters`	No	Also recruiter, job-site and gig listings (default false: direct employers).
`key_employers_only`	No	Only well-known employers on our key lists.
`posted_within_days`	No	Posted in the last N days (1-90).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 1, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior the annotations cannot: the result cap of 25 per page across 5 pages, i.e. a hard ceiling of 125 results, which affects whether an agent should narrow filters. It stops short of default sort or ordering behavior.

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?

Two sentences, purpose front-loaded, and the pagination limit tucked at the end where it belongs. The filter enumeration is dense but each clause maps to a real parameter family, so nothing is wasted, though it reads as a list rather than prose crafted for comprehension.

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 25-parameter zero-required tool with a fully documented schema and no output schema, the description covers the search surface, the result ceiling, and the filter families. An agent has enough to call it correctly and to know when to paginate or narrow rather than over-fetch.

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 coverage is 96%, so the schema already explains nearly every parameter, and the baseline is 3. The description's enumeration ('words and meaning', 'skills (all / any / none)', 'companies in or out') groups the filters helpfully but adds little semantics beyond the schema, and does not flag that roles and hiring_systems require a prior list_filter_options call.

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?

States a specific verb and resource ('Search every open job') plus the combinatorial filter capability in the same sentence. The word 'every' scopes it against siblings like new_jobs, my_jobs, and company_jobs, so an agent can tell what this tool returns without opening the schema.

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?

Implies the tool is the general-purpose filtered search, but never names alternatives such as company_jobs for a single employer, similar_jobs for lookalikes, or new_jobs for recency. The agent must infer routing from sibling names alone.

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

All OpeningsFirst 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?