Skip to main content
Glama
Sign In
OpenHire — Real Job Postings, Ghost Jobs Scored

OpenHire — Real Job Postings, Ghost Jobs Scored

by gzchenhao
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Manage watches

manage_watch
Destructive

List, update, or delete a fingerprint's job watches to change filters, reset a watch's baseline, or stop alerts when users change their mind.

Instructions

List, change or delete the user's watches (the fingerprint's standing intents).

action "list": every active watch with its watch_id and filters. "update": replace one watch's filters (pass watch_id and the WHOLE new filter set, same keys as watch_intent); it gets a new watch_id and its next check is a fresh baseline, the old one stops. "delete": stop one watch for good. Use this when the user changes their mind instead of registering a second watch beside the first. Only the fingerprint that registered a watch can change it. Nothing personal is stored or accepted, as with watch_intent.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "fingerprint": "<fingerprint>",
      "action": "<action>"
    },
    "name": "manage_watch"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYes
filtersNo
watch_idNo
fingerprintYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.62

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (destructive, non-idempotent), the description discloses that an update issues a new watch_id, resets the next check to a fresh baseline, and stops the old watch, and that delete is permanent. It also adds an authorization constraint ('Only the fingerprint that registered a watch can change it') and a privacy guarantee ('Nothing personal is stored or accepted'), none of which the annotations convey.

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?

Front-loaded summary sentence followed by compact per-action clauses keyed with quoted action names, so the agent can scan to the relevant paragraph. Every sentence contributes a distinct rule; nothing is repeated from the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive multi-action tool with no output schema and no documented parameters, the description supplies the mutation semantics, permission rule, and filter-replacement rule. It falls slightly short on per-action parameter requirements and on what 'list' returns beyond watch_id and filters.

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?

With 0% schema coverage, the description carries the load and mostly succeeds: it defines the action values (list/update/delete), explains that filters must be the WHOLE new set using the same keys as watch_intent, and implies watch_id identifies the target. It never states per-action requirements, e.g. that watch_id is needed for update/delete and filters for update, which is the remaining gap for a required-2-of-4 schema.

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 opening line states a specific verb set and resource ('List, change or delete the user's watches') and defines what a watch is ('the fingerprint's standing intents'). Each of the three actions is then named and scoped, so an agent can tell this apart from watch_intent and check_watches without opening the schema.

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?

It gives a concrete when-to-use rule for delete/update ('Use this when the user changes their mind instead of registering a second watch beside the first'), which implicitly steers away from watch_intent. It stops short of explicitly naming the alternative tools (watch_intent, check_watches) or saying when 'list' is preferable to check_watches.

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

Deploy Server

Other Tools