Scores whether AI assistants can read, understand and quote a public website. No account.
Score is being calculated.
Reports how many visits each AI assistant sent to a site that runs the free OperStack counter. Needs the private token from the counter link, which only the site owner has. Returns visit counts per assistant, not individual visitors.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days back to report. Default 90. | |
| token | Yes | The private token from your counter link (the part after t=) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent and non-destructive behavior, so the description's job is narrower. It still adds real context beyond them: the access constraint (a private token only the site owner holds) and the aggregation granularity (per-assistant counts, not individual visitors), which tells the agent what the data can and cannot answer.
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 what is reported, then the prerequisite, then the data granularity. No filler and nothing buried.
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 two-parameter tool with no output schema, the description covers purpose, prerequisite and return semantics (aggregate counts per assistant). It does not describe the default 90-day window or response shape, but the schema covers the window and the omissions are minor at this 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?
Schema description coverage is 100%, so the schema already documents both parameters, including that token is the part after 't='. The description reinforces who can supply the token but adds no syntax or format detail for the days window, 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?
The description names a specific verb (reports/counts) and resource (AI assistant visits to a site using the OperStack counter), which is plain and concrete. It does not explicitly differentiate itself from siblings like my_visibility or who_instead, but the resource is distinct enough that an agent can separate them.
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 rather than stated: the tool only works for a site running the OperStack counter and requires the private owner token. There is no explicit when-to-use versus when-not, and no alternative tool is named for adjacent questions such as overall visibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scores any public site out of 100 on the five things an answer engine needs before it will quote a page: whether AI crawlers are allowed in, whether there is a map for agents (llms.txt), whether the entity is clear from schema, whether there is anything quotable, and whether pages carry dates and sources. Use it when someone asks whether ChatGPT or another assistant can read and quote a site. Reads up to 10 public pages. A site that turns away automated readers cannot be scored.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A public site address, for example example.com | |
| lang | No | Language of the findings. Default en. Use ru when the site or the person is Russian. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, idempotent, open-world read, so the description only needs to add beyond that. It does: it discloses the crawl budget ('Reads up to 10 public pages') and a genuine failure mode ('A site that turns away automated readers cannot be scored'), both of which an agent needs before invoking.
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 action and score scale, then the trigger condition, then the crawl limit and precondition. Four sentences that each add something, though the five-criterion enumeration makes it slightly long for the payload it delivers.
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?
No output schema exists, and the description compensates by naming the 0-100 scale and the five scored dimensions, giving the agent a sense of the return. The precise output shape and whether the ten-page result set is itemized remain unstated, keeping it short of 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 description coverage is 100%, so both url and lang are already documented in the schema, including the enum guidance in lang. The description adds nothing about parameter format or behavior beyond 'any public site'. Baseline 3 is appropriate when the schema carries the full parameter burden.
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 ('Scores any public site out of 100') and enumerates the five concrete dimensions being scored (crawler access, llms.txt, schema/entity clarity, quotability, dates and sources). This clearly distinguishes it from narrow siblings like check_llms_txt or check_counter_installed, which each probe one of these facets.
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 trigger condition: 'Use it when someone asks whether ChatGPT or another assistant can read and quote a site.' It also states an exclusion ('A site that turns away automated readers cannot be scored'). It does not name a sibling alternative for follow-up actions, but the when-to-use guidance is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Looks at a site page and says whether the OperStack visit counter line is really there, including the case where it is there carrying a different key. Use it when a counter reports nothing and the owner does not know why.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The site key from the snippet, starting osv_ | |
| domain | Yes | The site to look at |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds real behavioral nuance beyond them: it fetches and inspects a live page, and it detects the specific case where the counter is installed under a different key. It leaves rate limits and the shape of the answer unstated, keeping it out of 5 territory.
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, zero filler: the capability and its distinguishing edge case come first, and the when-to-use trigger comes second. Nothing is repeated from the name or schema.
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 diagnostic check with annotations supplying the safety profile, the description is nearly sufficient. The one gap is that, with no output schema, it does not say what the answer looks like (a verdict, the detected key, or both), though 'says whether' implies a yes/no result.
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 (key with the osv_ prefix convention, domain) are already documented. The description's mention of a 'different key' scenario gives slight context about how key is used, but adds no syntax or format information beyond the schema. 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 verb and resource: it inspects a site page and reports whether the OperStack visit counter snippet is present. It goes further by naming the edge case it handles (counter present but under a different key), which separates it from generic siblings like audit_site or ai_visits.
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 triggering condition: 'Use it when a counter reports nothing and the owner does not know why.' That is concrete diagnostic guidance. It does not, however, name a when-not condition or route the agent to a specific alternative tool for other failure modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a site llms.txt, the file that tells an assistant which pages matter, and follows its links to see whether they still lead anywhere. Use it when someone asks about llms.txt or whether their map for AI assistants works.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A public site address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds meaningful behavior beyond that: the tool follows outbound links and validates that they still lead somewhere, which is a nontrivial fan-out not implied by openWorldHint alone. It omits rate limits, timeouts, and result 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 padding. The functional description is front-loaded and the usage trigger follows immediately; 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 one-parameter read-only checker with no output schema, the description conveys what is inspected and the gist of the result (whether links still resolve), which is enough for correct invocation. It could say more about what a failure/report looks like, but nothing critical 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?
Single parameter with 100% schema description coverage ('A public site address'), so the schema already carries the semantics. The description adds no format, protocol, or domain-level detail beyond what the schema provides; 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 verb (reads, follows links) and resource (a site's llms.txt), and explains the scope of the check: validating whether the linked pages still resolve. An agent can distinguish this from broad siblings like audit_site or compare_sites 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 when someone asks about llms.txt or whether their map for AI assistants works.' It does not name a when-not condition or a sibling alternative (e.g., vs audit_site), 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.
OperStack Watch subscribers, with their key. Scores a competitor site out of 100 on the same rules as the OperStack free check and the Watch email, and puts it next to the subscriber's own score from the last weekly check.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The competitor site, for example rival.com | |
| site | No | Only if you watch more than one site: which one, for example example.com. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the read-only, idempotent, open-world safety profile, so the bar is lower. The description adds genuinely new behavioral context: a Watch subscription and key are required, the result is a 0-100 score benchmarked against the subscriber's own last weekly check, and it consumes/relates to the weekly check data.
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, front-loaded with the audience/key prerequisite and followed by the core action and the comparison output. Nothing is wasted, though the reference to 'the OperStack free check and the Watch email' is slightly indirect for an agent with no prior context.
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 carries the burden of explaining the return value, and it does so by stating the score is out of 100 and is shown alongside the subscriber's own prior score. For a two-parameter read-only scoring tool this is largely sufficient, though it stops short of describing error/fallback behavior when no prior weekly check exists.
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 (url, site) are already documented with examples in the schema, making 3 the baseline. The description adds only marginal value, implicitly confirming that 'competitor site' maps to url and that a subscription may cover multiple watched sites.
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: it scores a competitor site out of 100 and places that next to the subscriber's own score. The 'same rules as the OperStack free check and the Watch email' phrasing clarifies how the score is derived, but it never names a sibling tool (e.g., compare_sites, audit_site, who_instead) that an agent might otherwise pick, so differentiation is implicit rather than explicit.
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 opening 'OperStack Watch subscribers, with their key' signals the audience and a prerequisite, which implies when the tool is applicable. However, there is no explicit when-not guidance and no named alternative for non-subscribers or for own-site checks, leaving the agent to infer that audit_site/compare_sites cover those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs the same AI-visibility scoring on two to four sites and returns them side by side, so a score means something. Use it to see where a site is losing answers to a rival, area by area. A site that turns away automated readers is reported as unreadable.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the findings. Default en. | |
| urls | Yes | Two to four public site addresses |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and openWorld, so safety is covered. The description adds real behavioral value: results are returned side by side for comparability, and a site that blocks automated readers is reported as unreadable rather than failing silently.
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 operation and scope. 'So a score means something' is slightly promotional but functions as the rationale for the comparison, so little is wasted.
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 low-parameter, read-only tool with full annotation coverage and a 100%-documented schema, the description is nearly sufficient: it conveys the comparison output shape and the unreadable-site edge case. No output schema exists, but the return is described in prose.
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% (urls and lang both documented, including the en default), so the schema carries the parameter burden. The description reinforces the 2-to-4 site constraint on urls but adds no format or syntax detail beyond it.
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 ('Runs the same AI-visibility scoring on two to four sites and returns them side by side'), with the multi-site scope making it distinguishable from single-site siblings like audit_site. It doesn't name a sibling directly, but the comparison purpose is 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?
'Use it to see where a site is losing answers to a rival, area by area' gives a clear use context. However, it offers no explicit when-not guidance or routing against near-neighbors such as audit_site or check_rival, leaving the agent to infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OperStack Watch subscribers, with their key. The fix of the week from the last Watch email: the buyer question it answers, who ChatGPT named instead, what to change, and the text to put on the site, word for word as in the email.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Only if you watch more than one site: which one, for example example.com. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior, so the bar is lower. The description still adds real context beyond them: the call is subscription/credential-gated, and the returned copy is verbatim from the email ('word for word as in the email'), which tells the agent the content is exact and pre-packaged rather than generated.
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, front-loaded with the audience and the source of the content, then a compact enumeration of the return payload. The opening fragment ('OperStack Watch subscribers, with their key.') is slightly clipped, but there is no 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?
With no output schema, the description carries the burden of explaining what returns, and it does so by listing the payload fields. Auth prerequisites are stated and the single param is covered by the schema, leaving only sibling differentiation as a gap.
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 one optional parameter with 100% schema description coverage, so the schema already explains 'site'. The description never mentions it, so it adds no meaning on top of the structured field — 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 identifies a specific resource — the fix of the week from the last Watch email — and enumerates its contents (buyer question it answers, who ChatGPT named instead, the change, the site copy). It is clear what comes back, but it never distinguishes this from adjacent siblings like who_instead or what_changed, and the verb is implied rather than stated.
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 states a prerequisite audience and auth requirement ('OperStack Watch subscribers, with their key'), which implies when the tool is valid. However, it gives no guidance on when to use this versus the many sibling tools listed, so usage remains inferred rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OperStack Watch subscribers, with their key. Shows the 10 buyer questions Watch asks ChatGPT and Perplexity every week. Can also replace one question (number and new text) or all ten. Only change questions when the person asked for it. Changes apply from the next weekly check, and history starts again for a changed question.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Only if you watch more than one site: which one, for example example.com. | |
| number | No | To replace one question: its number, 1 to 10. | |
| question | No | To replace one question: the new question, at least 5 words. | |
| questions | No | To replace all ten: exactly 10 different questions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the annotations by disclosing the access requirement (Watch subscribers with a key), the effective timing (changes apply from the next weekly check), and a meaningful side effect (history restarts for a changed question) that the idempotentHint/destructiveHint flags do not convey. The history reset is worth noting against destructiveHint=false, but since it is a side effect of an update rather than data deletion, it is a soft tension rather than a contradiction.
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 audience and function, then the conditional guidance, then the effect of changes, with no redundant sentences. The opening fragment ("OperStack Watch subscribers, with their key") is terse and slightly clipped, but overall the text is tight and well ordered.
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 4-parameter read/write tool with no output schema, the description covers authentication, the read payload (the 10 questions), the write modes, and the timing of effects. The only real gap is that the return shape of the read is only implied, but it is adequate for correct 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%, and every parameter's semantics (site, number, question, questions) plus the constraints (1-10, at least 5 words, exactly 10 different) are already documented in the schema. The description restates the one-question-vs-all-ten modes but adds no syntax or format detail beyond what the schema provides, 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 specific verb and resource: shows the 10 buyer questions Watch asks ChatGPT and Perplexity weekly, and can replace one or all ten. This is clearly distinguishable from siblings like my_visibility, what_changed, and who_instead. An agent can tell what the tool does 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 explicit when-to-change guidance: "Only change questions when the person asked for it," establishing read as the default and write as the exception. It does not name an alternative sibling for related tasks, but the read-vs-write condition is clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OperStack Watch subscribers, with their key. Whether ChatGPT (and Perplexity, when it answered) named the subscriber in answers to their 10 buyer questions at the last weekly check, the trend week by week, and the share of answers against the competitors named. The same numbers as that week's Watch email.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Only if you watch more than one site: which one, for example example.com. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds useful behavior beyond that: it requires a subscriber key, it is a snapshot 'at the last weekly check,' and it mirrors 'that week's Watch email' — clarifying cadence and data provenance/timeliness.
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 text is a run-on sentence fragment with no leading verb, and the opener 'OperStack Watch subscribers, with their key' is a confusing preamble rather than a front-loaded statement of what the tool does. The valuable content (citation results, trend, share) is buried mid-sentence.
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, single-parameter tool with no output schema, the description does describe the returned content (citation status, weekly trend, competitor share) and its source. It still lacks a clean action statement and any routing guidance, which an agent needs to choose it over visually similar siblings.
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 'site' parameter is fully documented in the schema ('Only if you watch more than one site'). The description adds nothing about the parameter, 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 deliverable: whether ChatGPT/Perplexity cited the subscriber in their 10 buyer questions, the week-by-week trend, and share vs competitors. That is concrete enough to tell what the tool returns. It does not, however, contrast itself with overlapping siblings such as who_instead or ai_visits, so differentiation is left to inference.
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?
There is no explicit when-to-use or when-not-to-use guidance and no named alternatives. The only contextual cue is the implied 'OperStack Watch subscribers, with their key' prerequisite, which hints at an audience/auth requirement but not when to call this over siblings like what_changed or who_instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OperStack Watch subscribers, with their key. What moved between the last two weekly checks: how many answers named the subscriber in ChatGPT and Perplexity, the share of answers against each competitor, and the buyer questions where they were named or dropped.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Only if you watch more than one site: which one, for example example.com. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, idempotent, closed-world read, so the safety burden is lifted. The description adds genuinely useful behavioral context beyond them: access is gated on a Watch subscription with a key, and the output is scoped to a fixed weekly comparison window rather than an arbitrary range. It does not discuss rate limits, latency, or what happens on the very first run when only one check exists.
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, front-loaded with the audience/access condition before the content list, and every clause contributes something. It is dense with product vocabulary and the opening fragment ('OperStack Watch subscribers, with their key.') reads as a prerequisite label rather than a sentence, which costs it the top score.
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 must describe the return, and it does so concretely across three result categories, which is the main thing an agent needs. Remaining gaps are the multi-site default behavior and the failure mode when fewer than two weekly checks exist.
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 one optional parameter with 100% schema coverage, so the schema already carries the meaning and the baseline of 3 applies. The description adds nothing about the site selector beyond what the schema description ('Only if you watch more than one site') already states.
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 deliverable — the movement between the last two weekly checks — and enumerates its contents (named-answer counts in ChatGPT and Perplexity, share against each competitor, buyer questions where the subscriber was named or dropped). That is far more specific than a restatement of the name. It stops short of 5 because it never contrasts itself with close siblings such as my_visibility or compare_sites, so the agent must infer that this is the delta view rather than the current-state view.
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 framing: it is for OperStack Watch subscribers, and it reports the diff between two weekly checks, so an agent can infer it answers 'what moved this week'. However, there is no explicit when-to-use statement and no routing against alternatives like my_visibility or who_instead, so selection still relies on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OperStack Watch subscribers, with their key. For each of the 10 buyer questions at the last weekly check: whether ChatGPT (and Perplexity) named the subscriber, and which businesses they named instead. Then the sites these answers were built from and where to get mentioned.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Only if you watch more than one site: which one, for example example.com. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a safe, idempotent, non-destructive read (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower. The description adds real value beyond them: the cadence ('last weekly check'), the fixed scope (10 buyer questions), the two answer engines covered, and that source sites plus mention guidance are returned.
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 is reasonably short and front-loads the scope, but the opening 'OperStack Watch subscribers, with their key' is a dangling fragment that wastes the prime position, and the output list is a run-on rather than cleanly structured.
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 usefully enumerates what comes back (named-or-not per question, competitors named, source sites, mention guidance), which is adequate for the return contract. However it leaves prerequisites and alternative-tool routing implicit for a tool with 11 siblings, so it is only minimally 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?
One optional parameter with 100% schema description coverage, so the schema already documents 'site' and its multi-site condition. The description never refers to the parameter, so baseline 3 applies with no added syntax or semantics.
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 subject (whether ChatGPT and Perplexity named the subscriber for the 10 buyer questions at the last weekly check) and the specific payload (which businesses were named instead, plus the source sites). An agent can distinguish it from siblings like my_visibility or check_rival, though the opening fragment 'OperStack Watch subscribers, with their key' muddies the 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?
Usage is only implied through the name and content ('who ChatGPT names instead of us'). It notes subscribers and their key as a prerequisite but never says when to call this versus my_visibility, check_rival, or compare_sites, nor states exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
ai_visitsaudit_sitecheck_counter_installedcheck_llms_txtcheck_rivalcompare_sitesfix_of_the_weekmy_questionsmy_visibilitywhat_changedwho_insteadCheck whether AI assistants can reach, read and cite a public website. No account for 4 of 5 tools.
See how ChatGPT, Claude, Gemini and Perplexity read any website. Scored out of 100.
Free GEO score of a web page or text: how easily AI assistants can quote it, with fixes. No key.
Checks whether a website is readable and citable by AI systems (ChatGPT, Claude, Perplexity, etc.)
Add one secure layer between your agents and this server.