@proof-holdings/mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

subscribe_lookalike_watch

Turn on lookalike monitoring for newly published npm, PyPI, Packagist, Go module and MCP-registry artifacts, checking names against your brand tokens and sending alerts plus monthly reports.

Instructions

Turn on Lookalike Watch: newly published npm, PyPI, Packagist, Go module and MCP-registry artifacts are watched for names confusable with your brand tokens, with alerts and a monthly report (list_lookalike_alerts, list_lookalike_reports). Not a billed proof: no quota is charged. Lookalike Watch is part of the €29 plan and above (enforced while billing is live). Refused 422 when not eligible, with the reason as the code: plan_upgrade_required, no_verified_domain, no_active_delegation, delegation_sample_exhausted, account_scheduled_for_deletion, or for the delivery address notify_email_not_owned / no_notify_email; 409 when already on; 503 eligibility_unavailable means unknown, not no, so retry. Needs lookalike-watch:write on an account-wide key (a key bound to one sub-account is refused).

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

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": {
      "brand_tokens": "<brand_tokens>"
    },
    "name": "subscribe_lookalike_watch"
  }
}

Input Schema

Name	Required	Description
`brand_tokens`	Yes	The names to watch for (1-20, each up to 64 characters)
`notify_email`	No	Where alerts go: an email address the account owns (otherwise notify_email_not_owned)
`owned_namespaces`	No	Namespaces you publish under yourself, so your own artifacts raise no alert (up to 50)

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.2/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing that no quota is charged, the exact plan gate, the full set of 422 refusal codes with their meanings, the 409 already-on case, and that 503 eligibility_unavailable means unknown rather than ineligible so the call should be retried. It also flags that start_login does not unlock this tool, which prevents a plausible wrong recovery path. Minor gap: it doesn't say whether an existing watch's config can be re-submitted or what the success payload confirms, though the output schema covers returns.

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?

Front-loads the action and the watch scope before the eligibility and error detail, which is the right order for a decision. The error-code enumeration is a single dense run-on sentence, readable but the least economical part of the text.

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 state-changing subscription tool with a rich output schema, it covers auth requirements, plan eligibility, every refusal reason and the retry semantics for the ambiguous 503, which is everything an agent needs to call it and interpret failure without guessing.

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%, so brand_tokens, notify_email and owned_namespaces are already fully described; the description adds only that notify_email must be an address the account owns (otherwise notify_email_not_owned) and otherwise restates schema semantics. Useful corroboration, but not much meaning beyond what the schema already carries.

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 ("Turn on Lookalike Watch") plus exactly what is watched (newly published npm, PyPI, Packagist, Go module and MCP-registry artifacts), what it compares against (brand tokens), and what it produces (alerts and a monthly report). It also names the companion tools (list_lookalike_alerts, list_lookalike_reports), so an agent can distinguish monitoring setup from alert/report retrieval.

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 explicit preconditions (Proof account, PROOF_API_KEY, lookalike-watch:write on an account-wide key, €29 plan and above), says an already-on state returns 409, and points to the listing tools for downstream use. It does not explicitly route an agent to get_lookalike_watch before subscribing or to cancel_lookalike_watch for teardown, so the alternative-selection guidance is strong but not complete.

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

Deploy Server