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

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that the tool returns a summary with observation history and freshness, which is useful. However, it does not address auth requirements, side effects, rate limits, or output structure, leaving some behavioral gaps.

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 short sentences deliver the core purpose, output contents, and usage intent with no filler. The information is front-loaded and every phrase 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 simple one-parameter tool with no output schema, the description is nearly complete: it states what the tool returns and why an agent would call it. The only minor gap is not specifying the exact shape of the summary response, but the description gives enough orientation for correct use.

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 already documents the single 'domain' parameter with an example, and the description adds no additional semantic meaning beyond restating that the summary is for a domain. Schema coverage is 100%, so a baseline of 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?

The description clearly identifies the tool as producing a company-level summary and specifies its contents: what is observed, since when, and how fresh. It distinguishes itself from deeper siblings like get_company_state or get_company_changes, though it does not explicitly name them or use a direct verb.

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 phrase 'Use to decide whether deeper calls are worth it' provides explicit context for when this tool is appropriate. It does not name alternative tools or state when not to use it, so it falls short of full guidance.

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 burden of explaining behavior, and it does add useful context by noting that the result includes before/after states and evidence. However, it does not clarify the meaning or bounds of 'recent', nor does it explicitly state whether this is a read-only operation, though the 'get' naming convention helps.

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 brief and front-loaded, leading with the core result type before adding a user-question framing. The second sentence repeats the intent in a different form but is short and helpful, so there is minimal waste.

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 single-parameter tool, the description covers the domain input and describes the output shape (recent changes with before/after and evidence). However, without an output schema and with no time-window definition or differentiation from timeline/technology siblings, an agent is left with some ambiguity about scope and expectations.

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 already documents the single 'domain' parameter at 100% coverage, so the description does not need to compensate for a coverage gap. It adds no additional parameter-level meaning, such as domain format, examples, or validation constraints, so the baseline score of 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?

The description clearly identifies the tool as returning recent technology/infra changes with before/after and evidence, so an agent can understand the core purpose. It does not use an explicit retrieval verb, and it does not sharply distinguish this from siblings like revnuvo_get_company_timeline or revnuvo_get_company_technologies, but the unique combination of before/after evidence makes the intent reasonably clear.

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 phrase 'Answer what changed at X?' gives a concrete user-intent signal and suggests when the tool is relevant. However, it provides no exclusion criteria, no alternatives, and no comparison to closely related sibling tools such as revnuvo_get_company_timeline or revnuvo_get_company_state.

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 burden of behavioral disclosure. It does reveal that data is 'observed' and 'latest', and mentions fingerprint freshness, implying a potentially cached or stale snapshot rather than a live fetch. However, it does not disclose side effects, failure modes, or whether the domain must already be monitored.

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 sentence with the core purpose front-loaded and the specific output components compactly parenthesized. Every word earns its place and there is no redundant phrasing.

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 tool with no output schema and no annotations, the description provides enough orientation: it names the main output aspects and the intended question type. It could be more complete about output format and error situations, but this is adequate for the tool's low complexity.

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 fully describes the only parameter, 'domain', with a type and example format. The description adds no additional semantic detail about the parameter, so the baseline score 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 that the tool returns the latest observed state of a domainizen and names three concrete components: technologies, fingerprint freshness, and observation hash. The phrase 'as of now questions' helps distinguish it from timeline and changes siblings, though it lacks an explicit action verb like 'get'.

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 explicitly scopes the tool to 'as of now' questions, which is a clear usage context that differentiates it from historical/change-oriented sibling tools. It does not name alternative tools or state when not to use it, so it stops short of full routing guidance.

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 present, so the description carries the full burden for behavioral disclosure. It mentions that results include detection evidence and confidence, but it does not state whether the operation is read-only, requires auth, has rate limits, or behaves on missing/unknown domains. The read-only nature is inferred only from the tool name.

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 short sentences with no filler; the core purpose is front-loaded and the use-case context is provided in the second sentence. Every word contributes.

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 read operation with no output schema, the description effectively conveys the return value shape (evidence and confidence) and the resource. It could be more complete with explicit usage exclusions or behavioral notes, but what is present is sufficient for basic 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?

The only parameter, domain, has 100% schema description coverage as 'Company domain'. The description does not add any additional semantic detail beyond what the schema already provides, 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 clearly states the tool returns detected technologies for a domain and specifies the output includes detection evidence and confidence. The phrase 'what does X run on?' makes the tool's purpose and answer type explicit, and it is distinct from sibling tools like revnuvo_get_company_state or revnuvo_get_company_timeline.

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 when to use the tool via the question 'what does X run on?', providing a clear context. However, it does not name alternatives or state when not to use it, so guidance is implicit rather than explicit.

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. It discloses chronological ordering and the free-plan time window, but it does not describe return format, pagination, authentication needs, or whether the operation is read-only. This is thin behavioral coverage for a tool with no annotation safety hints.

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 short sentences, no filler, and the core action is front-loaded. The free-plan note is valuable and efficiently included.

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 and no annotations, the description is the only source of behavioral context. It is too sparse to fully support invocation, especially given the likely overlap with get_company_changes and the lack of any description of what events look like or how limit interacts with the timeline.

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 both parameters are already documented in the schema. The description adds no extra semantic detail beyond tying the tool to a domain, which is sufficient for the baseline score of 3.

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 is a chronological change timeline for a domain. It clearly separates it from state, technologies, search, monitor, verify, and get_company siblings, but it does not distinguish it from the similarly named get_company_changes 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?

