@proof-holdings/mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

get_lookalike_watch

Read-only

Retrieve the Lookalike Watch subscription for a Proof account to confirm whether lookalike monitoring is active; returns 404 when the account never subscribed.

Instructions

Get the Lookalike Watch subscription, in the shape subscribe_lookalike_watch returned it. 404 when the account never subscribed.

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": "get_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.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds real behavior on top: the exact 404 condition when the account never subscribed, and the authentication prerequisite (Proof account plus PROOF_API_KEY and server restart). It also pre-empts a likely wrong assumption by stating start_login does NOT grant access.

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?

Two compact blocks, front-loaded with the operation, then the access requirement. Every sentence carries information, though "in the shape subscribe_lookalike_watch returned it" is slightly indirect phrasing where a direct statement of the returned object would read cleaner.

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 zero-parameter read tool with an output schema and a readOnly annotation, the description covers the operation, the error case, and the auth path, which is close to everything an agent needs. Only minor gaps remain, such as whether an absent subscription could also surface as an empty result rather than 404.

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 and the schema is empty, so there is no parameter semantics to explain; the baseline for a no-parameter tool applies. Nothing in the description is needed on this axis.

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 and resource ("Get the Lookalike Watch subscription") and ties the return shape to the sibling subscribe_lookalike_watch, so the agent knows exactly which of the lookalike-watch tools this is. The 404-on-never-subscribed clause further pins down the semantics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the verb: read the current subscription. No explicit when-to-use or when-not guidance is given, and the alternatives (subscribe_lookalike_watch, cancel_lookalike_watch) are not named as alternatives, only the former is referenced for return shape. The 404 clause does tell the agent what a never-subscribed state looks like, which is useful context.

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

Deploy Server