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

Annotations already cover readOnly, idempotent, and openWorld, so the safety profile is known. The description adds real value beyond that: it enumerates the returned payload fields and, importantly, warns that returned text is third-party authored and untrusted, which is operational guidance an annotation cannot convey. It stops short of noting pagination, rate limits, or auth requirements.

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 statement is front-loaded and the security caveat follows immediately, with no restated or redundant phrasing.

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

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

With no output schema, the description must carry return-value disclosure, and it does so by listing the returned fields and permissions. Combined with the untrusted-content warning, an agent has everything needed to call and correctly interpret this 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?

Only one parameter with 100% schema description coverage, so the schema already documents the uuids array including its source. The description's 'by uuid' and 'one or more' add only marginal confirmation of array semantics, matching the baseline 3 for schema-carried parameters.

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 ('Get full detail for one or more classes by uuid') and enumerates the exact fields returned (name, join code/url, member and message counts, owner count, flags, edit permissions). This is clearly distinguishable from siblings like remind_list_entities and remind_get_messages.

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 'by uuid' and the schema note that uuids come from remind_list_entities, but the description itself never states when to use this versus remind_list_entities or other lookups, nor any prerequisites. A competent agent can infer the flow, but nothing is 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 cover the safety profile (readOnly, idempotent, openWorld), yet the description adds real value beyond them: the typed item model (MessageItem/SystemMessageItem/GapItem with `size`), the newest-last ordering, and an explicit prompt-injection warning that returned text is third-party and untrusted. That trust warning is exactly the kind of context annotations cannot express.

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 dense sentences, zero filler, with the read-scope stated first before the item typing and safety caveat. Every sentence carries distinct information.

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

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

With no output schema, the description steps in to describe the return shape (typed items, paging gaps) plus ordering and the untrusted-content caveat. An agent has everything needed to interpret and safely use the response.

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

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

Schema description coverage is 100%, so both parameters are self-documenting; baseline is 3. The description's explanation of GapItem tangentially clarifies what 'max non-gap messages per stream' means for `limit`, but no direct parameter syntax or format detail is added.

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 messages in one or more chat streams'), and adds the ordering scope ('newest-last'). This clearly separates it from remind_list_chats (which enumerates streams) and remind_send_message (which writes).

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 resource name, and the schema notes uuids come 'from remind_list_chats', but the description itself gives no explicit when-to-use or when-not guidance relative to siblings. Adequate but not directive.

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 openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: the interpretation of the `canManage*` flags and the constraint that a subscriber account cannot change most preferences, which is material to how an agent acts on the result.

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 what is retrieved and followed by the permission caveat. Dense but every clause carries information — the only slight drag is the long enumeration in the first 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?

There is no output schema, so the description must carry return-value meaning itself, and it does: it names each preference group, the transport types of registered devices, their enabled state, and how to read the canManage flags. An agent has everything needed to call it and interpret the response.

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 no parameters, so the baseline is 4 per the rubric. The description instead documents the shape of the returned data (preferences, devices, enabled state, canManage flags), which is useful even though it strictly concerns output rather than 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?

