Skip to main content
Glama

Search Public Jobs

search_jobs
Read-only

Works without a Remoet account. Search Remoet's PUBLIC job catalogue: every role on the open board at remoet.dev/jobs, across all companies, not just the ones the user has starred. No star is needed and none is consumed. Use this to answer "what is out there" for any technology, title or company; use get_starred_jobs instead for the user's own curated feed.

Each result carries the role's public Remoet URL, which is a real page anyone can open, plus applyUrl (the employer's own posting, where an application actually happens) and companySlug (the same slug get_listing takes, for company detail). Roles that Remoet is not permitted to publish never appear here.

Duplicate postings of one role at a company are collapsed into a single result, so totalCount is the number of distinct roles, not raw postings. duplicateCount is how many postings collapsed into it; boards usually duplicate a role per location, but nothing guarantees that, so do NOT report it as a number of locations. firstSeenAt is when Remoet first saw the role, not when the employer posted it, and lastVerifiedAt is the last time Remoet confirmed it was still open.

Filters are searchQuery (title, Remoet summary and tech stack), techStack (ANY of the given technologies, or EVERY one under techStackMatch: "all", which is how you express a must-have stack), companySlug, location, remotePolicy, experienceLevel and salaryMin. A salaryMin floor drops every role Remoet holds no numeric salary for, which is roughly 45% of the board, so use it when salary is a hard requirement and leave it off otherwise. location matches the canonical places Remoet stores per role rather than the free-text location string, so a country also finds roles that name only one of its cities; searchQuery does NOT read location, so filter by place with location and not by typing the place into searchQuery.

When a search returns nothing, the hint says which filter emptied it and how many roles dropping that one filter would return, so act on the hint rather than guessing at which filter to relax. Results are newest-first unless you ask otherwise: sortBy takes "newest" or "salary", with sortOrder asc or desc. Start broad and narrow: a single heavily filtered query misses good roles. Use save_job to bookmark anything worth keeping.

Example: search_jobs({ searchQuery: "platform engineer", techStack: ["Go", "Kubernetes"], location: ["Berlin"], remotePolicy: ["remote"] }).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number, starting from 1 (default: 1). Without a Remoet account the first 10 pages are available; connect an account to page deeper.
sortByNoSort field: "newest" (default) or "salary". Under "salary", roles with no known salary sort LAST whichever direction is asked for, so they never head the list.
locationNoMatch roles in ANY of these places (max 5), e.g. ["Berlin"] or ["Germany", "Netherlands"]. Matched against the canonical place names Remoet stores per role, not the free-text location string, so a country ALSO matches roles that only name one of its cities. City or country name, url slug ("san-francisco") and common alias ("NYC", "UK") all resolve. A place Remoet does not know returns no roles and says so, rather than quietly returning everything. Note that under a location filter a role's duplicateCount, firstSeenAt and the particular posting shown (its id, applyUrl and location) describe only that role's postings IN THOSE PLACES, so they can differ from the same role returned without one.
pageSizeNoResults per page, max 20 without a Remoet account (default: 20)
salaryMinNoMinimum salary, against the role's normalized salaryEnriched.from. Roles Remoet holds no numeric salary for are EXCLUDED by this filter, so a floor narrows the board to the ~55% of roles that publish one.
sortOrderNoSort direction (default: desc)
techStackNoMatch roles carrying ANY of these technologies (e.g. ["React", "Go"]), or EVERY one of them under techStackMatch: "all". Matched case-insensitively against the exact stored technology, so use whole names rather than fragments. Known spelling variants are expanded, so "Go" also finds roles tagged "Golang".
companySlugNoRestrict to one company by its Remoet slug (the same slug get_listing takes, e.g. "stripe"). An unknown or delisted company returns an empty page, not an error.
searchQueryNoFree text, matched against the job title, Remoet's own summary of the role and its tech stack. Comma-separate keywords to require ALL of them (e.g. "react, typescript").
remotePolicyNoMatch roles with ANY of these remote policies: "remote", "hybrid", "onsite" or "remote-restricted" (max 5).
techStackMatchNoHow techStack combines: "any" (default, at least one technology) or "all" (every technology required ON THE SAME ROLE; use for a must-have stack). Spelling variants stay grouped per technology, so "all" with ["Go", "React"] means a Go-or-Golang role that is ALSO a React role, never a Golang-or-React one. Under "all" at most 20 distinct technologies may be required in one search: more than that returns NO roles rather than a search quietly trimmed to 20, so send the ones that genuinely matter.
experienceLevelNoMatch roles at ANY of these experience levels: "junior", "mid" or "senior" (max 5).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / companySlug / maxLength
      Added value: +500
    • changedInput schema / properties / page / type
      Previous value: -"number"New value: +"integer"
    • changedInput schema / properties / pageSize / type
      Previous value: -"number"New value: +"integer"
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description goes far beyond this, disclosing critical behaviors: 'Works without a Remoet account', 'No star is needed and none is consumed', 'Roles that Remoet is not permitted to publish never appear here', duplicate collapsing semantics ('totalCount is the number of distinct roles, not raw postings'), and temporal nuances ('firstSeenAt is when Remoet first saw the role, not when the employer posted it'). It also explains the empty-result hint behavior. All of this is essential behavioral context that annotations do not cover.

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 well-organized into logical paragraphs: intent, result semantics, filter explanations, and an example. Every sentence adds necessary information for correct use of a 12-parameter tool; there is no fluff. The opening sentence immediately establishes purpose, and the example at the end anchors the explanation. While it is not brief, the length is justified by the tool's complexity, and the structure supports comprehension. It earns a 4 for being efficiently structured despite its length.

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?

The tool is highly complex with 12 parameters, all optional, and no output schema. The description covers everything an agent needs: the full filter behavior, sorting semantics, pagination limits, result field meanings (URL, applyUrl, companySlug), duplicate collapse counts, empty-result hints, and even an example call. It also explains edge cases like 'a country also finds roles that name only one of its cities' and the 45% salary exclusion. Nothing essential is missing; the description is a complete operational manual.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds substantial semantic value beyond the schema: it explains that 'location matches the canonical places Remoet stores per role rather than the free-text location string' and that 'searchQuery does NOT read location', clarifies techStackMatch 'all' semantics with an example, and warns that salaryMin 'drops every role Remoet holds no numeric salary for, which is roughly 45% of the board'. These details materially change how an agent interprets parameters. While the schema already documents each parameter, the description provides operational nuance that the schema alone does not; hence a 4 rather than 3.

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 clear, specific statement: 'Search Remoet's PUBLIC job catalogue: every role on the open board at remoet.dev/jobs, across all companies, not just the ones the user has starred.' It names the resource (public job catalogue), the scope (all companies), and explicitly contrasts with get_starred_jobs, making the tool's unique purpose unambiguous. It is not a tautology and clearly differentiates from siblings.

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?

The description provides explicit usage direction: 'Use this to answer "what is out there" for any technology, title or company; use get_starred_jobs instead for the user's own curated feed.' It also offers tactical advice on filters, e.g., 'leave it off otherwise' for salaryMin when not a hard requirement, and 'Start broad and narrow: a single heavily filtered query misses good roles.' This is targeted, actionable guidance for when and how to use the tool versus alternatives.

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.

Resources