Skip to main content
Glama

Moxlade — Upwork buyer intelligence

This connector has been deprecated

Duplicate listing. This server is now listed as Moxlade - Upwork buyer intelligence, the entry linked to its official MCP Registry record (com.moxlade/upwork-buyer-intelligence). Same endpoint, same 15 tools. Please connect there instead.

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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedOutput schema / $defs / Posting / description
      Previous value: -"One public posting, as search_jobs and get_job return it.\n\nEvery field is what Upwork itself shows. The de-anonymised buyer is NOT here\nand never will be — that is get_buyer, behind the feed gate."New value: +"One public posting, as search_jobs and get_job return it.\n\nEvery field is what Upwork itself shows. The enriched company is NOT here\nand never will be — that is get_buyer, behind the feed gate."
    • changedOutput schema / $defs / Posting / properties / client_location / description
      Previous value: -"The country Upwork shows for the client. Not a de-anonymisation."New value: +"The country Upwork shows for the client. Not the enriched company record."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint already imply a safe read), the description discloses non-obvious behavioral traits: each page consumes one corpus query against a daily cap, cursors are bound to their originating search and refused on changed queries, scraped titles/descriptions are untrusted, and paging via next_cursor is the only way to know a survey is complete. No contradiction with the annotations; substantial added context.

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 every block earns its place: workflow, param semantics, pagination mechanics, caps, and data-quality warnings are each load-bearing for correct use of this complex tool. It is front-loaded with purpose and workflow before mechanics. It loses one point for some redundancy — the query/phrase/exclude/filters paragraphs largely duplicate the input schema descriptions.

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 output schema exists (covering matched/next_cursor return fields), the description need not explain return values, and it correctly focuses on call behavior: full pagination protocol (same-params + cursor, next_cursor absence meaning completion), daily-cap awareness, and cursor-rejection on changed queries. Combined with a rich input schema, nothing an agent needs to page a survey correctly 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 coverage is 100% so the baseline is 3, but the description adds genuine value: it surfaces the at-least-one-of constraint (absent from the schema since 0 params are required), explains the query-vs-phrase choice for named products vs topics, and specifies the max limit of 50. The narrative mostly restates schema text for individual params, which is why it is not a 5, but the cross-parameter rules are a distinct improvement.

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 specific verb+resource+scope ('Search Upwork postings by words, an exact phrase, and structured filters') and immediately distinguishes itself from siblings by naming the downstream tools (get_job_score, get_buyer, get_buyer_quality) it feeds into. It also differentiates query vs phrase intent, leaving no ambiguity about what this tool is searching.

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 states the workflow ('This is the way in: run it, then get_job_score… then get_buyer or get_buyer_quality'), the at-least-one-of-query/phrase/filters precondition, and when to route to get_prefilter_catalog for filter field names. It even warns against narrowing filters to defeat the page cap, stating that invented sub-searches 'overlap and double-count without saying so' — clear when-to/when-not-to 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.

Resources