@proof-holdings/mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

cancel_lookalike_watch

Destructive

Disable Lookalike Watch monitoring while preserving the canceled subscription and keeping past alerts and reports readable.

Instructions

Turn Lookalike Watch off. The subscription is kept as canceled and returned in the same shape get_lookalike_watch reads; past alerts and reports stay readable. 404 when not subscribed. Needs lookalike-watch:write on an account-wide key.

ACCESS: needs a Proof account. Set PROOF_API_KEY and restart this server, then call this tool again. start_login does NOT open this tool.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "cancel_lookalike_watch"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`id`	Yes	MongoDB ObjectId
`status`	Yes
`created_at`	Yes
`updated_at`	Yes
`activated_at`	Yes	When the watch was last turned on (stamped again on reactivation)
`brand_tokens`	Yes
`notify_email`	Yes
`owned_namespaces`	Yes
`last_report_period`	Yes	The last month reported, `YYYY-MM`; null before the first report

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.10.0Nov 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the destructiveHint annotation by explaining what is actually destroyed vs preserved: the subscription becomes canceled, past alerts and reports remain readable. It also discloses the required scope (lookalike-watch:write on an account-wide key) and the 404 failure mode.

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 behavioral sentence is dense and front-loaded, covering state, return shape, and side effects in one line. The ACCESS block is somewhat boilerplate and formatted as a separate trailing chunk, but it is short and operationally useful rather than 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?

An output schema exists, so the description needn't enumerate return fields, and it instead covers the things the schema cannot: retained state, side effects, auth scope, and the error case. For a zero-param destructive toggle this is complete.

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 tool takes zero parameters, so there is nothing the description needs to disambiguate beyond what is already implicit. Baseline of 4 applies; no parameter detail is missing because no parameters exist.

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?

States a specific verb+resource ("Turn Lookalike Watch off") and immediately clarifies the semantics of that action (subscription kept as canceled rather than deleted). It also names get_lookalike_watch as the reader of the same object shape, which lets an agent place it relative to siblings without opening schemas.

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?

Gives the precondition for failure ("404 when not subscribed") and explicitly rules out a tempting alternative path ("start_login does NOT open this tool"). It does not explicitly name subscribe_lookalike_watch as the re-enable counterpart, but the guidance on when this tool applies is unambiguous.

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

Deploy Server