citation-tracker

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

With no annotations present, the description carries the full burden of behavioral disclosure. It covers cost, read-only idempotency, concurrent start, per-engine error handling, and the output shape including 'model' and 'structured error per engine'. This is exceptional transparency for a paid, multi-engine tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, with the core action and output summary front-loaded. Every clause adds value: engines, scope, reported fields, concurrency, failure behavior, cost, and retry safety. No filler or repetition.

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

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

Despite lacking an output schema, the description lists the returned fields (cited status, count, domains, model, error) and failure behavior, which is sufficient for an agent to interpret results. Cost and retry safety are included, and input constraints are fully covered by the schema. Complete for a paid read-only API call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with detailed per-parameter info (e.g., domain normalization pattern, engine enum). The description adds context that target domains are the citation objects and prompt is sent verbatim, but does not materially expand on the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Sends one prompt to 1 to 4 search assistants' and reports citation info for 'target domains'. Names the four engines and the exact output fields, making the tool's function explicit. The multi-engine scope also distinguishes it from the sibling per-engine citation_tracker_check_perplexity.

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

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

Does not explicitly name alternatives or give when-not-to-use conditions, but provides clear behavioral context: concurrent execution, failure isolation ('a failed engine returns `cited: null` and does not block the others'), and cost ('$0.75/call'). The 'safe to retry' note gives a practical guideline. Lacks a direct contrast with sibling tools, but the context is strong enough for a 4.

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

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

With no annotations, the description carries the behavioral burden and does so well: it discloses rate limits (one call per caller, 100 per UTC day), that limits fail closed, and the nature of the output (citation count and cited domains). This is meaningful behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no waste. It front-loads the core action and output, then adds the critical rate-limit behavior, and closes with the usage context relative to the paid sibling.

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

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

For a two-parameter tool with no output schema and no annotations, the description covers the main behavior, output elements, limits, and failure mode. It lacks a defined response format but gives enough for an agent to call it and interpret the result generally.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of the parameters with descriptions, so the baseline is 3. The tool description adds little about parameter semantics beyond referencing 'target domains', but the schema already documents prompt and targets thoroughly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it sends one prompt to Perplexity (sonar) and reports whether target domains are cited, along with citation count and cited domains. It also distinguishes itself from the sibling citation_tracker_check by positioning this as a free live evaluation before paying.

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

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

The description gives clear usage context: this is a free, real live evaluation to use before paying for citation_tracker_check. It implies the alternative (the paid check) and the condition for choosing this tool, though it does not explicitly enumerate when not to use it or contrast with citation_tracker_shortlist_gate.

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

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

With no annotations, the description fully discloses behavioral traits: paid once, $18 cost, no refunds, cancel any time, 30-day retention, the monitor_id as the only recoverable credential, and that each run flags changed domains. This is comprehensive and beyond what any annotation would typically provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense sentence that front-loads the core action and then efficiently packs cost, lifecycle, and credential details. There is zero fluff; every clause earns its place, making it both concise and information-dense.

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

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

Given there is no output schema, the description covers the entire workflow: the first run returns the monitor_id, subsequent runs are fetched via status, and cancellation is possible. It also explains data retention. An agent has all necessary information to invoke and manage the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are already documented. The tool description adds value by explaining how parameters interrelate (e.g., 'for one prompt and 1 to 10 target domains' and 'daily or weekly'), enriching the schema's flat definitions with usage context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Buys a monitor') and the exact resource (30 recurring runs of citation_tracker_check) with clear parameters (one prompt, 1-10 target domains, daily/weekly). It distinguishes this from the 7-run sibling by explicitly naming the run count and mentions later retrieval via monitor_status, making the tool's role unambiguous.

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

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

The description provides clear context on when to use it: it's for a 30-run recurring monitor, and it tells the agent how to consume results (monitor_status) and stop (monitor_cancel). It doesn't explicitly contrast with citation_tracker_monitor_7, but the run-count difference is implicit, so an agent can infer the choice.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses pricing ($4.2, $0.6/check), non-refundability, non-recoverable monitor_id, cancellation, and 30-day retention. This is substantial behavioral context beyond what the input schema provides.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences deliver the essential product facts without filler. The first sentence front-loads the core offering, and each subsequent sentence adds a distinct, material fact: execution timing, state retrieval, pricing/cancellation, and retention.

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

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

