Skip to main content
Glama

Search remote jobs

search_jobs
Read-only

Search remote job listings on Himalayas by job title, role, skill or keyword, filtered by the countries a job is open to, worldwide availability, seniority, employment type, salary, markets, benefits or companies. Each result has the company, title, salary range when listed, the countries the job is open to, the posting date and the slugs for get_job_details.

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

NameRequiredDescriptionDefault
pageNoPage number for pagination (starts at 1)
sortNoSort order for results (default: 'relevant')
typeNoFilter by a single employment type (full-time, part-time, contractor, temporary, intern, volunteer, or other)
countryNoFilter jobs by country (e.g., 'Canada', 'United States', 'UK')
keywordNoJob title, role or skill to search for, e.g. 'product manager' or 'react' (optional)
marketsNoComma-separated market/category slugs to filter by (e.g., 'saas,fintech,healthcare')
benefitsNoComma-separated benefit slugs to filter by (e.g., '401k,health-insurance,equity')
currencyNoSalary currency (default: USD). salary_min and salary_max are always USD; this doesn't convert them.
companiesNoComma-separated company slugs to filter by (e.g., 'stripe,gitlab')
worldwideNoShow ONLY 100% remote jobs available worldwide (overrides country filter)
experienceNoFilter by a single experience/seniority level (entry-level, mid-level, senior, manager, director, or executive)
salary_maxNoMaximum yearly pay in USD, compared the same way as salary_min
salary_minNoMinimum yearly pay in USD. Hourly, weekly and monthly pay is converted to a yearly figure first (hourly x 2080), so hourly jobs whose yearly equivalent clears it are included.
salary_requiredNoIf false, include jobs without salary data in salary-filtered results (default: true — only jobs with salary)
exclude_worldwideNoWhen true and country is set, return ONLY jobs specifically available in that country, excluding worldwide/remote jobs. Requires country to be set.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/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 context the annotations do not: the per-result fields returned (company, title, salary range when listed, open countries, posting date, and get_job_details slugs), which matters because there is no output schema.

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?

Front-loaded with the purpose in the first clause and the return shape in the second sentence. Two sentences for a 15-parameter tool is efficient, though the filter enumeration is somewhat redundant with the schema.

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 15-parameter, zero-required search tool with no output schema, the description covers both intent and result shape, which is the main gap an agent would otherwise face. Pagination and sort behavior are left to the schema but are well documented there.

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%, so the description's broad enumeration of filter categories (country, worldwide, seniority, employment type, salary, markets, benefits, companies) largely restates what the schema already documents in more precise detail. It adds no syntax, default, or interaction detail beyond the schema, so the baseline applies.

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 (Search) and resource (remote job listings on Himalayas) plus the searchable dimensions (title, role, skill, keyword) and filter axes. It also names the follow-up sibling get_job_details, which the returned slugs feed, so an agent can chain calls without opening a schema.

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

Usage Guidelines4/5

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

Clear context: use this to discover remote jobs matching a keyword and a wide set of filters. However it never states when NOT to use it — notably how it differs from the sibling get_jobs or get_related_jobs — so the agent must infer the boundary.

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.