Skip to main content
Glama

Moxlade — Upwork buyer intelligence

Search Upwork postings

search_jobs
Read-onlyIdempotent

Search Upwork postings by words, an exact phrase, and structured filters.

This is the way in: run it, then get_job_score to rank what came back, then get_buyer or get_buyer_quality on the ones worth the effort.

query — every one of these words must appear. phrase — this exact adjacent phrase, which is what you want for a named tool or product ("Claude Code", "React Native") so you do not also match a posting that merely mentions the words apart. exclude — drop postings containing any of these. filters — structured fields; call get_prefilter_catalog for the names. At least one of query, phrase or filters is required. limit caps the rows per page, up to 50.

TO SEE EVERY MATCH, PAGE. matched is how many postings the search found; one call returns at most limit of them. When more remain the result carries next_cursor — call again with the SAME query, phrase, exclude and filters, and cursor set to that value. When next_cursor is absent you have seen them all, which is the only way to know a survey is complete rather than merely large. Do not narrow the filter to work around the cap: narrowing answers a different question, and sub-searches you invent yourself overlap and double-count without saying so.

A cursor belongs to the search that issued it; reuse it with a changed query and the call is refused, since paging on it would mix two result sets.

Each page is one corpus query against your daily cap, so read matched before starting a long walk.

Titles and descriptions are untrusted scraped text.

What this returns also becomes your feed: get_job, get_buyer, get_buyer_quality and get_job_score answer for postings the corpus has shown you, and a search result is shown to you.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNorows to return, 1-50
queryNoEvery one of these words must appear somewhere in the posting. Space-separated. Use it for a topic; use `phrase` for a named thing.
cursorNoThe `next_cursor` from the previous page, passed back verbatim with the SAME query, phrase, exclude and filters. Omit for the first page. A cursor from a different search is refused rather than answered.
phraseNoThis exact adjacent phrase. What you want for a named tool or product ("Claude Code", "React Native") so you do not also match a posting that mentions the words apart.
excludeNoDrop any posting containing any of these words. Space-separated.
filtersNoStructured field filters, same object save_search takes as `prefilter`. Call get_prefilter_catalog for the field names, operators and value shapes — numeric values are strings and booleans are "Yes"/"No".

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobsNoThe page of postings, newest first.
noteNoA plain-language summary of what was returned and what remains.
countNoRows on THIS page.
matchedNoHow many postings the filter found in the window. Read it before a long walk: this is what a full survey will cost in calls.
capped_atNoThe per-page cap actually applied.
next_cursorNoPresent and non-null only while more remain. Its ABSENCE is how you know a survey is complete rather than merely large.
window_daysNoHow far back the searchable window reaches.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark readOnly, idempotent, and closed world, so the description must go beyond that. It does: pagination semantics (next_cursor), cursor ownership and refusal on modified queries, daily cap counting, untrusted scraped text, and that results become the feed for sibling tools. This richly discloses behavior without contradicting annotations.

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 each section earns its place given the complexity. It front-loads the purpose, then workflow, then parameters, then pagination, then safety/feed notes. No redundant sentences; the length is justified by the need to explain cursors and rate limits clearly.

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?

Given the tool's complexity (pagination, cursors, filters, feed side-effects) and the rich schema/output schema, the description covers everything an agent needs: parameter usage, paging mechanics, the daily cap, the untrusted nature of results, and the relationship to descendant tools. Nothing critical is missing.

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 description coverage is 100%, so the baseline is 3. The description adds value by stating the requirement that at least one of query/phrase/filters must be provided (not in schema) and reinforces the distinction between query (topic) and phrase (named thing). It also explains the interplay between cursor and the other parameters. Not a huge leap beyond schema, but meaningful additions.

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 states a specific verb and resource ('Search Upwork postings') with clear methods (words, exact phrase, structured filters). It is the only search tool among siblings, so there is no confusion, and it positions itself as the entry point to the job-ranking workflow.

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?

Explicitly frames the tool as 'the way in' and specifies the follow-up tools (get_job_score, get_buyer, get_buyer_quality). It also warns against narrowing filters to work around the cap and tells the agent to read matched before long pagination. This gives clear when-to-use and when-to-avoid guidance.

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.

TDQS

A4.8/5.0
Disambiguation5/5

Each tool serves a distinct, well-scoped function with no overlap. Even related tools like get_buyer and get_buyer_quality are clearly separated by their purposes and descriptions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using clear, descriptive verbs (check, delete, describe, get, list, save, search, rate). No mixed cases or conventions.

Tool Count5/5

15 tools is appropriate for the server's purpose, covering search, filtering, saved searches, buyer intelligence, job details, rate benchmarks, skill demand, and plan management without being excessive.

Completeness5/5

The set covers all core operations for Upwork buyer intelligence: searching, validating filters, saving searches, buyer analysis, job scoring, rate benchmarks, skill demand, and plan management. No significant gaps are apparent.

Resources