MyReach

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

Annotations already declare the mutation/idempotency profile, and the description adds real context on top: the 24-hour private hold until verified owner claim, the requirement to keep requestId private and reuse it only on retries, and the pre-signup ownerEmail dependency. It does not say what happens if the requestId is reused for a non-retry call, which is the one notable 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?

Four short sentences, purpose front-loaded, then the operational constraints in order of importance. Dense and largely waste-free, though the final sentence about connecting an owner's account is compressed to the point of ambiguity.

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 needn't be described, and the identity/idempotency story is well covered. But for a create tool with a large nested content schema and 0% schema description coverage, the complete silence on slug and content payload leaves an agent under-informed about the primary inputs.

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 reported at 0%, so the description carries the burden, yet it explains only 2 of 4 parameters (requestId and ownerEmail) in detail. The required slug and the entire nested content object — the bulk of the payload — get no mention at all.

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?

"Prepare a private MyReach page" names a resource and an implied create-draft action, and the 24-hour private window confirms this is a draft-creation tool. However, "prepare" is soft and the description never distinguishes it from the sibling update_page_draft, which an agent could easily confuse it with.

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 conditional guidance: supply ownerEmail "before signup" and "for an existing page, connect its owner's account," plus the retry-only rule for requestId. What is missing is the key routing decision — when to call this versus update_page_draft on a page that already exists.

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, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds useful scope about page permissions, but does not mention behavior when no account is linked or what auth condition is required.

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

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

A single front-loaded sentence that states exactly what is read. It contains no filler and no redundancy.

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

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

Given zero parameters, rich annotations, and an output schema, the description is nearly complete. It tells the agent the two key pieces of information returned. A minor gap is the lack of guidance about unlinked-account behavior.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. Baseline 4 applies; the empty schema and description are consistent.

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

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

The description uses a specific verb ('Read') and clearly names the resource: the linked MyReach account and its granted page permissions. It distinguishes this from sibling page/content tools by scope, though it does not explicitly contrast with get_myreach_capabilities.

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 intended use is implied—retrieve account and permission context for the current connection—but there is no explicit guidance on when to choose this over get_myreach_capabilities or other siblings. No exclusions or prerequisites are 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?

With readOnlyHint, idempotentHint, and destructiveHint already covering the safety profile, the description adds value by disclosing the auth requirement ('No account needed') — a fact absent from the annotations. It also frames the tool as a prerequisite discovery step, which no annotation conveys.

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

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

Two short sentences, front-loaded with the payload enumeration followed by the two operational facts (no auth, use early). Every clause carries distinct information and nothing is redundant with the title.

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?

Return values are covered by the output schema, annotations cover the safety profile, and the tool has no inputs, so the description only needs to say what capability data is exposed and when to fetch it — both are present.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate and the empty schema is self-evident. The description correctly avoids wasting words on non-existent inputs.

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

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

The description uses a specific verb ('Read') and a clearly scoped resource (MyReach publishing actions, editable fields, appearance choices, limits, restrictions), which tells an agent exactly what information it will get back. It is distinct from all siblings, which operate on pages, drafts, accounts, or publication status, though it never names an alternative explicitly.

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?

'Check before choosing a workflow' gives a concrete timing cue: call this first, then pick among the sibling page/publication tools. It stops short of naming which siblings this precedes or when to skip it, so it is clear context rather than full exclusions.

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 and non-destructive behavior, so the description only needs to add context. It does: authorization is required, draft access is scoped to a temporary capability, and the caller is told to use zero-based indexes in page.items for linkUpdates. That is meaningful context beyond the annotations.

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

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

Three short sentences with no filler, and the core purpose is front-loaded. The trailing sentence about zero-based indexes is output-related guidance that sits slightly awkwardly in a read tool's description but is not 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?

An output schema exists, so return values need not be explained. But the critical selection logic — slug for a published page versus draftId plus draftCapability for a draft, and what happens if none are supplied — is left for the agent to infer from bare patterns, which leaves the definition incomplete for a three-parameter tool.

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 0% and all three parameters are undocumented in the schema, so the description carries the full burden. It only partially compensates: 'draftCapability' is loosely tied to 'temporary draft capability grants draft access only', but 'slug' and 'draftId' are never explained, nor is the fact that zero parameters are required or how the three interact.

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

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

