INITE Visibility

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

Goes well beyond the annotations by disclosing that this is an asynchronous run that takes about a minute and returns a run_id for polling, plus concrete rate limits (two a day per address) and tiered allowances. The annotations only flag non-read-only, non-idempotent, open-world; the description supplies the operational context an agent actually needs.

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 scope before the operational details, and each sentence carries weight (scope, async flow, quotas). It is dense and somewhat run-on with nested parentheticals, but nothing is wasteful.

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, return values need not be described; the description instead covers the async lifecycle, the follow-up call, and quota behavior, which is exactly what remains ambiguous. Nothing an agent needs to invoke it correctly 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% and the single url parameter is already documented with examples ('example.com or https://example.com'), so the description adds little param detail. Baseline 3 applies when the schema does the heavy lifting.

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?

Names a specific verb and resource ('AI visibility audit') and enumerates exactly what it covers: identity files, crawler policy, schema graph, page health, and answer-engine naming. It is clearly distinguishable from siblings like atlas_search or check_identity.

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?

Explicitly routes the agent to the follow-up tool ('call get_analysis with that id') after the run completes, and specifies the conditions under which different account tiers apply. When-to-use and the alternative are both stated.

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 the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds real context beyond them: no account required, no model is invoked, and a semantic distinction between retrieval crawlers (which gate citation) and training crawlers (which cost nothing). It stops short of stating rate limits or latency characteristics, which is the only missing behavioral detail.

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 free/no-account hook and the core value proposition, with the analyze_site routing at the end where it is most useful. The second sentence is dense and comma-chained, packing five return-value items into one clause, which slightly hurts scannability.

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 read tool with annotations and an output schema, nothing an agent needs to call it correctly is absent — auth requirements, model behavior, return categories, and the sibling boundary are all covered. The output schema carries the return shape, so the summary list in the description is a bonus rather than a gap-filler.

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 there is a single required url parameter already documented with a format example, so the schema does the heavy lifting. The description adds no extra syntax, normalization, or domain-handling detail beyond what the schema provides — 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 — read a website the way an AI engine does — and immediately scopes the output (crawler access split between retrieval and training, identity files, Organization schema, score out of 100, fixes). It also explicitly distinguishes itself from the sibling analyze_site, so the agent can pick between them 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?

Gives an explicit when-to-use (before an engine answers about the site) and an explicit when-to-use-the-other ("for whether the engines actually name the site, run analyze_site"). It also removes cost/prerequisite friction up front with "Free and instant, no account."

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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds behavior beyond them: the call is free, resolves instantly, asks no model, and — importantly for budgeting — "counts two identity checks." That quota/cost disclosure is the kind of context an agent cannot get from annotations or schema.

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

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

One dense sentence, front-loaded with the core framing ("Your site against a competitor's, read the way an AI engine reads them") before the output list. The enumeration is long but every item is a distinct deliverable, so little is wasted; it borders on list-heavy for a single 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?

With annotations carrying safety and an output schema present, the description does not need to explain return values — yet it still sketches them, which aids discovery. Combined with the cost/instant/counts-two-checks note, an agent has enough to call this correctly; only the sibling-routing gap keeps it from a 5.

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 both parameters are documented with examples, so the schema already carries param meaning. The description only restates the roles ("your site against a competitor's") without adding format or constraint detail, which is the baseline-3 case when the schema does the heavy lifting.

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 gives a concrete verb+resource (compares two sites as an answer engine reads them) and enumerates the outputs: identity score, crawler access, identity files, Organization schema, and lead differences. It is clear about what the tool produces, but never distinguishes itself from overlapping siblings like atlas_compare, analyze_site, or check_identity, so an agent could still hesitate between 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 only implied by "Your site against a competitor's" — the agent can infer this is for benchmarking one site against a rival, but there is no explicit when-to-use, when-not, or named alternative (e.g. use check_identity for a single site). The note that it is "free and instant" hints at a low-cost choice but does not frame it as a routing criterion.

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 closed-world, so the safety profile is covered. The description adds genuinely new behavior: the response shape changes over the run's lifetime (progress while running, final score and fix list when done) and access is restricted to the caller who started the run, including the guest-address case. Polling cadence and whether a failed run returns a distinct status are not covered.

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

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

Two tight sentences, front-loaded with the verb and source tool, then the access constraint. The rundown of return values slightly overlaps the output schema, but it is brief and does not read as padding.

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 details are optional here, yet the description still signals the progress-to-result transition that matters for polling. Authorization semantics are stated, and with one required parameter and full schema coverage, nothing essential 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% and the single run_id is documented in the schema as 'the id analyze_site returned', so the description's mention of analyze_site adds no new meaning. With only one fully described parameter there is little for the description to contribute 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?

States a specific verb (read) and resource (an audit) and explicitly ties it to the sibling that creates it (analyze_site), while also saying what comes back: progress, then a score out of 100 and top fixes. An agent can distinguish this from analyze_site or visibility_history without opening any 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?

