Skip to main content
Glama

Moxlade — Upwork buyer intelligence

by com.moxlade

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. Dates show when Glama detected each change.

  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.

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.6/5.0
Disambiguation5/5

Each tool maps to a distinct resource or action: search, filter validation, saved-search management, buyer lookup, buyer quality, job scoring, market rates, and account/plan introspection. The get_* tools are cleanly separated by complements such as get_job vs get_job_score and get_buyer vs get_buyer_quality, so an agent should not struggle to pick the right one.

Naming Consistency5/5

All tool names consistently use snake_case verb_noun or verb_adjective_noun patterns, such as search_jobs, check_prefilter, delete_saved_search, and get_buyer_quality. There are no camelCase names, vague verb-only names, or mixed conventions.

Tool Count5/5

At 15 tools, the server sits exactly within the ideal range and each tool earns its place in the workflow. The set covers discovery, enrichment, saved-search lifecycle, and account introspection without obvious redundancy.

Completeness4/5

The core workflow is well covered: search, prefilter validation, job detail, scoring, buyer identity, payment quality, saved-search create/list/delete, and plan/activity visibility. The main gap is the lack of an update operation for an existing saved search, such as changing its filter or attaching a webhook later; this is a minor workaround rather than a blocking dead end.

Resources