No guidance is given about when to use this tool versus siblings such as get_company_changes or get_company_state. The only contextual hint is the free-plan 7-day limitation, which is a constraint, not a usage guideline.

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 disclosure burden and does disclose that invocation is non-atomic: a baseline scan runs immediately and rechecks happen on a schedule, with delivery depending on webhooks. It doesn't mention idempotency, cancellation, or delivery payloads, but the core asynchronous behavior is clearly conveyed.

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 compact sentences front-load the action and scheduling behavior, then state the plan requirement. There is no redundant filler or restating of the tool name.

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 one-parameter monitor-setup tool, the description covers the action, immediate baseline, scheduled rechecks, and delivery requirement. However, with no output schema, it doesn't explain what the call returns or how to retrieve results, and it doesn't address duplicate monitors or how to stop monitoring, leaving minor gaps.

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 already documents 'domain' with a clear description ('Company domain to monitor'), and the description's mention of 'domain' adds no format, normalization, or validation details. Since schema coverage is 100%, 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 uses an active verb ('watch') and specifies the resource (a domain) and core behavior (baseline scan immediately, scheduled rechecks). This clearly distinguishes it from sibling get_* and search tools, which are one-time queries.

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 for ongoing change monitoring and states the webhooks plan prerequisite, but it doesn't explicitly explain when to prefer this tool over siblings like get_company_changes or verify_company. Prerequisite information is present, but comparative usage guidance is absent.

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 discloses that the operation is a read-only search over known companies and that results contain matched domains with observation recency. It does not mention result limits, sorting, minimum query length, or what happens with no matches, so transparency is adequate but not rich.

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?

A single, front-loaded sentence communicates the operation, input kind, and return content without wasted words.

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 search with no output schema, the description covers what the tool searches, what input it takes, and what it returns. It would be more complete if it described the shape or cardinality of results, but nothing essential is missing for invoking it.

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 already documents the single query parameter with a clear description and examples, so coverage is 100%. The tool description restates that the query is a name or domain fragment, adding no significant meaning 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 specifies a concrete action—searching known companies by keyword—and identifies the input as name or domain fragment. It is distinguishable from sibling tools like revnuvo_get_company or revnuvo_search_signals, though it does not explicitly name any alternative.

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 phrase 'by keyword (name or domain fragment)' gives a clear condition for when to call this tool, and 'known companies' scopes the search space. However, it offers no guidance on when to prefer a sibling such as revnuvo_get_company or revnuvo_search_signals instead.

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 burden. It discloses ranking by score, inclusion of evidence, and a 7-day lookback on the free plan, but it does not mention return shape, pagination, or read-only behavior.

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?

Single sentence, front-loaded with the core purpose, and enriched with two examples and a plan limitation. No filler or redundancy.

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?

Adequate for a simple 2-parameter search, but with no output schema or annotations, the description omits return structure and sorting details that would help an agent fully understand the result. It remains usable, but not complete.

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%, so the baseline is 3; the description adds concrete query examples ('migrated from', technology name) that go beyond the schema's generic 'Signal keyword' and clarify expected input.

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 clearly identifies a cross-company buying/intent signal search ranked by score, distinguishing it from sibling tools scoped to a single company (e.g. revnuvo_get_company_timeline). It lacks an explicit verb, but the resource and scope are 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 phrase 'cross-company' implies use against company-specific sibling tools, but no explicit when-to-use or alternative is named. 'Free plan: last 7 days' adds a temporal constraint but not usage context.

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. It adds useful behavioral detail by mentioning live HTTP + DNS evidence and on-demand execution, but it does not disclose side effects, permissions, rate limits, or whether the pass is read-only. This is a moderate gap for a no-annotation 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 short sentences carry purpose, evidence type, and usage context with no filler. The core action is front-loaded before the use-case guidance.

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?

The tool is simple (one required parameter), and the description covers what and when, but with no output schema it does not hint at the return shape or how a failed verification is represented. For a verification tool this is a meaningful but not critical omission.

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 schema already documents 'domain' as the company domain to verify. The description repeats 'domain' without adding format or normalization details, so it adds no parameter meaning beyond the baseline.

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: 'verification pass of a domain' with 'live HTTP + DNS evidence.' It clearly differentiates from sibling retrieval/monitoring tools by framing itself as an on-demand confirmation step, so an agent can tell it apart from get/search/monitor tools.

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 phrase 'Use to confirm a signal before acting on it' provides an explicit when-to-use context. It does not name alternatives or exclusions, but it is enough to route an agent toward verification rather than search or monitoring.

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