Moxlade — Upwork buyer intelligence

Delete a saved search

delete_saved_search

DestructiveIdempotent

Delete a saved search and its delivery, permanently.

saved is the slug list_saved_searches returns — not the display name.

THIS CANNOT BE UNDONE and there is no archive: the search and its webhook are removed, and re-creating it means calling save_search again with the filter, which you would need to have kept. Postings already delivered are yours and are unaffected; nothing further will be.

Do NOT use it to pause. There is no pause tool because there is nothing to call: letting a plan lapse pauses every saved search on the token, and paying resumes them where they left off. Deleting to stop delivery for a month throws the filter away to solve a problem that solves itself.

Returns deleted (false, with a note, when no search on this token has that slug — a delete that matched nothing is an answer, not an error) and the saved slug it acted on.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`saved`	Yes	The slug list_saved_searches returns — not the display name. Deleting one that is already gone answers false rather than failing.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No	Why nothing was deleted, when nothing was.
`saved`	No	The slug acted on.
`deleted`	No	False, with a note, when no search on this account had that slug — an answer, not an error.

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already mark destructiveHint=true and idempotentHint=true, but the description adds crucial behavioral detail: no archive, webhook removal, unaffected already-delivered postings, and a false return with a note when no matching saved search exists. It fully discloses consequences beyond the structured metadata.

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?

Though the description is longer than average, every sentence carries meaningful guidance for a destructive one-parameter operation. It front-loads the core action, then layers warnings, alternatives, and return semantics without repetition or filler.

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?

The description explains the return values (deleted false with a note and the slug acted on), the irreversible consequences, the alternative pause behavior, and the relationship to save_search. Combined with the output schema, this is complete for correct invocation and expectation-setting.

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% and the schema's parameter description already explains slug vs display name and the false-on-missing behavior. The description reinforces this and adds context about needing to keep the filter for re-creation, which is useful but not entirely necessary since the schema already covers the key distinction.

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 and resource: 'Delete a saved search and its delivery, permanently.' It clearly identifies the target resource and the permanent nature of the operation, distinguishing it from save_search and list_saved_searches.

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 when not to use the tool: 'Do NOT use it to pause.' It explains that no pause tool exists, that plan lapse handles pausing, and that using delete for temporary stoppage would discard the filter unnecessarily. This is strong alternative routing.

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 tools Inspect

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

Need Help?