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. Results can be bookmarked with save_job.

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?

Even though annotations already declare readOnly/no-destructive, the description adds substantial behavioral context: works without an account and consumes no star, salaryMin silently drops ~45% of the board, results are newest-first by default, duplicate postings are collapsed so totalCount counts distinct roles, and firstSeenAt/lastVerifiedAt are Remoet-observed timestamps rather than employer-posted ones.

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 account-free public-catalogue framing and the sibling contrast, then organized into result-fields, filters, and sort behavior. It is long and partially overlaps the schema's own parameter docs, but nearly every sentence carries actionable detail for a 12-parameter search tool.

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?

No output schema exists, and the description compensates by explaining the meaningful return fields (public remoetUrl, applyUrl, companySlug, totalCount, duplicateCount, firstSeenAt, lastVerifiedAt) and the semantics of duplicateCount so it is not misread as locations. Edge cases (empty results, unknown place, unknown company) are covered.

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, but the description goes beyond restating fields: it points to techStackMatch:'all' as the way to express a must-have stack, frames salaryMin as a hard floor that excludes unknown-salary roles, and warns that location matches canonical places while searchQuery does not read location. Much is still duplicated from the schema, keeping it below a 5.

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 Remoet's PUBLIC job catalogue, the open board at remoet.dev/jobs) and immediately bounds the scope ('across all companies, not just the ones the user has starred'). It explicitly names the sibling it is not (get_starred_jobs) so an agent can choose between them without opening either schema.

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?

Gives explicit when-to-use ('what is out there' for any technology, title or company) and the alternative for the opposite case (get_starred_jobs for the curated feed). It also adds operational guidance: start broad and narrow, act on the empty-result hint, use salaryMin only when salary is a hard requirement, and results can be bookmarked with save_job.

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