Skip to main content
Glama
hermoso-ai

Hermoso

Official

Read the competitor watch

list_watch_findings
Read-only

Retrieve competitor watch findings: new ads each watched brand launched since the last check, plus watch state and run status. Read-only and free—returns stored results without triggering a new check.

Instructions

Read what the standing COMPETITOR WATCH has found — the new ads each watched brand has launched since the last check, plus the watch's own state (who is watched, when it last ran, when it runs next, and whether the last run actually succeeded). The same board the web app's Ad Spy ▸ Watching tab renders. Use it to answer "what are our competitors running that's new?", to feed a teardown, or to save something worth keeping with save_to_swipefile. Findings marked seed:true are NOT new launches — the first check of a brand has nothing to diff against, so it seeds the board with what that brand is running right now; only later runs surface genuine changes. Read-only and free — it returns the stored results of past runs and never triggers a check (set_competitor_watch({runNow:true}) is what runs one).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNomax findings to return (default 25, max 75 — the server keeps at most 75, and at most 15 per brand)
competitorNoonly findings for this watched brand (exact name as returned in `watching`) — omit for all of them

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.161

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already set readOnlyHint=true and destructiveHint=false, and the description reinforces this by stating it is 'Read-only and free' and 'returns the stored results of past runs.' It adds the crucial behavioral caveat that seed:true findings are not new launches, explaining the first-check seeding behavior. This goes well beyond the annotations.

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?

The description is detailed but every sentence adds value: core purpose, equivalent web UI, use cases, seed semantics, and the distinction from set_competitor_watch. It is front-loaded with the main action and places caveats after the core message. No filler is present.

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?

Even though there is no output schema, the description explains what the return includes: new ads, watch state, last-run status, and next-run timing. It also explains the meaning of seed:true findings, which is essential for correct interpretation. For a read-only list tool with two optional parameters, this is complete.

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 description coverage is 100%, so the limit and competitor parameters are already fully documented in the schema. The description does not add parameter-level detail beyond what the schema provides. This meets the baseline for full schema coverage.

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: 'Read what the standing COMPETITOR WATCH has found.' It clearly distinguishes the tool from the sibling that actually runs a check, set_competitor_watch, by explicitly saying this tool 'never triggers a check.' The scope is concrete: new ads since last check plus watch state.

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?

The description gives explicit use cases: answering 'what are our competitors running that's new?', feeding a teardown, or saving items with save_to_swipefile. It also names the alternative for triggering a run: set_competitor_watch({runNow:true}). This gives an agent clear when-to-use and when-not-to-use guidance.

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