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.

Save a search and be told about matches

save_search
Idempotent

Save a search so new matching postings are pushed to you as they appear, instead of you polling for them.

This is the difference between asking the corpus and being told by it. name is yours, for finding it again. prefilter is the same filter object search_jobs accepts as its filters argument — run check_prefilter first if you are unsure it is valid. webhook_url is an https endpoint that receives each match as JSON; leave it out to save the search without delivery and add one later.

Matching starts immediately and also back-fills recent postings that already match, so a new search is useful the moment it exists rather than after the next thing is posted.

Refuses a webhook that resolves to a private address — a saved search is a URL we will fetch, and we will not be aimed at an internal network.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesYour own label for this search, for finding it again. Saving the same name twice updates that search in place rather than creating a second.
prefilterYesThe filter new postings are matched against — the same object search_jobs takes as `filters`. Run check_prefilter on it first: a filter that is valid and matches nothing looks exactly like a quiet market.
webhook_urlNoAn https endpoint that receives each match as JSON. Omit it and matches accumulate for you to read instead. http, and any address that resolves to a private network, are refused.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoThe name you gave it.
noteNoPresent when saved but paused because the plan has ended.
savedNoThe slug to use later.
signingNoThe verification recipe in one paragraph. Absent — not null — unless you passed `webhook_url`, on the same terms as signing_secret.
deliveryNo'webhook' when one was configured, else null.
matchingNoWhether it is running now.
signing_secretNoSHOWN ONCE. Verify every delivery with it. Re-saving returns the same secret rather than rotating. Absent — not null — unless you passed `webhook_url`: with no delivery there is nothing to sign.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations, the description reveals meaningful runtime behavior: matching starts immediately, it back-fills recent postings, webhooks receive each match as JSON, and private-network webhook addresses are refused. This adds security and timing context that annotations alone do not convey, and it does not contradict the idempotentHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening hook, per-parameter guidance, timing behavior, and a security caveat. Every sentence adds functional information, with the most important usage signal front-loaded.

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?

For a tool with an output schema, complete schema coverage, and informative annotations, the description fully covers selection, invocation, validation prerequisites, delivery behavior, and safety constraints. Nothing essential to a correct call is missing.

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

Parameters3/5

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

Schema coverage is 100% and the schema already documents all three parameters richly, including the update-in-place behavior for duplicate names. The description reinforces the prefilter/webhook_url meanings but mostly repeats what the schema already states, so it adds little net semantic value beyond the structured data.

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 names a specific action (save a search) on a specific resource (search queries) with a distinct outcome (matches pushed to you), and contrasts it with polling. It is clearly differentiated from siblings like search_jobs and list_saved_searches by the delivery/notification framing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit context for when to use this tool ('instead of you polling'), and tells users to run check_prefilter first if unsure about a filter. It could more explicitly list when not to use it or name alternatives like delete_saved_search, but the main selection guidance is present and actionable.

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