States a specific verb and resource ('Get notification settings') and then enumerates exactly what is returned: reply/announcement-copy/incoming-call preferences plus registered email/sms/apns devices with enabled state. That is far more specific than a restatement of the name, but it never names or contrasts with the natural sibling (remind_set_notification_devices), so it stops short of sibling differentiation.

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: the note that `canManage*` flags show which preferences the account may change hints that mutation belongs elsewhere, but the description never says when to call this versus remind_set_notification_devices or any other sibling. No explicit preconditions or exclusions are given.

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 annotations covering readOnlyHint and openWorldHint, the description still adds substantial value beyond them: mutation rejection policy, introspection availability, the specific 500-backed GRAPHQL_VALIDATION_FAILED error shape for unknown fields, and a prompt-injection warning that returned text is third-party and untrusted. These are exactly the operational traits annotations cannot carry.

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, then layers example queries, the mutation restriction with the redirect to write tools, the error-format gotcha, and the security caveat. Every sentence carries distinct, non-redundant information; length is justified by the tool's abstraction level.

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 raw-query escape hatch with no output schema, the description covers invocation semantics, permitted operations, error behavior, and safety handling of returned data. Nothing an agent needs to call 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%, so query and variables are already documented, giving a baseline of 3. The description goes further by supplying concrete introspection query examples (`{ __schema { ... } }`, `{ __type(name:"Class") { fields { name } } }`) that illustrate valid query syntax, slightly exceeding what the schema provides.

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 (Run), resource (arbitrary READ-ONLY GraphQL query), and target (Remind's API), and explicitly contrasts with 'the typed tools' in the sibling set. An agent can immediately distinguish this from remind_list_entities, remind_get_classes, etc.

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 tells when to reach for this tool (discovering fields the typed tools do not expose, via introspection examples) and when not to (mutations are rejected — use the write tools instead, which preview and confirm). Nothing is left to inference.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), yet the description goes well beyond them: it enumerates the full error.kind taxonomy (no_credential, credential_rejected, edge_blocked, http, timeout, transport) and explicitly states it never returns the cookie or CSRF token. This is exactly the kind of failure-mode context annotations cannot express.

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 sentences, front-loaded with the purpose, followed by the failure taxonomy and then the safety note. The long error enumeration is dense but every item carries diagnostic value, so nothing 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?

With no output schema, the description carries the return-value burden and largely does so by explaining the error.kind outcomes and the credential/token exclusion. It stops short of describing the success shape (e.g., a status or latency field), leaving a small gap for a zero-param diagnostic 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify and it does not need to compensate for any schema 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?

States a specific verb and resource ('Verify the Remind session end-to-end by running the smallest authenticated query') and is unmistakably distinct from siblings like remind_graphql or remind_send_message. An agent can tell this is a diagnostic probe, not a data-fetching call.

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 clear context for when to reach for it (checking whether a captured session still authenticates) and adds actionable interpretation guidance, notably that edge_blocked means re-signing in will not help. It does not explicitly name a sibling as an alternative or state exclusions, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds real value on top: it enumerates returned fields (notably canSend) and, importantly, warns that returned text is third-party and untrusted and must be treated as data, not instructions — a behavioral/safety trait no annotation conveys. It stops short of covering pagination, ordering, or rate limits.

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 tight sentences: what is listed first, how to filter second, the untrusted-content caveat last where it is most salient. No filler, no repetition of the 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?

With no output schema, the description usefully names the returned fields and flags the untrusted-content risk, which is what an agent most needs for a chat-listing read. Minor gaps remain around result volume/pagination and ordering, 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?

Schema coverage is 100%, so the three parameters are already fully documented in the schema, and the description merely mirrors them (uuids, class, search string). Baseline 3 applies since the description adds no format, default, or interaction detail beyond what the schema provides.

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 ('List conversation streams') and immediately enumerates the payload (unread counts, member counts, last-updated, per-stream permissions). The resource type is distinct from siblings like remind_get_messages or remind_list_entities, so an agent can route without opening a schema.

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

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

The description tells the agent how to narrow results ('Filter to specific uuids, a class, or a search string') but never states when this tool is preferable to a sibling such as remind_get_messages or remind_graphql. Usage is implied by the listing/filtering semantics rather than spelled out.

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 (readOnlyHint, idempotentHint, openWorldHint), and the description adds genuinely new behavior: unread counts are included, paging is cursor-based, and the returned text is third-party-authored and must be treated as data rather than instructions. That untrusted-content warning is exactly the kind of context annotations cannot express.

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 sentences, zero waste: identity and scope first, entry-point role and paging second, security caveat last. Each sentence carries distinct, necessary information.

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

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

With no output schema, the description carries the return-value burden and does so — listing entity types, unread counts, uuids, and the cursor. Combined with the annotation-covered safety profile, nothing needed to call this tool 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%, so both parameters are already documented in the schema. The description restates that the query is an optional filter and the cursor comes from a previous call, adding no syntax or format detail beyond the schema, which is the expected baseline.

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

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