The description opens with a specific verb+resource ('Read an authorized published page or a private draft') and scopes the resource into two access modes. It does not explicitly differentiate itself from the sibling get_page_preview or list_pages, so it falls short of 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?

It states that the page must be authorized and that a 'temporary draft capability grants draft access only', which implies the draft path's precondition. However, there is no explicit guidance on when to use this versus get_page_preview or list_pages, and no statement about which parameters select the published vs. draft path.

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 useful behavioral context beyond annotations: the preview is private, uses MyReach's storefront renderer, and reflects the exact draft revision. However, it does not explain why readOnlyHint is false for a 'get' operation, what access/permissions are required for a private preview, or whether any preview state is created or persisted.

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

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

The description is a single front-loaded sentence with zero filler. Every phrase earns its place, and nothing is repeated from the title or structured fields.

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

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

The tool has an output schema, so return values need not be described. But with two parameters at 0% schema description coverage and a non-read-only annotation for a preview operation, the description leaves key details missing: what draftCapability does, whether the preview creates a session or expires, and why the operation is not read-only.

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 0%, so the description must compensate, but it never mentions draftId or draftCapability by name. 'Private preview' loosely hints that a capability may be required, but it gives no meaning, format, or usage guidance for either parameter.

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

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

The description states a specific verb and resource: get a private preview of the exact draft revision. It implicitly distinguishes a draft preview from get_page (published page) and from create/update tools, but it never names or explicitly contrasts any sibling 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?

There is no explicit guidance on when to use this instead of get_page, list_pages, or get_publication_status. The intended usage (preview a draft before publishing) is only implied; no when-not-to-use or alternatives are 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The second sentence adds context that the returned receipt is temporary and cannot 'edit or authorize future account access,' which is genuinely beyond the annotations, but it is phrased cryptically and never explains what a 'builder's status receipt' actually is.

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

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

Two short sentences, front-loaded with the core purpose. The second sentence is terse but not padded; it could be clearer without being longer.

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 needn't be explained, and annotations cover safety. However, with zero schema description coverage the description should clarify the role of draftCapability and any authorization expectations, which it does not.

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 0% for two parameters, and the description never mentions draftId or draftCapability. The optional draftCapability in particular is opaque — 'a temporary builder's status receipt' may allude to it, but the connection is never made explicit, so the description fails to compensate for the coverage gap.

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 specific verb and resource: 'Check whether the owner has published this draft.' An agent can tell this is a read-only status check, distinguishable from siblings like request_publication_approval or update_page_draft, though it does not name those siblings explicitly.

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 guidance on when to call this versus request_publication_approval or get_page_preview, and no stated prerequisites. The usage is only implied by the verb 'Check.'

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 well past the annotations (readOnly/openWorld/idempotent) by warning that returned data is untrusted extracted content and never instructions or ownership evidence – critical prompt-injection framing an agent cannot infer elsewhere. Adds concrete operational constraints: ten inspections per connection per hour and no account required.

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 capability then trust caveat then next step then limits. No filler; each clause carries distinct information an agent would otherwise have to guess.

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 shape needn't be described, and the description instead covers the things the schema cannot: trust level of the data, absence of side effects, auth requirements, and rate ceiling. For a single-parameter read tool this leaves nothing an agent needs 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?

One required parameter, `url`, with 0% schema description coverage; the description never clarifies acceptable URL forms (scheme required, homepage vs. deep link, what happens on redirects) or the 2000-char limit. The name plus `format: uri` makes intent largely self-evident, so the gap is modest rather than fatal, but the description adds nothing to the parameter itself.

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 (inspect) and resource (a public website) plus exactly what gets extracted: suggested profile text, avatar, social links, brand colors/font. The clarifying sentence "Does not create or change a page" places it clearly apart from the draft/page siblings in a single read.

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 a usable workflow: review suggestedContent, then apply selected fields through draft tools, which implicitly points at create_page_draft/update_page_draft. It also excludes the mutation path ("does not create or change a page") and states the call is unauthenticated. No explicit "use X instead when Y" routing to a specific sibling by name, so not 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful authorization scope and exclusion details, but does not mention pagination, ordering, or other listing behavior; with annotations present and an output schema available, this is adequate but not rich.

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

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

