aipozi

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real substance by saying the plan derives from the latest check, that moves are ranked by how many questions and AIs each can win, and that it includes rival and source-page context. It does not discuss freshness/latency or what happens when no check exists yet.

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?

Front-loads what the plan is, then the usage example and the follow-on tools; every sentence carries information. The opening sentence is dense with nested clauses, which costs a little readability but not 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?

Output schema exists so return shape needn't be explained, the sole parameter is fully documented, and annotations cover the safety profile. The description fills its remaining job: what the plan contains and how to act on 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?

Single parameter with 100% schema description coverage that already explains domain/id/name forms and the omit-when-one-site case. The description adds no syntax or default 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?

States a concrete resource and verb: 'One site's plan from its latest check', then enumerates what the plan contains (per-AI naming reasons, ranked moves, rivals beaten, pages read instead). It is clearly distinct from siblings like questions or rivals, though it does not explicitly contrast with the close neighbor 'briefing'.

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?

Gives an explicit trigger phrase ('what should I improve first on biotree.bio?') and routes the agent onward: use build_prompt to hand a move to a coding session, mark_move_done once shipped. When-to-use and next steps are both named, leaving little to inference.

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?

Annotations already declare read-only, idempotent, non-destructive, open-world behavior. The description adds useful context that the answer is stored verbatim with cited pages and should be quoted as that AI's words, plus latest-vs-date 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?

Front-loads the core definition, then adds quoting guidance and concrete examples. Three sentences, no filler, and every part 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 an annotated read-only retrieval with full schema coverage and an output schema, the description supplies the exactness, citation, and date-scope details an agent needs. No important behavioral or usage gap remains.

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 schema already documents all four parameters including question formats, AI enum, date, and site. The description reinforces the one-question/one-AI and latest/date semantics but adds little parameter syntax beyond the schema, so the baseline 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 retrieval: one AI's verbatim answer to one question, with cited pages, from the latest check or a given date. It clearly conveys the resource and scope, but does not explicitly name or contrast sibling tools such as questions or briefing.

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?

Provides clear usage examples, including exact-quote and recommendation-style queries. It gives strong positive guidance but no explicit when-not guidance or named alternatives.

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?

