CareerHolo

Search tech jobs

search_jobs

Read-onlyIdempotent

Search open tech jobs by keywords, place, skills, level, work type, visa sponsorship, pay and posting date. Returns 20 jobs a page, newest first, or the best title matches first when there are keywords. Each job has url (its CareerHolo page) and apply_url (the company's own page).

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
`sort`	No	Default: best title matches first when there are keywords
`level`	No	Seniority: junior includes interns, senior includes leads
`query`	No	Keywords: a role, skill or company, e.g. "data engineer" or "rust"
`skills`	No	Skills every job must ask for, e.g. ["Python", "AWS"]
`company`	No	One employer, e.g. "Stripe"
`location`	No	A city, state or country, e.g. "Berlin", "Texas", "Canada", or "Remote"
`work_type`	No	How the job is worked
`remote_from`	No	Remote jobs open to people in this region
`posted_within`	No	First seen within this many days
`salary_stated`	No	Only jobs that state their pay
`min_salary_usd`	No	Stated pay of at least this, US dollars a year
`visa_sponsorship`	No	Only jobs that say they sponsor a visa

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world reads, so the description isn't obligated to justify safety. It adds real value beyond them: page size (20 per page), the two ordering regimes (newest first vs. best title matches when keywords are present), and the distinction between `url` and `apply_url`.

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?

Two sentences, front-loaded with the searchable facets, then pagination/ordering, then the two URL fields. No filler, no repetition of the title.

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 13-parameter search with no output schema, the definition covers the important unknowns: page size, result ordering, and the meaning of the URL fields returned. It stops short of describing the remaining job fields or how deep pagination goes, but nothing essential to calling it correctly is missing.

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?

With 92% schema description coverage and enums on five parameters, the schema carries most semantic weight; the description mostly restates the facet list. The one genuine addition is clarifying how keyword presence changes default ordering, which the schema's `sort` text only partially covers.

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?

States a specific verb and resource ("Search open tech jobs") and enumerates the facets it searches over, which clearly separates it from get_job (single job) and company_jobs (one employer). It never names a sibling to route against, so it lands just short of full differentiation.

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 facet list implies when to reach for it (faceted discovery rather than lookup by id), but there is no explicit "use this when / use X instead" guidance and no prerequisites or exclusions. The ordering sentence describes behavior rather than when to choose this tool.

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

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