Even without an output schema, the description names the returned artifacts (first run, monitor_id), the only credential, how to retrieve later runs, and the tool's limits. Combined with a fully described input schema, an agent has enough context to invoke and manage this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already documents each parameter with constraints and examples. The description reinforces that cadence is daily/weekly and targets are 1-10 domains, but it does not add parameter-level semantics beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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: 'Buys a monitor: 7 recurring runs of citation_tracker_check for one prompt and 1 to 10 target domains, daily or weekly.' This clearly distinguishes the tool from one-off check siblings and from the monitor_30 variant by run count.

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

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

It gives explicit lifecycle guidance: the first run happens now, later runs are read via citation_tracker_monitor_status, and cancellation is done with citation_tracker_monitor_cancel. It does not explicitly contrast this with a one-time citation_tracker_check or the 30-run monitor, so it stops short of a full when-not-to-use statement.

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

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

With no annotations, the description carries the full behavioral burden. It explicitly discloses destructive side effects (deletes prompt, domains, results) and the non-refundable nature of unused runs, which is critical for a cancellation tool. It does not mention irreversibility or error behavior, but the destructive scope is clearly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short sentences that front-load the core action and side effects. 'Free.' is slightly extraneous, but the overall text is lean, scannable, and every other sentence contributes essential information.

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

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

For a simple one-parameter destructive tool with no output schema, the description covers the action, deleted resources, cost implications, and required id. It doesn't specify return format or error handling, but the simple input shape and absent output schema reduce the need for more.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: the monitor_id parameter is already fully documented (pattern, source from citation_tracker_monitor_7/_30, and credential status). The description merely restates 'Needs the monitor_id' without adding new semantic information, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Stops a monitor') and its precise destructive scope ('deletes its prompt, domains and results'). This clearly differentiates it from sibling tools like citation_tracker_monitor_7/_30 (creation) and citation_tracker_monitor_status (status checking).

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

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

The description implies usage is for canceling an existing monitor and warns 'Unused runs are not refunded,' but it does not explicitly say when to use this tool versus alternatives or what conditions would make cancellation inappropriate. No exclusions or alternative tool routing is provided.

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

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

No annotations are provided, so the description carries the full burden. 'Reads' signals read-only behavior, 'Free' discloses the cost profile, and the return contents are spelled out in detail. It does not cover edge behavior such as an expired monitor or an empty run history, but the core behavioral profile is clearly disclosed and nothing contradicts the absent annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with the main verb and resource front-loaded. The long middle sentence earns its length by compressing a full return contract through the reference to citation_tracker_check's rows plus changed_since_last, rather than restating everything. 'Free' and 'Needs the monitor_id' are zero-waste cost and precondition signals.

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

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

With no output schema, the description correctly takes responsibility for explaining return values: remaining runs, next run time, most-recent-first ordering, per-engine rows, and changed_since_last. The single parameter is fully documented in the schema. The only omissions are edge-case behaviors (expired monitors, exhausted run lists), which is minor for a simple status read.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the monitor_id definition is already rich: pattern, length bounds, provenance (returned by monitor_7 or _30), and a credential warning. The description only repeats the requirement with 'Needs the monitor_id,' adding no semantic value beyond the baseline for a fully covered schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb ('Reads') plus a resource ('a monitor') and enumerates exactly what is returned: remaining runs, next run time, and run history. It also distinguishes itself from the sibling citation_tracker_check by stating its output is the same per-engine rows plus changed_since_last, so an agent can tell them apart 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.

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

States the precondition 'Needs the monitor_id,' and the schema adds that this id comes from citation_tracker_monitor_7 or _30, telling the agent the tool only applies once a monitor has been created. It also discloses that it is 'Free.' It stops short of explicitly naming alternatives or exclusion conditions (e.g., use monitor_cancel to stop, or citation_tracker_check for one-off checks), which keeps this at a 4 rather than a 5.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses that the call is paid ($0.20/call), read-only, and safe to retry, plus the whole-word match behavior. This is strong context for an agent deciding whether to invoke and retry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with no filler: the function is front-loaded, the usage guidance follows, and the cost/safety caveat closes. Every clause earns its place.

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

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

For a read-only gate tool with no output schema, the description covers purpose, usage context, matching semantics, cost, and retry safety. It does not explain return structure, but for a boolean gate-style check this is sufficiently complete for correct selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds the whole-word match nuance and ties the supplied brand/product terms into the search-query matching behavior. This is helpful but does not add format or syntax detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states exactly what the tool does: checks whether ChatGPT would search the web and whether the first query matches supplied brand/product terms. This is a specific verb+resource description that clearly differentiates it from the downstream citation_tracker_check tool.

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

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

It explicitly instructs agents to use this as a gate before spending on citation_tracker_check, which is clear usage context. It does not mention exclusions or when to prefer citation_tracker_check_perplexity, but the primary routing guidance is present.

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