X1 Wealth

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds real behavioral value beyond that: it cites source and page, states it will plainly report missing evidence, and explains the data-source split between the X1 record and own X1 documents on outside assistants.

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 core action, followed by citation/evidence behavior and then the exclusion boundary. Slight redundancy between the opening data-source listing and the closing 'own household' restatement, but nothing 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?

An output schema exists, so return-value explanation is unnecessary, and the annotations cover safety. The description covers scope, sourcing discipline, and evidence-gap handling well; only the absence of explicit sibling routing 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% with only two parameters, both fully documented including the enum-constrained 'record'. The description adds topical framing of what the question should concern but no syntax or format guidance beyond the schema's maxLength constraint, so baseline 3 applies.

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

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

States a specific verb (answers questions) plus the exact resource domains: trusts, entities, properties, insurance policies, decisions, and document contents from the X1 household record. It also scopes the boundary to the connected person's own household, which separates it from the many get_* household aggregate 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?

Provides explicit when-not guidance: 'not a whole-household financial-picture, balance, spending, or net-worth reader,' which implicitly routes those needs to get_household_financial_snapshot and similar tools. It does not name the alternative tool explicitly, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds two things not in structured data: it never returns an upload link or token, and it can report an intermediate 'still reading' state that the agent should surface and then re-check. Error cases (expired token, unknown requestId, how long to wait) 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?

Front-loaded with the purpose, then the parameter rules, then the response handling, then the self-only constraint — a sensible order with no filler. Some sentences are dense and pack two ideas (e.g., the still-reading instruction), but every sentence carries operational weight.

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 compensates by naming the two observable outcomes (arrived vs. still reading) and one guaranteed non-return (no link/token), plus the self-only scope. It falls short of covering failure modes and expected polling latency, which an agent may need in practice.

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 the selection logic the schema only implies: requestId is the normal path when the upload tools are mounted, token is the fallback for a direct dropUrl call. Both parameters are optional, and the description clarifies when each is appropriate.

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

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

States a specific verb (check), resource (a file deposit), and scope (THEIR OWN X1 documents), which separates it from listing tools like get_vault_documents or search_my_documents. It also names the upstream tools whose requestId it consumes, so an agent knows exactly where this sits in the approval-to-deposit flow.

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 conditional invocation rules: pass requestId when request_vault_upload_link or create_my_vault_upload are mounted (the usual path), pass token only when a direct call returned a dropUrl. It also prescribes the follow-up behavior in each outcome, which resolves the ambiguity about whether to answer the user or keep waiting.

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

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

Annotations already establish the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower, yet the description still adds real value: it discloses that the operation is a draft that does not open a browser, that guardrails are read/download-only, and that an X1-side confirmation review is required. That is meaningful behavioral 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?

Two tight sentences, front-loaded with the verb and resource, with no filler. The second sentence is dense but its enumeration of return contents is purposeful, so it stays structurely efficient overall.

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 description compensates for the absent output schema by enumerating what gets returned (goal, domains, guardrails, review contract), and annotations cover safety. However, with 6 undocumented parameters at 0% coverage, the definition leaves a notable gap an agent must fill blindly.

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?

With 6 parameters at 0% schema description coverage, the description carries the full burden but only gestures at two of them (goal, allowed domains) as return fields rather than input semantics. The other four (clientId, clientRef, institutionLabel, targetArtifactLabel) get no guidance, format, or constraint hints.

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 ("Draft an Ask X1 BrowserMission proposal") and immediately scopes the operation with "without launching a browser session," which cleanly separates it from execution/launch and from siblings like get_browser_mission_status and summarize_browser_mission_result.

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 "without launching a browser session" clause and "for X1-side confirmation" hint at when this pre-step applies, but there is no explicit statement of when to choose this over its siblings (e.g. status or summarize tools) or any stated prerequisites. Usage is implied rather than directed.

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

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

Annotations already declare readOnlyHint/idempotent/non-destructive, and the description reinforces with 'writes nothing' without contradiction. It adds real behavioral context beyond annotations: the optional insight is treated as unverified external evidence bound to the exact live thread revision before review, and missing outcomes prompt a request instead of a guess.

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 front-loaded sentences: purpose, evidence-handling, and write/no-write routing. Efficient overall, though the middle sentence is dense with jargon ('source-minimized', 'live X1 thread revision') that slightly slows comprehension.

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 5-parameter tool with a nested object and no output schema, the description covers purpose, the write-free guarantee, the actual closing mechanism, and the missing-outcome edge case. Return-value detail is not required without an output schema, so coverage is nearly 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 the baseline is 3, but the description adds behavioral meaning for parameters: it explains the optional sourceProposal's unverified/hash-bound nature and that an omitted closeoutOutcome causes the tool to ask rather than infer. This meaningfully supplements the structured fields.

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 ('Draft a proposed coordination-thread closeout summary with citations...'), and distinguishes itself from the draft_coordination_reply/draft_coordination_thread siblings by being specifically a closeout. It also names the sibling that actually performs the closing (close_coordination_thread).

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?

Clearly routes the agent: 'This tool writes nothing; closing happens through close_coordination_thread when it is mounted, or in X1,' and says to ask for a missing outcome rather than guess. It gives strong context but never directly contrasts with the other draft_* siblings, so an explicit when-not comparison is absent.

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 and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior beyond that: it explains that the call loads the thread and returns its latest messages as citations, that replyGoal becomes the draft body, and that nothing is written. It stops short of describing the commit/confirmation flow in any detail despite advertising 'human-confirmation commit instructions'.

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 purpose followed by the read-first caveat and the write boundary; there is little waste. It is slightly dense, packing return behavior, parameter mapping and the send alternative into the second sentence, but nothing is filler.

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

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

With no output schema, the description carries the burden of explaining returns, and it does state that the tool returns the thread's latest messages as citations plus a draft packet. Combined with the 100% schema coverage and read-only annotations, an agent has enough to invoke it correctly; only the promised 'commit instructions' are never actually described.

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 baseline is 3. The description earns an extra point by tying semantics to behavior that the schema does not: replyGoal 'becomes the draft body' and threadId is the thread whose 'latest messages' are returned as citations, which is more than the schema's terse 'Plain-language intent' and 'Coordination thread ID'.

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 ('Draft a proposed coordination-thread reply') and immediately scopes the deliverable ('with citations and human-confirmation commit instructions'). It also distinguishes itself from the send-side sibling by naming reply_to_coordination_thread, so an agent can tell drafting from sending 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?

It gives a clear usage condition ('read the thread first when the reply has to answer its content') and an explicit boundary against a named alternative ('This tool writes nothing; sending happens through reply_to_coordination_thread when it is mounted, or in X1'). What it does not do is disambiguate itself from the other drafting siblings such as draft_coordination_thread or draft_coordination_closeout, which remains an inference for the agent.

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, so the bar is low, yet the description adds real context: the tool returns availableRecipients, unknown recipientIds are refused, and use is gated by mounting and actor safety ('when it is mounted and the current actor can safely use it'). The mounting/permission phrasing is a bit vague, keeping 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?