The prerequisite is explicit: this reads an audit started by analyze_site, so the agent knows to call analyze_site first and poll here for progress. It does not name an alternative for retrieving finished results elsewhere, but the workflow context is clear enough to act on.

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the tool returns connection artifacts rather than mutating anything, but discloses nothing further about behavior, prerequisites, or failure modes; with an output schema present, the return-value detail is largely redundant.

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 compact sentences: purpose and trigger first, then the three argument modes, then what comes back. No filler, and the alternative-path information is front-loaded before the parameter recap.

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 zero-required-parameter lookup with full schema coverage, an output schema and complete safety annotations, the description covers the essential unknown (default behavior with no argument) plus the intent trigger. Missing only guidance on what to do if the returned connection information fails or when it should be re-invoked.

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, but the description adds genuinely new meaning: the zero-argument default ('the server beside this one'), which the schema does not state at all. It also glosses `for` as 'the one that does a job' and `all: true` as 'every server,' reinforcing rather than duplicating the enum documentation.

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

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

The description states a specific action (add another INITE MCP server to this client) and frames it as retrieving connection info rather than performing the connection, which the closing sentence about returning a URL, Claude Code command and custom-connector step makes concrete. It is distinguishable from the atlas_*/match_* siblings, though it never names an alternative connector-related tool.

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

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

It gives an explicit trigger: use it 'when the person wants something this one does not do,' which is a clear when-to-use condition. It also explains usage of each argument mode (no argument, `for`, `all: true`), but offers no when-not-to-use 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 cover the read-only, idempotent, non-destructive profile, so the description's real contribution is the auth-dependent data source and the fact that the signed-in variant requires a completed audit and includes answer engines the free reading does not. That is meaningful behavior beyond the structured fields. It doesn't state rate limits or what happens when no finished audit exists, which keeps it from 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 ordering guarantee is front-loaded in the first clause, which is the right priority. The remainder is a single long run-on sentence with stacked clauses about auth tiers and snippet types; it is dense but every clause carries information, so it stays efficient rather than padded.

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 the description needn't define return values, yet it usefully previews the item shape and the paste-ready artifact types an agent can expect. Given three simple parameters and full annotation coverage, an agent has everything needed to call it correctly; only the empty-audit case and rate/latency expectations are left unaddressed.

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 url, limit, and offset are already documented, including the 'most important first' ordering and the nextOffset convention. The description's 'most important first' and per-page framing merely restates what the schema says, adding no syntax or edge-case meaning. Baseline 3 is the correct ceiling here.

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 the resource concretely — an ordered fix plan for a site's AI visibility — and enumerates what each item contains (what to change, why it matters, points recovered, pages, paste-ready snippet). That content profile separates it from analyze_site, get_analysis, and visibility_history without naming them. It stops short of an explicit contrast with a sibling, so it isn't a clean 5.

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 context is implied through the auth tiers: anonymous callers get the free version derived from the identity reading, signed-in callers get the version built from their latest finished audit. That tells the agent what it will get in each case but gives no explicit when-to-use/when-not guidance relative to get_analysis or analyze_site, which is the more useful routing signal for a fix-plan tool.

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 and closed-world, and the description adds genuinely new behavior: the call is free, consumes no check, invokes no model, and simply replays previously measured data. It also discloses that signed-in callers additionally receive their own audits and their scores, which is a scope difference not visible in any structured field. Missing only operational detail such as history depth, pagination, or empty-result 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?

One dense sentence with a parenthetical enumeration; the core scope statement is front-loaded and every clause carries information (data content, personal-audit overlay, cost model). The nested list inside the sentence makes it slightly harder to scan than a structured breakdown would be.

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 fields need not be spelled out, yet the description still sketches them, and it covers the cost/side-effect profile an agent needs before calling. The main remaining gap is what happens when the URL is not in the Atlas or has no recorded weeks — with a single required parameter that is the one failure mode an agent would want stated.

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% for the single url parameter, so baseline is 3. The description adds a real constraint the schema does not state — the site must be 'in the INITE Atlas' for published readings to exist — but it never says what is returned for a non-Atlas site, so the added meaning is useful but incomplete.

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 the specific resource (historical AI visibility readings for a site in the INITE Atlas) and enumerates what each reading contains (identity score, crawlers allowed, llms.txt, Organization schema, top fix). The verb is implicit ('has moved over time') rather than a clean 'returns the history of', and it doesn't explicitly contrast with siblings like get_analysis or compare_sites, which keeps it below a 5.

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: 'Free, no model, and no check is spent: it reads what was already measured' signals this is the cheap read-only path rather than a new analyze_site run, and 'signed in, your own audits of it too' hints at the personal-data variant. There is no explicit when-to-use vs. when-to-use-a-sibling statement, and no exclusion such as what to do for a site not in the Atlas.

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