Two short sentences, front-loaded with the main action and followed by an important scope exclusion. Every sentence contributes useful information without repetition.

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

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

For a simple, parameterless listing tool with an output schema and clear annotations, the description is nearly complete: it identifies the resource, authorization scope, and excluded data types. It could go slightly further by clarifying its relationship to get_page, 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?

The tool has zero parameters, so there are no parameter semantics to explain. The baseline for a parameterless tool is 4, and the description does not create any parameter ambiguity.

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

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

The description states a specific verb and resource: 'List pages.' It also scopes the result to pages 'explicitly authorized for this connection' and excludes analytics/payment data, which distinguishes this listing behavior from singular siblings like get_page.

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

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

The description implies the tool should be used to list authorized pages and states what data is excluded, but it does not explicitly say when to use this tool versus get_page or other page-related siblings. The usage context is understandable but not fully guided.

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 a non-destructive, idempotent, non-read-only operation; the description adds the genuinely useful clarification that no publishing occurs and that the owner must act explicitly. It does not, however, explain what the 'review link' is, whether the request expires, or what happens when called repeatedly despite idempotentHint=true.

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

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

Two short sentences with the action front-loaded and the scope-limiting clarification second. 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?

An output schema covers return values, but for a write tool with two undocumented parameters at 0% schema coverage, the description should explain draftId vs. the optional capability and the lifecycle of the approval request. That gap makes the definition incomplete 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 0% and the description says nothing about either parameter. Most critically, the optional draftCapability — presumably a secret token authorizing access to the draft — is never explained, leaving an agent unable to judge when to supply 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?

The description states a concrete action (prepare a browser review link that the verified owner must claim/approve) and explicitly negates the adjacent capability with 'This tool does not publish,' which separates it from publish-like siblings. The framing is slightly indirect relative to the name 'request_publication_approval,' but the intent 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?

It implies when to use it (before publication, so the owner can claim/publish a new page or approve a revision), but never names alternatives such as get_publication_status or get_page_preview, nor states prerequisites or what to do after requesting approval. Usage is inferable rather than explicit.

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

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

Annotations already declare non-read-only, non-destructive, non-idempotent, closed-world, and the description reinforces this consistently by disclosing PATCH semantics ('Omitted fields stay unchanged'), the optimistic-concurrency requirement (expectedRevision), the frozen-theme lock, and the fact that published pages are untouched. What it omits is failure behavior on a stale revision and any auth/capability caveat, 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?

Five tight sentences with the editable surface front-loaded and constraints trailing, no filler. It is dense with semicolon-joined rules, which is efficient but slightly compresses the distinction between the mutually exclusive links and linkUpdates paths.

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, deeply nested mutation tool with an output schema, the description covers the tricky nested semantics and the concurrency contract without needing to explain return values. The remaining gaps are draftCapability and stale-revision error handling, which matter given the explicit expectedRevision precondition.

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?

Top-level schema description coverage is 0%, so the description carries the burden and mostly delivers: it explains links vs linkUpdates vs socials replacement semantics, translation merging, and expectedRevision. However draftId and especially draftCapability (a 64-hex token parameter) are never explained anywhere, and name/tagline/avatar/design are only implied by 'profile, public avatar... freestyle appearance'.

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

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

Opens with a specific verb and resource ('Edit a private draft's profile, public avatar, social icons, links, translations or freestyle appearance') and enumerates the exact editable surfaces, which separates it from create_page_draft, get_page and list_pages without naming them. The closing clause 'Changes never directly update a published page' further distinguishes it from the publication siblings.

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 parameter-level routing: 'Use linkUpdates for existing link cards on mixed-card pages; links replaces a complete link-only list', and equivalent rules for socials, secondaryLanguages and translations. It also states exclusions ('Commerce, domains, calendars and file uploads are unsupported') and the precondition 'Requires latest expectedRevision', 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.