Purpose is front-loaded, but the second sentence runs long with an awkward clause ('when it is mounted and the current actor can safely use it') that is vague and hard to act on. Two dense sentences with some redundancy ('This tool writes nothing' repeated in the message 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?

No output schema exists, yet the description explains the key return value (availableRecipients) and the refusal behavior, and annotations cover the safety profile. The workflow role relative to start_coordination_thread is conveyed, though the 'mounted' prerequisite remains underspecified.

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 baseline is 3, but the description adds meaning beyond the schema: recipientIds must be drawn from the returned availableRecipients and unknown IDs are refused, and it clarifies clientId omission for one's own household. This enriches the recipient/client semantics materially.

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 ('Prepare a new coordination-thread draft') and enumerates what the draft carries (member, recipients, subject, message). It is distinguishable from sibling drafts like draft_coordination_reply and draft_coordination_closeout, though it never explicitly contrasts itself with 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?

Gives clear sequencing guidance: call it before looking up a professional elsewhere, and note that it produces commit instructions for start_coordination_thread. It does not spell out when NOT to use it versus the other draft_* siblings, but the workflow placement 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 declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is already covered. The description adds genuine value beyond that: 'nothing is saved or sent' and it 'Returns a proposal and the X1 review destination,' clarifying the dry-run nature and the follow-on step.

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 tightly scoped sentences that front-load the action and the no-side-effect guarantee. No filler, though the category constraint sentence is somewhat redundant with the schema's category description.

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 and 100% schema description coverage, the description needn't detail return values, yet it still signals the proposal-and-review-destination output and the 'nothing saved/sent' behavior. Complete enough to call the tool correctly; only explicit sibling routing is absent.

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 every parameter including enums, deadlines, and clientId is already documented in the schema. The description only restates the category constraint and examples the schema also provides, so the baseline of 3 is appropriate for this schema-driven tool.

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: 'Prepare a draft request for a missing financial or household document,' with concrete examples (K-1, statement, trust, property record). This distinguishes it from the sibling list_document_requests, though it does not explicitly name an alternative. Purpose is clear 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?

It implies the usage context ('for a missing ... document') and adds the constraint that only supported categories on this connection can be requested. However, it never states when to use this draft tool versus siblings like list_document_requests or other draft_* tools, leaving 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 declare readOnlyHint/idempotentHint/non-destructive, and the description reinforces this with substantive extra context: it is 'write-nothing', 'deterministic', 'never merges records', and explicitly 'has no MCP confirm tool', plus it delivers a consequence preview and X1 deep link. This prevents an agent from hunting for a confirm tool that doesn't exist.

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 waste. The core purpose is front-loaded and the second sentence is load-bearing because it corrects the dangerous implication of the word 'merge'.

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 explained. The description fully covers what is produced, that no write occurs, and where the follow-up confirmation lives — everything an agent needs 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 loserEntityId/survivorEntityId/clientId/clientRef are already documented in the schema. The description only implies the two-item pairing and adds no syntax, format, or sourcing detail beyond the schema. Baseline 3 applies when the schema carries the 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?

Names a specific verb (prepare a proposal) and resource (two member-owned household items that may be the same), and immediately distinguishes itself from any actual merge tool by stating it 'never merges records'. An agent can tell exactly what this produces without reading 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?

The use condition is stated ('two member-owned household items that may be the same'), and the description clarifies that confirmation happens first-party in X1 rather than via any MCP tool, which routes the agent correctly. It stops short of naming specific siblings (e.g. list_household_entities as the ID source or list_household_entity_change_proposals) or stating explicit when-not conditions.

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/destructiveHint=false, so the safety profile is covered; the description nonetheless adds concrete behavioral facts: it self-gathers meeting prep, validates recipients against an allowed team list (arbitrary users rejected), and creates no packet or relationship. The 'writes nothing, sends nothing' clause partly restates the annotations, which keeps this 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?

Three sentences, each doing distinct work: what it produces, how to route to it, and what it does not do. The core purpose is front-loaded and there is no filler or 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?

For a read-only drafting tool with no output schema, the description covers purpose, routing, side-effect scope, and the key validation constraint, which is enough to invoke it correctly. It stops short of describing the brief's structure or length beyond the 'omitted sections' hint, 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 description coverage is 100%, so every parameter (title, purpose, audience enum, clientId, meetingDate, recipientIds) is already documented in the schema. The description echoes the recipient-eligibility and self-household drafting rules but adds no new syntax, format, or interaction 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?

The description gives a specific verb (prepare/draft) plus the resource (a role-aware meeting, intro, or handoff brief) and adds a scope constraint ('from data the actor can already read'). It also implicitly separates itself from the sibling get_meeting_prep by stating 'It gathers meeting prep itself, so call it directly,' 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?

It explicitly tells the agent to call this tool directly and to consult other tools only for sections the brief marks as omitted, which is a clear when-to-use rule plus a named alternative behavior. It also flags the recipient-eligibility precondition (must come from the member's allowed team list), covering the main failure mode before invocation.

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 non-destructive behavior, so the safety profile is covered. The description adds the important scoping constraint that results stay within the caller's household or participant/watcher scope, which is useful non-annotation context, but says nothing about result ordering, pagination beyond the limit parameter, or completeness of results.

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 waste. The search action and its filter dimensions are front-loaded, followed by the scope constraint. Efficient and well-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?

For a 9-parameter search tool with no output schema, the description covers the main facets and the scope constraint but leaves gaps: no return shape information, no pagination behavior, and no explicit routing guidance among similar siblings. Adequate but with clear gaps.

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 56%, so roughly half the parameters are documented. The description adds the list of filterable dimensions (query, participant, status, intent, closeout outcome, activity date range) which maps to the parameters, but adds no syntax or format detail beyond what the schema already provides for the documented ones.

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 clear verb+resource ('Search coordination threads') and enumerates the filterable facets. It is distinguishable from sibling list_my_coordination_threads and get_coordination_thread, though it does not explicitly name those alternatives.

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 filter enumeration and the scope note, but there is no explicit statement of when to use this tool versus list_my_coordination_threads, get_coordination_thread, or summarize_coordination_thread. The agent must infer the selection criteria.

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, destructiveHint=false and openWorldHint=false, so the description adds value beyond them by disclosing two real behavioral traits: it never launches a browser or sends anything external, and it fails closed as 'infra_gated' when BrowserMission storage is unavailable. That failure-mode disclosure is genuinely useful for an agent interpreting a 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 tight sentences with zero filler, front-loading what is read before the behavioral guarantees. 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 single-parameter read tool with no output schema, the description covers purpose, side-effect profile, and the failure mode. It does not describe what the returned status values look like, but that is a minor gap given the tool's simplicity.

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 parameter with 0% schema description coverage, so the description must compensate. It only restates that missionId identifies the BrowserMission ('by missionId'), adding no format, source, or lookup guidance beyond the schema's type and required flag. Adequate but thin.

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 the X1-owned status of a BrowserMission by missionId'), which is distinguishable from siblings like summarize_browser_mission_result or draft_browser_evidence_mission. It doesn't explicitly name an alternative sibling, but the scope 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?

Usage is implied by the definition ('read the status of a mission by id') but there is no explicit when-to-use guidance or routing away from the similar summarize_browser_mission_result sibling. An agent can infer the case but must do so itself.

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, so the bar is lower, and the description adds real behavioral context: results are 'bounded', raw claims and evidence are opt-in, and access is permission-gated ('excluded unless a future explicit permission adds this surface'). It doesn't disclose pagination or default return shape, keeping it out of the top tier.

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 a single dense sentence with nested parentheticals and a mid-sentence colon example, front-loaded with the core verb but heavy to parse. No outright waste, yet the run-on construction hurts readability.

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 and 0% schema coverage across 6 parameters, the description should do more. It covers purpose, ownership semantics, and permission gating well, but omits any explanation of the parameters or the returned claim structure an agent needs to call 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 0%, so the description carries the param burden. It hints at includeRawClaims/includeEvidence ('optional raw claims and evidence'), scope ('member or household'), and limit ('bounded'), but leaves clientId, memberIds, and actual limit bounds entirely undocumented. Partial compensation only.

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 ('Return') and resource ('bounded business-entity graph claims for a member or household'), and elaborates on a distinctive output, effectiveOwnership look-through with a concrete example. This clearly separates it from generic context tools, though it never names a specific sibling like get_professional_graph_context or list_household_entities.

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 provides an implied usage goal ('so you can answer what they effectively own through their entities') and notes an exclusion ('Scoped specialists are excluded'), but gives no explicit when-to-use versus alternatives or prerequisites for choosing this over list_household_entities or get_family_office_context. Usage is inferable rather than directed.

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 carry readOnly, idempotent, non-destructive and closed-world hints, so safety basics are covered. The description nonetheless adds real value by bounding expectations: it 'does not prove all terms match', does not 'authorize a financial action' and does not 'replace household approval', plus it enumerates the categories of information returned (checked-field changes, source versions, affected recorded work, preserved history).

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 core comparison action, followed by the return contents and then the limitations. The middle sentence is a long enumerated list, but with no output schema it earns its space; nothing is redundant.

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 convey what comes back, and it does so by naming the five categories of read results (changes, versions, affected work, history, next step). It also closes the expectation gaps around proof of term matching and financial authorization. A reader still lacks clarity on how this differs from the sibling capital-call state tools.

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

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

Schema coverage is 100% and both parameter descriptions are already detailed (including the note that the current ID may equal the recorded ID on reprocessing). The description only reinforces that both documents must be identified explicitly and reiterates that no write authority is granted, adding little beyond the schema. Baseline 3 is appropriate.

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

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

Names a specific verb (compare) and a specific resource (two explicitly identified capital-call documents) against the recorded job, which an agent can distinguish from generic document search siblings. It does not, however, explicitly differentiate itself from the closely named siblings get_capital_call_job_state and get_capital_call_source_state, which a reader would naturally conflate.

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 phrase 'two explicitly identified' implies the caller must pick both documents deliberately, and the final sentence gestures at a 'next permitted review step', which hints at workflow context. But there is no explicit statement of when to reach for this over get_capital_call_job_state or get_capital_call_source_state, and no stated prerequisites beyond identification.

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, so the description earns credit for adding the enumerated state space (review needed, confirmed obligation waiting, funded, no longer due, held) and the explicit caveat that this is never authority to move money or proof of settlement. That caveat is real behavioral context an agent could not derive from 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 tight sentences, front-loaded with what it reads and scoped by document. The state enumeration is a long clause but carries genuine information; the only mild redundancy is restating scope and safety in sentence three.

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

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

Output schema exists and annotations carry the safety profile, so the description need not explain return shapes. It covers purpose, scope and a critical non-authority caveat; only sibling differentiation is missing for a tool that sits beside two other capital-call readers.

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 coverage, including min/max length and 'Exact document ID returned by X1'. The description reinforces exactness ('one exact document') but adds no format or sourcing detail beyond the schema, so baseline 3 applies.

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

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

Specific verb (read) plus resource (capital-call job state) plus scope (one exact document in your own X1 Vault). It distinguishes itself from general list/search tools, but never names near-identical siblings like get_capital_call_source_state or get_capital_call_continuity, so an agent must infer the split.

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 — you check this when you have a single document and want to know where its capital-call job stands. There is no explicit when-not guidance and no mention of the two sibling capital-call tools, so choosing among them 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?

Beyond the annotations' read-only/idempotent/non-destructive profile, the description discloses that X1 returns complete proof-backed facts or a typed hold and enumerates the semantic operations it refuses to perform (confirmation, obligation, authorization, settlement). This is substantive behavioral context an agent needs to interpret results correctly.

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 verb and resource, with the second sentence carrying the boundary disclosures. Slightly jargon-heavy ('strict source-state projection'), but every clause contributes and 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 an output schema present and rich annotations, the description needn't explain return values, and it covers purpose and semantic boundaries well. The main remaining gap is explicit disambiguation from the two capital-call sibling tools.

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

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

Schema coverage is 100% and the single documentId parameter is fully documented in the schema as the ID returned by get_vault_documents. The description adds no parameter-specific detail, 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 (Read) and resource (one capital-call notice from your own X1 Vault) and characterizes the output as a source-state projection with proof-backed facts. It does not, however, explicitly differentiate itself from siblings like get_capital_call_continuity or get_capital_call_job_state, so the agent must infer the distinction.

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

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

Provides strong when-not boundaries: it never treats the document as household confirmation, creates an obligation, authorizes a write or coordination, moves money, or verifies settlement. These exclusions clearly scope usage, but it never names an alternative tool to use instead for those purposes, leaving 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 declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds the useful scope note that it is a 'broad timeline' and access-limited ('a client/member you can access'), but says nothing about pagination, ordering, or what an activity item contains.

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 core action, then utility, then routing. No filler, and each sentence earns its place, though the third reads slightly redundantly with the second.

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 should convey what comes back; 'recent activity timeline' gives a rough shape but no detail on item contents or ordering. For a simple read-only, two-parameter tool whose annotations cover safety, this is adequate but leaves gaps.

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 (limit, clientId) are already documented in the schema. The description adds no meaning beyond it — it never mentions the limit cap or the clientId format. Baseline 3 is appropriate 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 specific verb and resource ('Get a recent activity timeline') and clarifies scope ('for yourself or a client/member you can access'). It also positions itself against alternatives by contrasting the 'broad timeline' with shared documents and coordination threads, which helps distinguish it from the many get_* 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?

It states when it is useful ('understanding engagement and what changed recently') and gives an explicit when-not-to-use with an alternative ('Scoped specialists should use shared documents and coordination threads instead'). That routing guidance is stronger than most siblings, though it doesn't spell out prerequisites or exclusions beyond specialist roles.

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 behavior, so the description's added value is in scoping: connected accounts only in the totals (not full net worth), documentBacked figures are as-of statement date and never live, account/loan numbers shown as last four only, and scoped specialists are excluded. These are useful constraints beyond what annotations disclose.

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 opening sentence front-loads usage, which is good, but the body is a dense, run-on block mixing output scope, documentBacked details, and role rules. Several clauses are redundant with each other and with the schema, so it is longer than it needs to 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?

With an output schema present, return values need not be explained, and the description covers inclusion/exclusion scope, data freshness, and invocation rules adequately. It is essentially complete for an agent to call correctly, with only minor redundancy.

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 parameter with 100% schema description coverage, so the schema already documents clientId. The description largely restates the same member-omit/professional-pass rule, adding only minor nuance ('unless X1 already supplied a client-scoped context'). Baseline 3 is appropriate when the schema carries the 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 names a specific verb and resource (get connected-account liquidity broken out by entity: cash, investments, debt, net connected value, plus a household total) and explicitly distinguishes it from a whole-household financial picture. It is clear what the tool returns, though the signal is somewhat buried under dense surrounding text.

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 when to use it ('connected-account balances, not a whole-household financial picture') and points elsewhere for whole-household questions (authorized property, alternatives, private holdings, loan records). It also gives role-based invocation rules for clientId. The alternatives are described by category rather than named sibling tools, so it stops short of explicit tool routing.

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 non-destructive behavior, so the safety profile is covered. The description adds genuine behavioral context beyond that: the privacy rule that non-authored drafts remain private, and the access restriction excluding scoped specialists. It does not describe pagination or return ordering, so not 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?

Front-loaded with the core purpose, then constraints, in three sentences with little filler. The drafts sentence overlaps heavily with the schema's drafts description, which is the only notable 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?

For a five-parameter read tool with no output schema, the description covers purpose, access scope, privacy behavior, and hints at returned fields. It stops short of explaining result ordering or how question-based retrieval works, a minor gap given the rich schema.

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

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

Schema coverage is 100%, so all five parameters are already well documented. The description largely restates the drafts parameter rather than adding new semantics (e.g., how 'category' values are matched or how 'question' ranks results), so the baseline 3 is appropriate.

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

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

States a specific verb ('Recall') and resource ('recorded X1 decision memory') with scope ('your own record or an assigned client') and enumerates the fields returned (category, timestamps, status, owner labels, confidence, provenance). This is readily distinguishable from siblings like get_client_profile or get_client_activity without opening their schemas.

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 use: recall memory for one's own record or an assigned client, with an explicit exclusion ('Scoped specialists are excluded') and a conditional ('professionals must pass clientId unless X1 supplied context'). It does not name an alternative tool for overlapping reads, which keeps it 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 establish readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful access-scoping context (yourself or an accessible client/member; scoped specialists excluded), but says nothing about return shape, pagination, or freshness of the aggregated 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?

Two sentences with the action front-loaded and the access constraint following. The enumeration is dense but each item adds informational value rather than 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?

With no output schema, the description must convey what comes back, and it does by listing the product-state components. For a read-only aggregation tool with full annotation coverage, this is nearly sufficient; only the absence of any note on data currency or scope limits holds it back.

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% for the single optional clientId parameter, so the schema carries the semantics. The description reinforces that the target may be yourself or a client/member, but adds no format or behavior details 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 ('Get') and resource ('structured view') and enumerates the surfaces it aggregates (onboarding, Pulse, vault, plays, packet readiness, member-intelligence, CRM context). An agent can grasp what it returns, though it does not explicitly differentiate itself from siblings like get_client_profile or get_household_financial_snapshot.

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?

Specifies the eligible subject ('for yourself or a client/member you can access') and an access exclusion ('Scoped specialists do not receive this broad product-state surface'), which is useful routing context. However, it never says when to prefer this aggregated view over narrower siblings, so the when-to-use guidance is only implied.

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 readOnly/idempotent/non-destructive, and the description adds genuinely useful context beyond them: role-based access model, admin-only read-only break-glass escalation, and the currentFacts semantics (client-shared facts plus document-derived facts with document/page/section but never quoted text). This materially exceeds the annotation payload.

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 purpose well, but the remainder is dense with specialized jargon ('bounded shared member intelligence', 'currentFacts', 'X1 read from documents') that is not self-explanatory and reads as internal shorthand. Every sentence is relevant, yet the phrasing is more convoluted than it needs to 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?

For a read-only tool with full annotation coverage, a 100%-covered schema, and no output schema, the description supplies the access model and the semantics of the returned facts. It is largely complete; only the return-shape and how it differs from sibling client getters are left implicit.

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 clientId, clientEmail, and debugAccess are already documented in the schema. The description restates debugAccess semantics ('read-only break-glass when eligible') but adds no new syntax, format, or precedence detail, so baseline 3 applies.

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

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

States a specific verb and resource: 'Canonical MCP read for your profile or a profile view for a client/member you can access.' The scoping (own profile vs. an accessible client/member profile) is clear, but it never names or contrasts with the many sibling get_client_* tools (activity, liquidity, memory, tax_reserve), so an agent must infer the boundary.

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

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

Gives actor-specific context ('Advisors use active relationships, coaches follow managed-program defaults, and scoped admins can use debugAccess'), which implies usage but is not framed as when-to-use-this vs. an alternative. No explicit exclusions or sibling routing, so guidance is only implied.

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, so the safety profile is covered. The description adds genuinely useful context beyond that: data provenance ('as X1 read them from returns you can see', household confirms in X1), and important caveats that this is a planning estimate, not tax advice, federal income tax only. It does not, however, discuss any rate limits or freshness/latency 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?

The leading clause front-loads the core purpose before the field inventory, and the caveats are grouped at the end. The middle sentence enumerating every returned subfield is dense and slightly run-on, but with no output schema it is largely load-bearing rather than 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 appropriately documents the return shape (reserve fields plus filedReturns and informationReturns subfields) and carries the necessary scope and disclaimer context. The main omission is explicit guidance on when to prefer this over sibling client-state tools, and there is no mention of pagination or empty-result 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?

Schema description coverage is 100% and there is a single optional parameter, so the schema already fully documents clientId, including the member-omit/professional-must-pass rule. The description's reference to 'your own record or an assigned client' restates rather than extends that, so the baseline 3 is appropriate.

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

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

States a specific verb ('Get') and a precisely scoped resource ('federal estimated-tax reserve planning position'), then enumerates the concrete fields returned (target reserve rate, safe-harbor amount, next deadline, provenance). It also explicitly disentangles itself from the filedReturns/informationReturns payloads by noting those 'do not drive the reserve position', which helps an agent distinguish this from sibling client-state tools like get_client_liquidity.

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 establishes eligibility ('your own record or an assigned client') and notes that 'scoped specialists are excluded', which is real usage context. However, it never names an alternative tool or states a when-not condition, so routing versus siblings like get_client_profile or get_household_financial_snapshot 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?

Beyond the readOnly/idempotent annotations, it discloses the access-control model, the two projection modes and their precondition logic (resume needs the exact open obligationId; closed result derives the sole exact completed obligation and requires three converging conditions), operator exclusions, and an important caveat that neither projection proves settlement or money movement.

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 result fields before the projection detail. The projection sentences are dense and jargon-heavy, but for a tool with two special modes and an access model, each clause carries load and nothing is pure 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 itself enumerates the returned content and flags the projection caveats. For a 4-parameter read tool with an access model and two opt-in modes, an agent has everything needed to call 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 coverage is 100%, so the baseline is 3, but the description adds conditional semantics the schema only hints at: which projection requires obligationId, which accepts none, and that the projection path is external-connector only. That is real added meaning over the property descriptions.

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

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

States a specific verb+resource ('Get full detail of a single coordination thread') and enumerates the payload (subject, messages, attachments, participants, next owner, closeout state), which cleanly separates it from summarize_coordination_thread, list_my_coordination_threads, and find_coordination_threads.

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 scopes who may use it (household member or active participant/watcher) and who is excluded (managed-program operators, scoped specialists), plus the conditions under which each projection applies. It stops short of explicitly routing to summarize_coordination_thread for a lighter read, so it is clear context rather than full when/when-not guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: it is access-scoped to self or an accessible client/member, and explicitly notes that scoped specialists are excluded unless a future permission grants the surface. Return format is not described, 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?

Two dense sentences with no filler. The returned contents are front-loaded, followed by the access scope and the exclusion caveat.

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 the return surface, and it does list the artifacts returned. Combined with rich read-only annotations and a fully documented single parameter, an agent has enough to invoke it correctly; only finer output detail is absent.

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 clientId parameter is documented in-schema, so the baseline is 3. The description adds meaning by clarifying that the parameter optionally targets a client/member 'you can access' while omitting it yields your own context, which the schema does not state.

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 (Get) and resource (family office context) and enumerates the concrete contents it returns: constitution, crest, mission, mode-of-operation, meeting playbook. This clearly separates it from the adjacent graph/context siblings such as get_business_entity_graph_context and get_professional_graph_context.

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 scope ('for yourself or a client/member you can access') and an access caveat about scoped specialists, which implies when it is callable. However, it never names an alternative tool or states a when-not condition, so usage is only implied.

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

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world. The description adds real context beyond that: it is a "latest saved" precomputed snapshot rather than a live calculation, and it discloses an authorization boundary (scoped specialists are blocked). It does not describe freshness/staleness behavior or return format, keeping 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?

Three tight sentences: what it returns first, when to use it second, access constraint last. Front-loaded and every sentence earns its place with 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?

For a read-only, fully-annotated tool, the description covers purpose, trigger conditions, returned fields, and an access restriction. No output schema exists but the description enumerates the payload, and the single optional parameter is fully documented in the schema.

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

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

Schema description coverage is 100% with a single clientId parameter, so the schema carries the semantics. The description adds no parameter-level meaning (it never mentions clientId or scoping behavior), so baseline 3 is appropriate.

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

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

States a specific verb ("Read") and resource ("household's latest saved financial snapshot") and enumerates the exact metrics returned: cash runway, debt payoff horizon, freedom delta, calculation date, and data quality. This distinguishes it clearly from siblings like get_client_liquidity or get_client_tax_reserve.

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 trigger conditions ("how long their money lasts or how their income, spending, and debt compare") plus an access constraint ("Scoped specialists cannot access this snapshot"). It does not name specific alternative tools, so it stops short of a 5.

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

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

Annotations already cover readOnly, idempotent, non-destructive and closed-world semantics, so the bar is low; the description still adds real value beyond them by disclosing the 20-item result cap, the exact fields returned, and an access restriction (scoped specialists cannot read household strategies). It omits what happens when more than 20 strategies exist and whether the status filter accepts arbitrary strings.

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, front-loaded with the payload and bound, followed by the trigger and the negative scope. Nothing is redundant with the title or the schema, and every sentence 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?

With no output schema, the description carries the return-value burden and does so by enumerating the returned fields and the 20-item cap. The remaining gap is pagination/truncation behavior and how the status filter values map to records, which an agent may need 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%, so both parameters (status, clientId) are already documented, and the description adds nothing about their accepted values, format, or interaction. Baseline 3 applies 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?

Names a specific verb (read), a bounded resource (up to 20 saved household financial strategies) and the exact payload fields returned (status, next steps, progress, update dates). It also positively distinguishes itself from the sibling get_household_financial_snapshot by framing this as the strategy list rather than a snapshot, and explicitly disclaims creation/advice.

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 clear triggering condition ('Use when the user asks which strategies are active or what remains to do') plus explicit exclusions (not create a strategy, not new investment advice, not available to scoped specialists). It never names an alternative sibling tool to use instead, so routing between this and the snapshot/context tools still requires 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 (readOnly, idempotent, non-destructive, closed-world), and the description adds genuine extra context: it does not move money, make tax/legal recommendations, or treat missing evidence as an all-clear, and scoped specialists are excluded. Those boundaries materially shape how an agent should interpret and act 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?

Three front-loaded sentences with no filler; the scope, the joined data shape, and the limitations are all stated compactly. Phrasing like 'bounded next moves' is jargon-heavy but still compact.

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-shape burden and does so by enumerating what the view joins (coming dates, source records, responsible entities, connected cash, verification gaps, next moves). Combined with annotation-covered safety and full parameter documentation, an agent has enough to call this correctly, though the response format itself remains unspecified.

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 clientId parameter is fully documented in the schema, including the omit-for-self behavior. The description's 'your own record or an assigned client' mirrors the schema without adding syntax or format detail, so the baseline of 3 applies.

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

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

States a specific verb (get) and a specific artifact (a deterministic 90-day household readiness view), plus the scope (own record or assigned client). It clearly implies a distinct role next to snapshot/context siblings, though it never names an alternative tool to differentiate 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?

The description establishes the applicable scope ('your own record or an assigned client') and excludes scoped specialists, but it gives no explicit trigger for choosing this over get_household_financial_snapshot, get_what_matters_now, or get_meeting_prep. Usage is implied rather than directed.

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 readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds substantial behavioral context beyond them: exclusions and endorsements are NOT extracted, data is read from uploaded declarations, the resolved household must not be attributed to another person, and scoped specialists are excluded without an explicit future permission.

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 what the tool returns, then the guardrails. The adequacy prohibition is stated twice (once abstractly, once as a six-adjective list) and the clientId rule is duplicated from the schema, so it is somewhat longer than strictly necessary, though most sentences carry 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?

No output schema exists, so the description must carry the return shape, and it does so thoroughly (per-policy-type fields, staleness, currency, resolved household naming). For a single optional-parameter read tool with rich annotations, 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 description coverage is 100% for the single clientId parameter, so the baseline is 3. The description does add the decision logic (professional's own household vs. a client's) which reinforces rather than merely repeats the schema, but it does not extend beyond what the schema text already says.

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+resource ('Get the household insurance record') and enumerates exactly what is returned: life policies with sourced death benefit, face amount, cash value, coverage by type, staleness, plus auto/homeowners/umbrella limits, deductibles, named insured, dates, premium, currency. This is clearly distinguishable from siblings like get_household_financial_snapshot or get_client_product_state.

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 states the boundary of use ('never determines coverage adequacy') and routes the excluded judgment to a named alternative (coverageReviewPolicy.requiredStatement) and a licensed professional. It also spells out the clientId condition: pass for a client unless X1 already supplied client-scoped context, omit to read one's own household.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the payload composition and the 'you can access' access-boundary hint, but says nothing about response size, latency, truncation, or partial-availability behavior for a large aggregate bundle.

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 verb and the bundle contents; the second sentence earns its place by carving out scoped specialists. The content enumeration is long but each item is load-bearing for telling an agent what it will receive.

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

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

With annotations covering the safety profile and only one fully-documented optional parameter, the remaining burden is explaining what the aggregate returns, and the description does that by listing every constituent data source. No output schema exists, but the enumeration effectively substitutes for one.

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

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

Schema coverage is 100% with a single optional clientId documented as 'Client or member user ID,' which sets the baseline at 3. The description goes beyond that by clarifying the omitted-parameter case ('a meeting with yourself') and by tying the ID to 'a client/member you can access,' adding the access-scoping nuance the schema does not express.

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 lead verb 'Bundle' plus the enumerated contents (profile, product state, Pulse, plays, documents, family-office context, activity, shared member intelligence, CRM context) state a specific resource and scope, so an agent knows this is a composite prep payload rather than a single-entity getter. The closing note about scoped specialists being excluded further differentiates it from narrower siblings like get_family_office_context or get_client_product_state. It stops short of naming which sibling to use instead, which keeps it out of the top band.

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?

'For a meeting with yourself or a client/member you can access' implies the usage context (pre-meeting aggregation) but never states when to prefer this over the individual getters it bundles or over draft_meeting_brief. Among 46 siblings, no alternative is named and no prerequisite or exclusion is given beyond 'scoped specialists are excluded,' which is a content note rather than tool routing.

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

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

Annotations already establish the safe read profile (readOnlyHint, idempotentHint, non-destructive), so the description needn't repeat that. Instead it adds genuinely useful behavioral disclosure: which sensitive fields are suppressed (arguments, signatures, authorization revisions, bearer ids) and that the disposition projection is content-free and never returns targets, records, review text, or committed results.

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 dense sentences, front-loaded with the core action and its suppression guarantees before introducing the projection variant. It is information-rich rather than padded, though the second sentence is somewhat run-on.

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

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

With no output schema and no annotation coverage of the return shape, the description does explain the two response modes (legacy default vs content-free disposition), which is valuable. But it leaves the limit and toolName parameters unexplained, so an agent cannot fully construct a correct call from this text alone.

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

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

Schema description coverage is 0%, so the description carries the full burden. It explains requestId ('one exact requestId') and projection ('projection=disposition_v1') but says nothing about limit or toolName, leaving half the parameters undocumented anywhere.

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 (List) and resource (action-request statuses) with a clear scope restriction: 'created by this authenticated connector'. It distinguishes itself from receipt/thread siblings implicitly, but never names an alternative tool, so it stops short of full 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?

The description gives a concrete conditional for opting into the alternate response mode ('one exact requestId plus projection=disposition_v1'), which is real usage guidance. However it offers no when-to-use vs when-not guidance relative to siblings like list_my_confirmation_receipts or get_coordination_thread, so the routing value is only partial.

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, so the safety profile is covered. The description adds real behavioral context beyond that: results are only currently client-facing approved snapshots, never team drafts or unshared later edits, and revoked or withheld records are unavailable. It does not describe pagination token lifetime or result ordering, so it stops 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?

Four sentences, front-loaded with purpose and scope before the pagination/resume mechanics. It is dense but every sentence carries information. Minor awkwardness in 'Include bounded content to resume the approved work' costs it a point.

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 list tool with no output schema and no parameter documentation in the schema, the description covers what the records are, what is excluded, and how to page/resume. Nothing critical is missing, though ordering, page size defaults, and max-result behavior 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?

Schema description coverage is 0%, so the description carries the burden, and it explains three of four parameters: 'before' continues bounded pages, 'artifactId' resumes an older saved record, and 'includeContent' pulls bounded content. 'limit' is left unexplained, but overall the description meaningfully compensates for the empty 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?

The description opens with a specific verb+resource: 'Read your own approved household records shared by your professional team.' It immediately scopes the resource (approved snapshots, not drafts) and explicitly excludes the Vault uploads siblings, so an agent can distinguish it from get_vault_documents and check_vault_deposit without opening a schema.

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

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

It gives clear operational guidance: use 'before' to continue bounded pages, or an exact 'artifactId' to resume an older saved record. It also rules out Vault uploads as a target. It does not name a specific alternative sibling for the non-approved case, but the when-to-use conditions are concrete.

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, non-destructive, closed-world), so the bar is lower; the description adds genuinely useful context beyond that — member-entered provenance, not lender-verified, private scope, and the caveat that business balances are not a personal guarantee or household net worth.

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, front-loaded with the resource and contents, then provenance, then the usage caution. Dense but each clause carries information; 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?

For a no-parameter, read-only tool with no output schema, the description supplies the provenance, scope, and caveats an agent needs to interpret the data correctly and to avoid overstating it (e.g., treating business balances as net worth). Return shape is unaddressed but that is minor here.

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, which is the baseline-4 case; there are no parameters whose semantics need explaining and the schema is empty.

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 clear verb ("Read") and a specific resource ("your own member-entered loans") plus an enumerated inventory of contents (borrower links, dated balances, payment/maturity terms). It distinguishes the data's provenance ("member-entered", "not lender verified", "private to you"), though it never names a sibling tool to contrast against.

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?

Implied usage is present — read this before "proposing a change" and reuse the exact ids and revisions — but there is no explicit when-to-use versus alternatives or when-not-to-use guidance against the many sibling getters.

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, but the description adds substantive behavior: explicit exclusions (raw meeting statements, private notes, unapproved suggestions, cancelled tasks) and the co-owner permission boundary, plus a reinforcement that it assigns or completes nothing. The permission semantics are genuinely beyond what annotations provide.

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 resource, then exclusions and the permission caveat, then the read-only note. Every sentence carries weight, though 'This is read-only' mildly restates the annotation.

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 sketches the return (pending/completed state, prerequisites, attributed owner or relative due statement) and access restrictions. The one gap is the unexplained 'before' parameter, which leaves the filtering surface ambiguous.

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 parameter ('before') with 0% schema description coverage and no mention anywhere in the description. The description does not compensate for the gap, leaving the agent unable to know what 'before' filters or formats.

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 (your own household's explicitly approved meeting follow-up tasks) and enumerates scope: current pending/completed state, prerequisites, and owner/attribution. It clearly separates itself from the raw/private/unapproved/cancelled material it excludes, so an agent can tell what this returns 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?

It supplies an access prerequisite (member-only tasks require the current owner; a co-owner Vault permission does not grant them) but never states when to use this rather than nearby siblings like get_meeting_prep, get_my_action_requests, or get_my_approved_artifacts. Usage is implied by the scope rather than routed.

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

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

Annotations already establish readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-annotation context: an explicit privacy boundary about what is never surfaced (broad advisor roster, full household record). It does not, however, disclose error behaviors such as the access-denied case that the schema hints at.

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 core read action and closed by the scoping boundary; every clause carries information. The enumerated list is dense but each item earns its place. No padding or boilerplate.

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 is not obligated to explain return values, and annotations cover the safety profile. But for a 3-parameter listing tool it omits how limit caps results and what includeClosed toggles, and gives no hint of the access-denied failure mode, leaving gaps an agent would hit when invoking it.

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

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

Only clientId carries a schema description (33% coverage); limit and includeClosed are entirely undocumented in both schema and description. The description adds no parameter meaning at all – no mention of pagination limits or what includeClosed changes – so it 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 ("Read") plus a well-scoped resource (the connected network professional's shared-work context) and enumerates exactly what it returns: participant-scoped threads, packet/bundle shares, approved intro requests, and document-share boundaries. The closing negative clause ("never exposes a broad advisor roster or full household record") implicitly distinguishes it from roster/graph siblings like get_professional_graph_context, though it never names an alternative directly.

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: an agent can infer this is the tool for viewing shared-work context, and the exclusion clause hints at when it is the wrong tool. However there is no explicit when-to-use vs. when-not statement, no named alternative among the many sibling getters, and no mention of prerequisites such as the clientId visibility requirement.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds useful context: the result is 'bounded', it merges stored claims with a 'live' team graph, and access is scoped to what the caller may see. It still omits how reviewFilter/includeEvidence alter 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?

A single front-loaded sentence with no filler; the key resource and payload contents come first. It is dense but not padded, though the phrase 'bounded professional-graph claims' is slightly jargon-heavy.

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 and four undocumented parameters, the description should explain what is returned and how the filters behave. It names returned categories but leaves reviewFilter, includeEvidence, limit behavior and pagination unaddressed, so an agent cannot confidently parameterize the call.

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

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

Schema description coverage is 0% across four parameters, so the description must carry the burden. It partially covers limit ('bounded') and clientId ('client/member you can access'), but says nothing about reviewFilter's all/confirmed_only/pending_only semantics or what includeEvidence toggles.

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: returns boundedly-scoped professional-graph claims plus the live VFO team graph, naming concrete contents (relationship labels, specialties, capability summaries). However it never distinguishes itself from the nearby sibling get_business_entity_graph_context, leaving the agent to infer which graph context applies.

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 guidance and no mention of alternatives, even though get_business_entity_graph_context, get_client_profile, and get_member_artifacts all compete for similar intent. Only the implicit qualifier 'for a client/member you can access' hints at a precondition.

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, openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: it is a discovery tool that surfaces an 'authority contract' but explicitly does not itself grant authority, and it flags that full detail 'can be very large'. These non-obvious behavioral traits are useful to the agent.

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, front-loaded with the primary purpose before the write-contract and detail guidance. Each sentence carries distinct information with no redundancy. It is appropriately sized for a 3-parameter discovery tool.

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 capability-discovery tool with no output schema, the definition covers scope, the write-safety entry point, and the detail trade-off. Annotations carry the safety profile and the schema fully documents parameters, so the remaining need is small. It is nearly complete, missing only explicit routing against the get_x1_context/guide 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 coverage is 100%, so the schema already documents all three parameters, giving a baseline of 3. The description still adds real semantic value by explaining the intended sequencing: use toolName 'before a write' to obtain an execution/authority contract, and reserve detail: full for large diagnostic responses — guidance not present in the raw schema text.

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?

Starts with a specific verb+resource: 'Get a compact summary of the connected user's X1 entitlements, feature access, subscription context, and MCP scope visibility', which clearly identifies a capabilities/introspection tool. It also discloses a second mode (per-tool write contract via toolName). It does not, however, differentiate itself from siblings like get_x1_context, get_x1_guide, or get_x1_workflow_guide, so an agent must infer which introspection tool to pick.

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 concrete trigger condition: 'Before a write, pass toolName for that mounted write tool's complete execution and authority contract', plus 'Use detail: full only for large diagnostic responses.' This tells the agent when to use the summary mode vs the toolName mode vs full detail. It stops short of naming when-not-to-use or routing to a specific alternative sibling among the many get_* tools.

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 readOnly/idempotent/non-destructive already in annotations, the description adds substantial extra behavior: download-permission and household connected-document requirements, rate limiting, release logging in household access history, role-dependent scope (advisors and scoped specialists vs managed-program roles), and explicit caveats that the returned metadata does not verify source contents, extracted facts, or financial balances.

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 first sentence is a good front-load, but the remainder is one long run-on block that interleaves return values, version tokens, permission rules, scoping, and URL construction advice. Most sentences carry real content, but the lack of grouping makes it hard to scan and forces the reader to disentangle purpose from caveats.

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 explain returns, and it does: id, optional sourceVersion with version token/revision time/extraction-generation marker, X1-authored documentUrl, and summary. It also covers permissions and scope-based visibility. It is close to complete for a four-parameter listing read, with only minor gaps in pagination/inventory shape.

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 schema already documents all four parameters, establishing a baseline of 3. The description does add context for documentId (an exact own-account lookup may surface a closed sourceVersion) and for what summary holds, but limit/category/clientId get no added semantics 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?

The opening sentence pins a specific verb and resource: 'Canonical MCP read for vault document inventory,' and the text distinguishes itself from mounted siblings get_document_content and get_document_download_url. 'Inventory' communicates a listing read, though the description never plainly says it returns a list of documents, so the purpose is clear but partly inferential.

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

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

It gives explicit routing: on external professional connectors use get_document_content or get_document_download_url (once per document id, when mounted), otherwise open the document in X1. It also states the access conditions under which this applies. It stops short of contrasting with the many sibling search_* document tools, so the alternative-selection guidance is strong but not exhaustive.

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, so the safety bar is lower. The description adds genuine behavioral context beyond annotations: the composition of results (focus items + grounding context + suggested next actions) and a permissions/scoping constraint about specialists being excluded. Good value added.

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 compact sentences with the primary purpose front-loaded and a caveat second. No filler, though the second sentence's phrasing is slightly abstract.

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, zero-required-param tool with 100% schema coverage, the description is nearly complete. It omits any notion of result shape or ordering, but with no output schema and readOnly annotations, the remaining gap is minor.

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 both parameters (clientId, weekStart) are well documented with omit-defaults semantics. The description adds no parameter detail beyond the schema, so baseline 3 is appropriate.

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

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

States a specific verb ('surface') and resource ('prioritised weekly focus items with grounding context and suggested next actions'), which clearly distinguishes it from sibling getters like get_meeting_prep or get_my_action_requests. It's clear what the tool returns, though the 'member's' scope vs 'own household' isn't fully differentiated from relatives like get_client_activity.

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?

No explicit when-to-use guidance relative to siblings such as get_my_action_requests or get_meeting_prep, which likely overlap. The sentence about scoped specialists is a permission caveat, not usage selection guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds that the payload contains 'product context, surfaces, and MCP guidance', but does not clarify what 'surfaces' means, how large the response is, or whether it is static content versus live state.

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 with the action first and the rationale second; nothing is wasted. It is slightly padded by the trailing 'how it is meant to be used' clause, which adds little beyond the preceding phrase.

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 parameterless, read-only context tool with no output schema, the description gives a rough sense of the payload but not its structure or when it beats the sibling guide tools. An agent can invoke it correctly but may not know it picked the right X1-related 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 disambiguate, and it correctly does not invent parameter behavior.

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 and resource ('Get structured X1 product context, surfaces, and MCP guidance') and scopes it to orientation about the X1 product, which is more concrete than the bare name. However, it never distinguishes itself from close siblings like get_x1_guide and get_x1_workflow_guide, so the agent cannot tell which of the three to 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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named despite two obvious sibling candidates (get_x1_guide, get_x1_workflow_guide). The clause 'so Claude can reason about what X1 is' hints at intent but leaves routing entirely to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description adds that the guide is curated, account-specific ('describes their own account'), and covers boundaries and workflows, which tells the agent the content is personalized rather than generic. It does not describe return format or pagination, but with rich annotations this is a solid addition.

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 begins with the usage trigger and then lists the guide's contents. There is no wasted language, and the key routing condition is placed first.

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 four optional parameters, full schema coverage, and no output schema, the description supplies the missing content-level context: it explains that the tool returns an account-specific guide covering X1, capabilities, workflows, and boundaries. It omits explicit routing against similar siblings, but is otherwise complete enough 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 coverage is 100%, so all four optional parameters are already documented with descriptions, enums, and examples such as 'what can X1 do for me'. The description adds no parameter-level syntax or semantics beyond what the schema provides, making the baseline 3 appropriate.

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

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

States a specific resource (a curated guide to X1) and scope (what this person can do on this connection, key workflows, boundaries) in concrete terms. It does not explicitly differentiate from sibling tools like get_x1_workflow_guide, which also likely covers workflows, 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?

Explicitly says 'Use when the connected person asks what X1 is or what X1 can do for them,' giving a clear trigger condition. It does not name when not to use it or point to alternatives such as get_x1_context or get_x1_workflow_guide, so it stops short of the top score.

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, non-destructive), so the bar is lower. The description adds one useful output fact—'full production app URLs'—and the role-aware framing, but says nothing about guidance format, length, or how detail=concise/detailed changes 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?

A single rambling run-on sentence crams the entire workflow taxonomy into one breath, with 'Or choose an X1 workflow artifact...' bolted on. It is dense and hard to parse rather than front-loaded and 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?

For a zero-required-parameter guide with no output schema, the description conveys the broad domain and output contains app URLs, which is adequate. But with 5 parameters and a lookalike sibling, it stops short of telling the agent what it gets back or how this differs from get_x1_guide.

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 baseline is 3. The description largely restates the workflow enum descriptions already present in the schema rather than adding new syntax, defaults, or interaction rules between topic/states/clientId and workflow.

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?

'Get role-aware guidance' states a verb and resource, but the sentence immediately dissolves into an enumeration of workflow values, so it is unclear whether the tool returns guidance text, routes to a workflow, or produces artifacts. No differentiation from the very similar sibling get_x1_guide, leaving the agent unable to tell the two guides apart.

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

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

Provides explicit routing with exclusions: 'use money_check for dated official state unclaimed-property destinations, not search results' and 'use review_capital_call only for a capital-call notice'. This is when-to-use guidance for the workflow values, though it never says when to prefer this tool over get_x1_guide.

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

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

Adds substantial context beyond annotations: it clarifies that the operation 'works with read access and grants no household write access' even though readOnlyHint=false, explains that labels/reports are unverified observations, enumerates prohibited data, and discloses the outcome ('records the report for human triage; it does not automatically fix or retry'). This resolves the apparent read/write tension rather than contradicting it.

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 purpose, then constraints, then privacy, then outcome — a sensible priority order with no obvious filler. The privacy sentence is dense but every clause carries content (document contents, prompts, arguments, identifiers, personal data).

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 feedback-submission tool with no output schema, the description covers purpose, data restrictions, permissions, and the fate of the report. It falls short only in not clarifying parameter-choice semantics, which the 0%-coverage schema leaves entirely undocumented.

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% across 8 parameters (6 enum-constrained), so the description carries the load. It names several parameter families (categories, capability choices, client choices, tool names) but says nothing about what 'goal', 'observed', or 'severity' mean or how to choose among their enum values.

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 (report) and enumerates the exact resource classes (X1 MCP tool error, confusing result, missing capability, connection instruction). This is clearly distinguishable from every sibling, which are all read/draft/query tools.

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 timing condition ('after serving the user's request') and a scope restriction ('submit only the listed categories, capability and client choices, and known X1 tool names'). It does not name an alternative tool, but no sibling competes for this purpose, so the omission is minor.

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 the description adds behavior they cannot: the default page size of 20, the distinction between memberCount (total matches) and returnedCount (this page), the response-size budget that can shorten a page, and the requirement to reuse the same query when paging. With no output schema, this is exactly the disclosure an agent 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?

Four dense sentences, front-loaded with the lookup purpose, then return shape, then pagination, then the ambiguity warning. Every sentence carries weight, with only minor overlap against the schema's own cursor/limit text.

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-param, read-only paginated search with no output schema, the description covers defaults, paging, returned fields (role, profile policy, specialist boundaries), and multi-match ambiguity. It omits any note on authorization requirements or what 'managed-program/VFO' means, but nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100%, so limit, query, and cursor are already fully documented. The description restates the default-20 and same-query-for-cursor semantics but adds no new syntax or constraints beyond the schema, matching the baseline 3.

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

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

States a specific verb (find/list) and resource (authorized managed-program or VFO members) plus the lookup keys (name, email, exact ID). The 'authorized managed-program or VFO' scope distinguishes it from the many document/thread/entity siblings, though no sibling is named explicitly to route between near-neighbors.

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: prefer search when a person is named, never guess between multiple matches, and only follow nextCursor when more results are needed. It stops short of naming an alternative tool or stating when not to use it, but the conditions for use are unambiguous.

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, destructiveHint=false and openWorldHint=false, so the 'writes nothing' sentence is partly redundant — but 'grants no document access' and the caller-eligibility rules (member vs professional vs scoped specialist) are behavioral facts the annotations do not encode. It still omits pagination/limit 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?

Three dense sentences, front-loaded with purpose before eligibility constraints; little waste. The middle 'Read-only' sentence slightly overlaps the annotations and could be trimmed.

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 explained, yet the description still lists them usefully, and it covers the authorization model thoroughly. The gaps are the undocumented limit/pagination semantics and the unstated default for status.

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 carry the param burden. It explains clientId well (omission rules per role) and mentions status values, but it silently drops the schema's 'all' enum value and says nothing about what limit does or what the default status is. Baseline 3 for partial compensation.

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 the document requests on an X1 record') and enumerates exactly what each listed item contains (status, type, reason, deadline, requester, timestamps). This clearly separates it from the write-side sibling draft_document_request and from search_documents or get_vault_documents.

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, role-conditional access rules: members may omit clientId, professionals must pass clientId unless X1 supplied a client-scoped context, and scoped specialists are excluded. That is genuine when-to-use/when-not guidance rather than implied usage.

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, non-destructive, closed-world), yet the description adds substantial behavioral context beyond them: self-added items are labeled, non-source-backed, and non-fileable until X1 matches evidence; explicit current filters stay source-backed; non-fileable entities can't be belongs-to targets; identifiedForReview items are never counted. This is rich, non-redundant disclosure.

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

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

The purpose is front-loaded, but the body is a single dense paragraph mixing return contents, filter behavior, filing eligibility, and role permissions. Each clause is substantive but the lack of structure makes it harder to parse than it needs to 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?

With no output schema and six parameters at 50% description coverage, the description does most of the heavy lifting: it explains the filtered-return behavior, the identifiedForReview bucket, and filing constraints. Only a few parameter-level details remain underspecified.

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 50%: status, clientId, and clientRef are documented in-schema. The description adds meaning for includeCounts ('optional document/artifact counts') and implies entity types and lifecycle state, but limit, the entityType enum values, and includeCounts semantics are not explained beyond the schema. It only partially compensates 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 states a specific verb and resource: 'List the household's structured entities, trusts, properties, assets, and personal filing bucket,' and enumerates the returned fields (stable IDs, lifecycle state, aliases, counts). This clearly distinguishes it as a household-graph listing tool, though it doesn't explicitly contrast with nearby siblings like get_household_financial_snapshot or get_family_office_context.

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

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

It gives concrete usage context: members and Multiplier operators use fileable IDs for filing/cleanup, advisors use them to understand the household map and file artifacts, and scoped specialists are excluded. However, it never explicitly routes the agent away from this tool to a specific alternative when the household graph isn't what's wanted.

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, destructiveHint=false, openWorldHint=false), so the description's added value is the role-based visibility scoping and the fact that results are split into two lists. It stops short of describing pagination behavior despite a limit parameter.

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 tightly packed sentences with the primary output stated first and the role-scoping caveat second; no filler. The second sentence is dense and slightly run-on, but every clause carries information.

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

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

There is no output schema, and the description compensates by explaining the two-list return structure and the role-dependent filtering. It leaves the limit/pagination behavior and empty-result handling unspecified, which is a modest gap for a read-only list 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 75%, with status, clientId, and clientRef already documented in-schema, including the 'Defaults to pending' and 'Members usually omit this' notes. The description adds no syntax or format detail beyond what the schema provides, so the baseline of 3 applies.

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

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

The description gives a precise verb+resource ('List ... household entity cleanup proposals for a member') and immediately clarifies the return shape by naming a second distinct output list, ownershipEdgeProposals. That resource is clearly separable from the closest sibling, list_household_entities, which returns entities rather than proposals.

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 spells out role-conditional behavior: members/coaches/admins get the actionable review queue, while advisors and scoped professionals see only their own submissions. That tells an agent what to expect for the calling user, but it never states when to prefer this tool over an alternative or what to do if the result is empty.

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 beyond the readOnly/idempotent annotations by disclosing the crucial behavioral traits: receipts are single-use, viewing one confers no authority, and X1 re-verifies signature, surface, tool, live entitlements, and exact arguments before execution. That is exactly the kind of safety semantics an agent needs and cannot infer from the annotation block.

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 core action and scope before the usage cue and the safety caveat. Every clause carries distinct information; nothing is redundant 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?

With no output schema, the description still communicates what is returned (unused receipts on this surface) and why it matters, and the two optional parameters are covered by the schema. Minor gaps remain around ordering or how the limit interacts with the result set, but 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 description coverage is 100%, so limit and toolName are already fully documented in the schema. The description adds no syntax, default, or format detail for either 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?

States a specific verb (List) plus a precisely scoped resource (confirmation receipts you granted in X1 that have not been used yet, on this connection's surface). The scoping qualifiers cleanly distinguish it from siblings like get_my_action_requests or list_household_entity_change_proposals without needing to open 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 an explicit trigger: 'Use it after someone approves a batch of queued proposals in X1 so you can act on exactly what they approved.' That is clear when-to-use guidance, but it names no alternative tool or when-not condition, so it stops short of a full routing statement.

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

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely non-schema context: the caller-relative visibility model ('members see their own; professionals only see threads where they are active participants or watchers') and the shape of each returned row.

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 front-loaded sentences: purpose and returned fields first, then usage guidance, then visibility. Efficient, though the attention explanation slightly duplicates the schema description rather than adding new 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 usefully enumerates returned fields (status, next owner, last activity, attention signals, summary) and explains the access model. Gaps remain around pagination/limit behavior and the status enum, but the core calling context is present for a read-only listing 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 40%: clientId and attention are documented in the schema, while limit, status, and includeClosed are undocumented in both places. The description's attention guidance largely restates the schema's own attention description and says nothing about limit, includeClosed, or what the status enum values mean, so it only partially compensates.

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?

Clear verb+resource ('List coordination threads') with an explicit access scope ('the caller can access') and an enumeration of returned fields. However, it never distinguishes itself from the sibling find_coordination_threads, which an agent could plausibly 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?

Gives concrete when-to-use guidance for the attention modes ('use waiting_on_me for what is on my plate', 'changed_since_last_read for what changed since I last looked'), and states the visibility rule for members vs professionals. It stops short of naming an alternative tool or stating when NOT to use this one.

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

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

Beyond the readOnly/idempotent annotations, it discloses asynchronous indexing lag, the 'still indexing, try again shortly' response pattern, that results carry a document id and an X1-authored documentUrl, a firm prohibition on constructing URLs, rate limiting, current-download-permission and household-access requirements, and access-history recording.

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

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

Purpose is front-loaded and every sentence carries operational information rather than filler; length is justified by the connector, permission, and indexing caveats. It is dense and slightly long, but no sentence is redundant.

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 compensates by describing the result shape (document id, optional documentUrl), indexing behavior, permission prerequisites, and the per-role visibility model — everything an agent needs to call and 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?

Schema coverage is 100%, so the schema carries the baseline, but the description adds real query semantics the schema lacks: filename matching works as displayed in Vault even when the stored name uses separators, and it clarifies that the returned documentUrl must be used verbatim. The category/clientId/dateFrom filters get no extra elaboration.

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

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

The opening sentence gives a specific verb and resource with scope: 'Canonical MCP read for vault document metadata and summary search.' It implicitly separates this tool from the body-content variants by directing content queries elsewhere, though it never names search_my_documents or search_my_document_contents explicitly, so an agent must infer the sibling boundary.

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

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

It explicitly routes the agent: metadata/summary search here, 'use the body-content search tools for content', then on external connectors use get_document_content or get_document_download_url per document id, otherwise open in X1. It even covers role-scoped visibility for advisors, specialists, and managed-program roles.

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 already declaring safety, the description adds substantial context beyond the annotations: it states the tool returns matching passages rather than writing an answer, clarifies that coverage modes are passage-level and not page-by-page reviews, and warns about asynchronous indexing and rate-limit retry behavior. These are exactly the operational traits annotations do not cover.

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 passage is dense but front-loaded: purpose and return behavior first, alternatives second, operational constraints last. It is longer than most tool descriptions, but nearly every sentence carries unique routing or behavioral information, so little waste is present.

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, idempotent search tool with an output schema already present and 100% schema description coverage, the description completes the picture by covering result semantics, comparison workflow, coverage-mode behavior, rate limiting, and indexing latency. 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 coverage is already 100%, so the schema documents all five parameters. The description still adds meaning by explaining the semantics of coverage modes (all_requested requires a matching passage from every selected document; best_effort can return partial evidence) and the compare-by-documentIds pattern. It does not discuss limit, query, or clientId semantics 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?

The description states a specific verb and resource ('Search the text (body contents) of the connected person's own documents in X1') and explicitly distinguishes itself from the name/title/tag search alternative. An agent can immediately tell it apart from search_documents or search_my_documents 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?

It gives explicit when-to-use criteria ('when they ask what their own documents say'), names the alternative for metadata search, instructs how to compare known files (pass up to 10 documentIds instead of parallel calls), explains when each coverage mode applies, and cautions about rate limits and the still-indexing state. This is a complete routing and prerequisite guide.

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 safe-read profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds real value: the server binds the search to the authenticated account and accepts no clientId/account identifier, only X1-authored documentUrl links should be used, and an empty result means no matching metadata rather than a missing notice. That is substantive behavioral 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?

Front-loaded with the core action, then progressively adds scoping, routing, and result-handling rules. It is longer than most definitions but nearly every sentence carries distinct operational guidance; only the closing sentence about the governed metadata audit and document authority feels like boilerplate.

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 compensates by describing the return shape (X1-authored documentUrl links, use only those) and the meaning of an empty result. Combined with the account-binding rule and sibling routing, an agent has everything needed to call and 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?

Schema coverage is 100%, so query, category, and dateFrom are already documented, establishing the baseline of 3. The description's mention of 'filename, title, and tags' as searchable facets is only loosely mapped onto the actual parameters (there is no tag parameter), so it adds flavor but little precision.

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 (Search) and resource (your own X1 Vault) plus the searchable facets (filename, title, category, tags) and the pre-indexing scope. It clearly differentiates itself from siblings search_documents and search_my_document_contents by naming the vault ownership boundary.

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

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

Explicitly says when to use it (the connected person searching their own Vault, even if they hold an admin or professional role) and routes alternatives: search_documents for a client's Vault, search_my_document_contents for cited body passages. Exclusions and alternatives are stated, not implied.

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, destructiveHint=false and openWorldHint=false, so the safety profile is largely covered. The description reinforces this with domain-specific detail (no Vault import, no browser launch, no external contact), which adds some concrete value but mostly restates the annotation surface.

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 with the purpose front-loaded and the safety constraints as a clear follow-up. 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?

There is no output schema, so the description should convey the return content; it hints at 'artifacts and proposed filings' but doesn't describe the summary's shape or what happens when the mission has no artifacts. Adequate for a read-only tool but leaves return expectations underspecified.

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 the single required parameter (missionId), and the description never mentions it or its expected format. With a parameter present and undocumented, the description should compensate but does not.

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 ('Summarize') and resource ('quarantined BrowserMission artifacts and proposed filings'), which is distinct from siblings like get_browser_mission_status and draft_browser_evidence_mission. It does not explicitly name the adjacent tools, so an agent must infer the boundary, but the resource specificity is high.

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 phrase 'for member review' implies the use context, and the read-only disclaimer signals when the tool is appropriate. However, it never states when to prefer it over siblings such as get_browser_mission_status, nor any exclusions or prerequisites.

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 value by disclosing the briefing's actual contents (participants, status, decisions, open questions, next step) and, notably, that the delta is 'caller-specific' and relative to last look — context an agent cannot derive from 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?

Two tight sentences with the core purpose front-loaded and the content enumeration second. No filler, though the long comma-separated list slightly blurs into the delta clause.

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 correctly carries the burden of describing the return shape by enumerating the briefing's sections. Combined with access rules and the caller-specific delta note, it is sufficiently complete for a read-only summarization tool, though focus-value behavior remains 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?

Schema coverage is only 33% and the description lists content categories (next step, decisions, open questions, delta) that map onto the focus enum values, partially compensating for the low coverage. But it never explains the focus enum itself or the difference between 'full' and the narrower focuses, leaving the parameter only loosely clarified.

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?

Specifies a clear verb (summarize/generate a briefing) and resource (coordination thread), and the word 'briefing' implicitly contrasts with fetching a raw thread via get_coordination_thread. However, it never names the sibling alternatives (get_coordination_thread, list_my_coordination_threads) explicitly, so the differentiation is inferred 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 visibility/access conditions ('visible to the household member or an active participant/watcher') and notes that professional callers are limited to threads where they participate, but gives no explicit when-to-use-this-vs-get_coordination_thread guidance. Usage is implied by the noun 'briefing' 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.