Skip to main content
Glama

Moxlade — Upwork buyer intelligence

by com.moxlade.buyer

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.

TDQS

A4.6/5.0
Behavior5/5

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

The description provides substantial behavioral detail beyond the annotations: it explains that matching starts immediately and back-fills recent postings, that saving the same name updates in place (aligning with idempotentHint), and that webhooks resolving to private addresses are refused. It also clarifies the optionality of the webhook and the accumulation of matches if omitted. No contradictions with annotations exist.

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 well-structured, opening with the core purpose, then covering each parameter, followed by behavior and a security note. Every sentence contributes value, though the length is slightly above minimal. The front-loading of the primary use case aids quick comprehension.

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 that an output schema exists and annotations cover safety and idempotency, the description completes the picture by explaining when to use it, how to validate the prefilter, the behavior of back-filling, and security constraints. An agent has sufficient information to call this tool correctly without additional context.

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?

The schema already describes all parameters with 100% coverage, so the description's role is supplementary. It adds operational guidance: instructing to run check_prefilter on the prefilter, and noting that webhook_url can be added later if omitted. These go beyond the schema's definition, earning a 4 rather than a baseline 3.

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 ('save') and resource ('search'), and clearly explains the purpose: to receive push notifications instead of polling. It distinguishes this from search_jobs by framing it as 'the difference between asking the corpus and being told by it', effectively differentiating the tool from its sibling.

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 explicitly contrasts with polling and implies use for ongoing monitoring rather than one-off queries. It recommends running check_prefilter first if unsure of the prefilter's validity, which is a clear prerequisite. However, it does not explicitly enumerate all alternative tools (e.g., list_saved_searches or delete_saved_search) or state when not to use this tool, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Moxlade — Upwork buyer intelligence toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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