States a specific verb and resource ('List everything in the Remind sidebar — classes and chats') and scopes it precisely against the sibling tools remind_get_classes and remind_list_chats by covering both entity types in one call. It also declares what it returns (uuids, unread counts) so an agent can tell it apart 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?

Explicitly frames itself as 'the entry point: it yields the uuids the other tools take', which routes the agent to call this before the uuid-consuming siblings, and notes the optional query filter and cursor paging. It stops short of naming specific alternatives or stating when not to use it (e.g. when a uuid is already known), so it is clear context without 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 open-world behavior, so the safety profile is covered. The description adds value beyond that by spelling out the returned account fields (uuid, name, email, locale, admin/child flags, sign-in count), which matters because no output schema exists. It does not mention auth failure behavior or rate limits, keeping it short of 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?

One front-loaded sentence with zero filler; the resource comes first and the field list follows as compact, comma-separated detail. 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 zero-parameter read tool with no output schema, the enumerated return fields plus the annotations give an agent nearly everything needed to call and interpret it. Only the auth/session precondition and error case (e.g., no signed-in user) are unstated.

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 of 4 applies and there is nothing for the description to disambiguate. No parameter semantics are needed or missing.

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 ('Get the signed-in Remind account') and enumerates the exact fields returned, which is precise and unambiguous. It does not explicitly position itself against siblings like remind_get_notification_settings or remind_get_classes, though the subject matter is naturally distinct enough that confusion is unlikely.

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?

Used when the agent needs the current user's identity, but this is only implied by 'signed-in account' – there is no explicit statement of when to call it, no prerequisites (e.g., an authenticated session is required), and no named alternatives. Adequate but leaves routing to inference.

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

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds substantial context beyond them: delivery reaches real people, the action CANNOT be unsent, nothing is sent until confirmed, and the exact confirmation protocol (preview + confirmToken round-trip) is described.

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

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

Front-loaded with the core action and its irreversibility, then the confirmation mechanics. Dense but every sentence carries operational weight; only the parenthetical MCP_CONFIRM_MODE reference is slightly extraneous.

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 destructive, no-output-schema tool, the description covers the safety-critical pieces: irreversibility, the two-phase confirmation contract, the fallback token flow, and the pre-flight permission check. An agent has enough to call it correctly and safely.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by framing confirmToken as part of a named two-step protocol and tying recipient_uuid to a prior permission check, adding workflow meaning to the parameters.

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+resource ('Send a message to a chat stream or class') and distinguishes the two recipient types. It is clearly separable from siblings like remind_list_chats and remind_get_messages, which read rather than send.

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 tells the agent to check `permissions.canSend` via remind_list_chats first, and names the alternative confirmation paths (client elicitation vs. two-step token fallback). The when-to-use conditions are fully spelled out.

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 only say readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds substantial non-obvious behavior: a preview shows the exact mutation input, the first call is a no-op without confirmation, the confirmToken must never be invented or reused, and it is ignored when elicitation is supported.

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 then the confirmation model in three dense sentences with no filler. Slightly packed with parenthetical detail, but every sentence carries operational information.

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

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

For a mutation tool with no output schema, the description covers the safety model, the id source, the two-phase confirmation protocol, and token reuse rules. An agent has everything needed to invoke it correctly.

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 enable/disable and the confirmToken lifecycle are already documented in the schema. The description reiterates the confirmToken fallback but adds no format or syntax 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 (enable/disable) and resource (notification delivery devices), and identifies the sibling tool (remind_get_notification_settings) as the source of valid ids. An agent can distinguish it from remind_send_message or remind_get_notification_settings 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?

Gives explicit routing conditions: use ids from remind_get_notification_settings, and choose between the elicitation confirmation path and the two-call confirmToken fallback (MCP_CONFIRM_MODE). It also states the precondition that nothing is sent until the user confirms.

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