Annotations already establish readOnly, openWorld, idempotent, non-destructive, so the safety bar is low. The description still adds real behavioral context: results are 'read live' (not cached/stale), there is no auth or cost barrier ('Free, no sign-in'), and the response includes concrete remediation lines—details an agent could not infer from the annotations alone.

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 dense sentence with the core subject front-loaded ('Whether each AI's crawlers ... are allowed'), followed by coverage scope and then the remediation detail. It is long but every clause—vendors, bot classes, live read, output lines, free/no sign-in—carries information; only mild cost is that it reads as one run-on.

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 an output schema present, the description need not explain return values, yet it usefully previews that results include remediation lines. Combined with the live-read and no-auth notes, an agent has enough to call this correctly; the only missing piece is explicit positioning against the sibling domain-analysis tools.

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 single domain parameter is documented in-schema with an example format. The description only implies the input is a site/domain; it adds no syntax, normalization, or edge-case handling beyond the schema, so 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?

States a specific resource (robots.txt AI-crawler permissions) and enumerates the vendors and bot classes covered (OpenAI, Anthropic, Perplexity, Google, Microsoft; search/user/training), so an agent knows exactly what question this answers. It stops short of naming which sibling (e.g. check_domain) it is not, so sibling differentiation is only implicit.

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?

Usage is implied by the enumeration of crawler vendors and the 'exact lines to add when a search crawler is blocked' framing, which hints at a remediation use case. However, there is no explicit when-to-use/when-not guidance and no named alternative among check_domain, domain_rating, or rivals for an agent to route against.

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?

Annotations already cover read-only, idempotent, non-destructive, open-world. The description adds genuinely non-redundant behavior: every figure is 'stamped with the check time', refresh happens only at 05:00 GMT, and calling the tool does not trigger a check - so the agent knows the data's staleness profile before invoking. Missing only depth on response size or latency.

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?

Front-loaded with the what and the how-to-use, but the middle is a long run-on enumeration of every briefing field. Since an output schema exists, that catalog largely restates return values and could be trimmed without loss; the schedule and freshness clauses are the only sentences that earn their length.

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 annotations covering the safety profile, a 100%-covered single parameter, and an output schema defining the return payload, the description supplies exactly the missing pieces: usage triggers, the scheduled-task phrasing, and data-freshness semantics. An agent can select and call it correctly from this alone.

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 single site parameter already documents domain, id, or name forms and when to omit it. The description reinforces this by stating the read covers 'all of the person's sites, or one', clarifying the optional parameter's aggregate semantics beyond the schema's per-field note.

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 resource (the daily briefing read) and scope (all sites or one), with concrete content: per-AI mention counts, address, delta since yesterday, lost questions, new rivals, DR, best move. It implicitly ranks itself above siblings with 'Use it first for "how am I doing"', but never names an alternative tool such as trend, questions, or rivals that overlaps in data.

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?

Explicit when-to-use triggers ('how am I doing', 'read me my aipozi briefing', scheduled morning briefing) plus a literal scheduling example ('run daily_briefing from aipozi' every weekday at 07:00). It also sets a clear boundary: checks run at 05:00 GMT and this tool never runs one.

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?

Annotations already declare readOnlyHint/idempotent/non-destructive, so the safety bar is lower; the description adds real context beyond that — the paid-site gating constraint, the correct downstream tool, and the instruction that listed pages are 'to study, not copy'. It stops short of saying what the response looks like on a paid-tier failure or how large the brief is, but the behavioral picture is substantially enriched.

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?

Purpose is front-loaded in the first clause, followed by a compact enumeration and then two short operational sentences. The middle list is dense but each item is a distinct content guarantee an agent would otherwise have to discover; only minor tightening is possible.

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?

An output schema exists, so return values need not be explained; the description instead covers the things the schema cannot — repo context, follow-up tool, default argument, and paid-tier restriction. Nothing an agent needs before calling is missing.

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 both parameters are already fully documented, including the move-id format and site identifier forms. The description only echoes the default ('the top move') and adds no format or edge-case detail beyond the schema — baseline 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 names a concrete verb and resource — 'One move of a site's plan as a complete, self-contained brief for a coding agent' — and then enumerates exactly what the brief contains (goal, target questions, rivals, pages read, page anatomy, prohibitions, measurement). An agent can tell this apart from action_plan or briefing without opening either schema.

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 says where to run it ('In a coding session opened on the site's repo'), what to do afterwards ('implement it, then call mark_move_done'), the default behavior ('Default: the top move'), and a hard eligibility gate ('Paid sites only, as in the app'). That is explicit use, follow-up, default, and restriction in one pass.

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?

Beyond the read-only annotations, the description explains that results come live from each registry via RDAP or WHOIS, that the service is free and needs no sign-in, and that aipozi does not register names. It also describes the result categories, including registrar links, registration dates, ages, and uncheckable cases.

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 front-loaded with the core question and usage conditions, and most sentences add practical value. It is somewhat dense and conversational, but not redundant enough to obscure the main operation.

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 the annotations and output schema, the description covers what an agent needs: when to call it, how it queries registries, what kinds of results to expect, and the important boundary that it only checks availability and does not register names.

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 input schema already carries most parameter meaning. The description adds some operational context, such as free names being returned first, but much of the parameter behavior it mentions is already present in the schema field descriptions.

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 opening question and subsequent sentences state a specific action and resource: checking whether domain names are available across registries. It is clearly distinct from sibling domain-information tools such as domain_age and domain_rating because the description is entirely about availability, not historical or reputation data.

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 concrete triggering scenarios: naming an app, product or company, asking for a name with a free domain, or asking whether a .com exists. It also sets a hard usage rule: always use this tool for availability and never guess from DNS or memory.

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?

Goes beyond the readOnly/idempotent annotations by disclosing the data path ("read live from the registry's own record (RDAP, else WHOIS)"), the privacy boundary ("Never owner details"), and the access model ("Free, no sign-in"). It also flags the derived signals — estimated drop date and Ahrefs Domain Rating — so the agent knows what it will and won't get.

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?

Front-loaded with the verb and the returned fields, with caveats (never owner details, free, no sign-in) kept short. The run-on field list and the quoted-example tail are slightly bloated but still earn their place as disambiguators.

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?

An output schema exists, so return structure needn't be re-explained, and the description still covers source, privacy, auth, and the bonus DR field. The only gap is the missing guidance on overlapping siblings and on failure modes for unregistered domains.

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 domain property already documents that a link is accepted, so the description only adds the phrase "any domain." It provides no syntax, normalization, or error-behavior detail beyond the schema 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?

States a specific verb and resource ("WHOIS / RDAP lookup for any domain") and enumerates exactly which fields it returns. It is clearly separable from siblings like domain_rating and check_domain because it names registry data as the core payload.

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 trailing quoted queries ("whois heya.page", "how old is this site", "is this domain expiring") give concrete triggers that map user phrasing to this tool. However it never says when to prefer check_domain or domain_rating instead, and the DR overlap with the domain_rating sibling is left unexplained.

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?

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld). The description adds important context beyond annotations: the service is free, requires no authentication, and every answer must carry an Ahrefs attribution line shown with the numbers. It does not mention rate limits, but the added licensing/attribution requirement is a meaningful behavioral disclosure.

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 short sentences, front-loaded with the metric and scope, then the access conditions, then the required attribution. There is no wasted text; each clause carries practical information for invocation.

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 one parameter, full schema description coverage, an output schema, and rich annotations, the description supplies the remaining needed context: cost, auth, attribution requirement, and batch scope. Nothing essential for correct invocation is missing.

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% with one documented domains parameter including examples and a maxItems constraint. The description repeats the batch limit and clarifies 'anyone's' domains, but adds no format or syntax details beyond the schema, 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 the exact metric (Ahrefs Domain Rating, 0–100), the batch scope (up to 25 domains), and that it works for any domain. This is specific and actionable, but it does not explicitly distinguish itself from siblings like check_domain or domain_age.

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 implies usage (look up ratings for any domains) and notes it is free and needs no sign-in, but it gives no explicit when-to-use guidance or alternatives. The agent must infer that this is the tool for rating scores rather than availability or age.

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?

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds useful behavioral detail about the lookback window ('last 7 days') and per-AI breakdown. It says nothing about result size, pagination, or what happens with zero sites, which is the remaining gap.

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?

It uses two sentences: the first front-loads the scope and enumerates the returned fields, and the second explains why to call it. The field enumeration is dense and slightly run-on, but every clause carries 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?

Because the output schema is present, the description need not restate return shapes, and it does explain the temporal scope of the data. It omits edge-case behavior, such as an empty site list or any account prerequisites, which keeps it a point below full completeness.

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?

This tool takes zero parameters, so the baseline of 4 applies, and the schema needs no compensation. The description correctly presents a parameterless call.

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 names a specific action and resource ('Every site the person watches in aipozi') and lists the returned data: id, plan, market, last check time, mention counts per AI engine with address, DR, and a 7-day window. A reader can distinguish this tool from siblings such as rivals or domain_rating without opening a schema.

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 use cases ('see which sites exist, or get a site id for another tool'), which is clear context. It does not name exclusions or say when to prefer a sibling tool instead, so it falls short of 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?

Adds meaning beyond the annotations: it discloses the downstream effect that 'from the next morning's check, briefing and trend show what changed since,' which no structured field conveys. It also restates reversibility with the concrete `undo: true` mechanism, useful even though destructiveHint=false already signals safety. Idempotency is covered only by the annotation, not reinforced in prose.

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 short sentences, front-loaded with what happens and the core trigger, with reversibility and sibling differentiation following. Every sentence carries information an agent needs; nothing is filler.

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 mutation tool this is complete: annotations cover the safety profile, the schema fully documents all four parameters, an output schema exists, and the description still adds the downstream consequence and the undo path. An agent has everything needed to call it correctly and to reverse a bad 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% and all four parameters carry their own descriptions, so the baseline is 3. The description adds only the optionality of the URL; it does not explain `move` id-vs-rank formats or `site` fallback behavior beyond what the schema already documents.

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 ('Records that a move has shipped') and pins down the payload (today's date, optional URL). It also explicitly distinguishes itself from all siblings with 'The only tool that writes,' so an agent can classify it without opening the schema.

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?

Gives an explicit trigger: 'Use it after the person (or their coding session) has shipped the move,' and points to `undo: true` as the correction path. It never states the negative case directly (e.g. do not call before shipping) nor names which sibling to use instead for pre-shipment actions, so it stops short of full when/when-not coverage.

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?

Annotations already declare the tool as read-only, idempotent, non-destructive, and open-world. The description adds useful behavioral context: up to 10 questions, latest check results, last 7 checks, and competitor naming details. It does not discuss freshness beyond 'latest' or truncation behavior, so it is strong but not exhaustive.

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 front-loaded with purpose and avoids filler. The first sentence is dense with enumerated result categories, but every part contributes useful scoping detail.

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 an output schema, rich annotations, and a fully described single parameter, the description is complete enough for an agent to select and invoke the tool correctly. It covers scope, constraints, use cases, and the key alternative.

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 site parameter is fully documented in the schema. The description does not add parameter-specific meaning beyond what the schema 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 specifies the exact resource and scope: one site's questions, latest AI check results, last 7 checks, and competitors named. It also clearly distinguishes the tool from ai_answer, which handles exact AI wording.

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 concrete example questions that map directly to use cases and explicitly routes the agent to ai_answer when exact AI wording is needed. This is clear when-to-use and alternative 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?

The description adds meaningful context beyond annotations: rivals are seen only through the person's own questions, and the result includes every question and AI where the rival was named and the person's site was not. This clarifies data provenance and scope limitations. It does not need to explain return format because an output schema exists, but auth/rate-limit context is absent.

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 front-loaded and every clause contributes useful scope or alternative guidance. It is slightly dense and could be split for readability, but it does not waste sentences.

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 the output schema and read-only annotations, the description supplies the important missing context: the tool only works on rivals observed in the person's own questions, lists all relevant questions and AI mentions, and points elsewhere for general domain age/rating.

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 input schema. The description does not add syntax or meaning beyond the schema's own explanation of when to supply site versus rival. 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?

The description states a specific resource and enumerates exactly what is returned: age, registrar, DR, what the rival does, and every question/AI mention with AI commentary. It also explicitly distinguishes this tool from domain_age and domain_rating for sites outside the person's own checks.

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 concrete use cases in quotes (age/DR about a rival, what AIs said about Linktree) and explicitly names the alternative tools for any site not in the person's own questions. The when-to-use and when-not-to-use boundaries are clear.

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?

Annotations already declare this is a read-only, idempotent, open-world call, so the safety bar is low. The description adds genuinely non-obvious behavior: the data comes 'from the latest check' (freshness), the caller's own DR is prepended to the list, and the scope is one site or all sites. No pagination or result-cap behavior is disclosed, keeping it below a 5.

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 usage sentences are front-loaded and efficient, but the middle sentence is a long run-on enumeration of return fields that duplicates the output schema. Since an output schema exists, that clause spends words on information already structured elsewhere and buries the useful freshness/scope detail.

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?

A single-parameter read tool with an output schema and full annotations does not need much, and the description covers scope, freshness and typical caller intent. The only real omission is how the result behaves at scale (all-sites result size/ordering), which is minor given the output schema.

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?

There is a single optional parameter with 100% schema description coverage, so the schema already explains that omitting it returns all sites. The phrase 'For one site, or all of them' restates the schema rather than adding format or precedence rules, so this is the baseline 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 name and title-plus-description make clear this is a per-site (or all-sites) list of rival domains that AI assistants recommend, with a specific enumeration of what each row contains. It is distinct from the sibling rival_detail, though the description never explicitly says 'this is the list; use rival_detail for one rival', leaving that inference to the reader.

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?

Gives two concrete triggering questions ('who are my competitors?' and 'which new sites are taking my questions?'), which is well above the average tool. It stops short of exclusions or naming rival_detail as the alternative for drilling into a single rival, so it is clear context without full when-not 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: results are bucketed daily, done moves are marked on the timeline, and each carries a 'what changed since' delta. Pagination and volume limits are unmentioned, but the output schema presumably covers the response shape.

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, no filler, with the data shape stated before the usage examples. The phrasing is dense with domain jargon ('named and linked counts'), which costs a little immediate clarity but not length.

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 an output schema, full parameter documentation and rich annotations, the description only needs to establish what the report contains and when to reach for it, and it does both. The jargon around 'moves' and 'named and linked counts' is the main residual ambiguity.

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%, with both parameters fully described including the 7/30/90 enum and the 'leave it out for all sites' default. The description's mention of the three windows and per-site breakdown echoes rather than extends 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 names a specific resource and scope: daily named and linked counts per site and per AI over a fixed set of windows, plus completed moves shown on the timeline. That is far more specific than a restatement of the name 'trend'. It does not, however, distinguish itself from siblings like briefing or rival_detail, so an agent must infer the boundary.

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?

Two concrete example questions ('how have I moved this month?', 'did the comparison page work?') give the agent a clear trigger condition for selecting this tool. There are no explicit exclusions or named alternatives, so it stops short of a 5.

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