Skip to main content
Glama

List your job matches

list_matches
Read-onlyIdempotent

List the job offers already matched to the caller's profile — their matches, not a search: nothing is fetched, scored or applied to here, and new offers only appear once the nightly match run has written them. Only offers with a match row for this account appear, whatever the account's role, and only offers that are still live: a posting the cleanup deactivated is never returned, however well it scored. Every row carries a numeric match score. It answers over a window — the last 30 days unless since_days says otherwise — and returns 10 offers unless limit says otherwise, at most 100, because a larger page is context the model pays for and does not read. Two counts always travel with the list: total is how many live matches fall inside the window, total_older how many fall outside it — so an empty jobs array never has to be read as "no matches": when every match is older than the window, the answer says so in summary and names the count. q filters inside that already-matched set, and narrows both counts with it. Read one offer with get_job, using a slug this returns.

Input Schema

NameRequiredDescriptionDefault
qNoFilter inside the already-matched set by title, company, description or location. It never widens the set.
pageNo1-based page of the same matched set.
limitNoMatches per page, 10 by default, at most 100.
since_daysNoWidth of the posting-date window in days, 30 by default. Widen it to reach the `total_older` matches.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Well beyond the read-only/idempotent annotations: it discloses that results depend on a nightly match run, that deactivated postings are never returned, and that empty results must be read alongside `total`/`total_older` and `summary` rather than as 'no matches'. The only gap is that it never states the shape of the `jobs` rows beyond 'numeric match score', so an agent must infer the fields of each returned offer.

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 what and the not-what, then behavior, then paging, then routing — a sensible order with no filler sentences. It is on the dense side (one long paragraph of stacked clauses), so it is efficient rather than maximally tight.

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?

There is no output schema, yet the description still explains the return contract: a `jobs` array, `total`, `total_older`, and a `summary` that explains empty results. Combined with the mutation and freshness caveats, an agent has everything needed to call this and interpret the response correctly.

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 adds real semantics: the 30-day default window, the interaction of `since_days` with `total_older`, that `q` narrows both counts, and the rationale for the 100 cap. It doesn't repeat parameter types or defaults blindly, which keeps the addition genuine.

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?

Names a specific verb and resource ('List the job offers already matched to the caller's profile') and immediately draws the boundary against search semantics — 'their matches, not a search: nothing is fetched, scored or applied to here'. The final sentence distinguishes it from get_job, so an agent can place it among siblings without opening any 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?

Explicit about when this is the right call (listing an already-matched set) and when it is not (searching, scoring, applying), and routes the agent to get_job for reading a single offer with the returned slug. The `q` clause also states it only narrows an existing set, which prevents misuse as a search entry point.

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