Zambo

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. The description adds real value beyond them: the ledger is private and receipt-backed, the call is free and does not consume the daily allowance, and the AER-1 receipt is offline-verifiable.

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, followed by the cost and verification guarantees. Every sentence carries information, though 'AER-1' is unexplained jargon.

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

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

An output schema exists, so the return value need not be described, and annotations cover the safety profile. The billing and receipt guarantees are the genuinely useful additions; only the meaning of the 'Today link' artifact and cross-tool positioning are left uncovered.

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% across all 8 optional parameters, so the schema does the heavy lifting and the baseline of 3 applies. The description adds no meaning about how date, agent_name, or the underscore-prefixed continuity handles affect the returned ledger.

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 private, receipt-backed work ledger for this job, returning a 'Today link'. That separates it from siblings like journal_log or continuity_get_recent, though 'Today link' is never defined, so the concrete artifact returned stays slightly opaque.

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 never says when to reach for this tool versus continuity_get_recent, memory_recall, or journal_log. It only mentions commercial terms ('always free, does not use the daily call allowance'), which is billing context, not usage 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 and destructiveHint=false, so safety is covered. The description adds value by describing the shape of results (relevance scores, taglines, callable endpoints) and the referral reward mechanic, but 'AER-1 receipt, verifiable offline' is unexplained jargon that tells an agent nothing actionable.

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 purpose and followed by return contents and the referral nuance. The closing 'AER-1 receipt, verifiable offline' fragment is opaque filler that does not earn 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?

A read-only search whose annotations cover the safety profile, whose ten parameters are fully described in-schema, and which has an output schema so return values need no prose. Purpose, result contents and the referral case are all covered; only sibling routing is missing, and that is scored under usage guidelines.

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 every parameter, including the q/query/keyword/search aliases and the underscore-prefixed session/continuity fields, is documented in the schema itself. The description adds only the contextual link between 'Referral searches' and the _ref parameter, so it neither needs to nor does compensate further.

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: 'Search across the supported Zambo tool catalog for a use case', and enumerates what a result contains (relevance scores, descriptions, taglines, API endpoints). It is clearly a catalog-discovery tool, but it never names or contrasts with the closest siblings (zambo_universal, zambo_home), so differentiation is left to inference.

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

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

Implies usage ('search ... for a use case') and carves out one narrow scenario ('Referral searches find the invite-link tool and its 2,000-call reward'), which is useful but exotic. There is no explicit when-to-use versus the catalog-browsing siblings, no statement about when not to call it, and no guidance on query formulation.

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, so the safety profile is covered. The description contributes beyond that by asserting 'AER-1 receipt, verifiable offline' and flagging the job ID as private, plus pagination-stability guidance. It still says nothing about rate limits, access requirements for the private job, or what happens if both resume_code and thread_id are supplied.

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 tight sentences, front-loaded with what is read, then the two input modes, then pagination. No filler, though the trailing 'AER-1 receipt, verifiable offline' is a fragment whose practical meaning for invocation is thin.

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 13 optional parameters, rich annotations, and an output schema (so return values needn't be described), the description covers the main invocation paths and pagination correctly. The remaining gap is scope ambiguity: 'thread_id omitted reads the job and its named threads' lives only in the schema, and nothing says how this differs from continuity_list_threads.

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 above that by mapping the loosely named 'existing private job ID' to the actual session parameters and by spelling out what resume_code returns and how since/cursor interact across pages — linkages the schema documents only piecemeal.

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: reads receipt-backed work for a job or named thread, and explicitly distinguishes the resume_code path (full saved handover, notes, handover ID, JSON URL) from the job-ID path. The phrase 'receipt-backed work' is jargon an agent may not fully decode, and it never names the sibling it is not (continuity_list_threads, handover_status), so it falls short of a 5.

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

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

It gives conditional guidance for two modes ('Pass resume_code ... otherwise use the existing private job ID') and tells the agent to use since plus the returned cursor for pagination. However, with siblings like continuity_list_threads, handover_list, and handover_status in the same family, there is no explicit when-to-use-this-instead-of-those statement, leaving mode selection partly inferred.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is clear. The description adds that threads are owned by the supplied job ID and that thread IDs can be reused as _session_id by another AI client, but terms like 'AER-1 receipt' and 'verifiable offline' are unexplained jargon rather than actionable behavioral detail.

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

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

Three short sentences, front-loaded with the core action. The final sentence about the AER-1 receipt is compact but cryptic, slightly reducing clarity without adding much length.

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

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

An output schema exists, so the description need not explain return values, and annotations cover safety. However, for a listing tool with seven optional parameters and several continuity-related siblings, the description lacks sufficient guidance on usage and does not clarify the receipt terminology.

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 mentions the supplied job ID, but it does not clarify the relationship between session_id and _session_id aliases or explain the many optional continuity parameters beyond what the schema already provides.

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

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

States a specific verb and resource: it lists named threads owned by the supplied job ID. The ownership scoping by job ID is useful, but it does not explicitly distinguish itself from siblings like continuity_get_recent or continuity_start_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?

The description implies listing threads and notes that returned thread IDs can be used as _session_id elsewhere, but it gives no explicit when-to-use guidance or alternatives. It does not explain when to choose this over continuity_get_recent or continuity_start_thread.

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, open-world, so the safety profile is covered. The description adds real value beyond that: results are filtered to events with stored Zambo receipts, links to open/check each receipt are included, and receipts are AER-1 verifiable offline. It omits what happens for a nonexistent thread and the role of the _zambo_key capability.

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

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

Two short sentences, front-loaded with the action and result shape; nothing redundant. The trailing 'AER-1 receipt, verifiable offline' is terse jargon but does convey a trust property, so it 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?

An output schema exists, so return-value explanation is not required. But for a tool with 10 optional params, continuity/capability mechanics, and a confusingly named sibling, the description leaves gaps: no creation-vs-resume semantics, no auth/capability note, no error 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% across 10 parameters, so the schema carries the semantics. The description only loosely maps 'named thread or thread ID' onto name/thread_id and adds nothing about limit, session binding, or caller-label fields. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a verb and resource ('opens a named thread or thread ID') and the filter applied to results ('only events with stored Zambo receipts'). However, 'opens' is ambiguous next to the sibling continuity_start_thread — an agent cannot tell from this text whether open creates a thread, resumes one, or merely reads it. No sibling is named or excluded.

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 no when-to-use guidance and never contrasts itself with continuity_start_thread, continuity_list_threads, or continuity_get_recent. The only routing hint ('thread_id returned by continuity_start_thread') lives in the schema, not the description.

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

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

Annotations already declare non-destructive, idempotent, open-world mutation, so the safety profile is covered. The description adds real value by clarifying that existing public receipts are neither removed nor hidden and that a verifiable AER-1 receipt is produced. It stops short of describing authentication/capability requirements (_zambo_key, _caller_handle) or the response body.

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

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

Three short sentences with the primary effect front-loaded and the non-destructive caveat immediately after. No filler, though the trailing 'AER-1 receipt, verifiable offline' clause is cryptic without prior context.

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

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

With 12 optional parameters, an output schema, and open-world mutation semantics, the description is thin on access requirements and on the other preference dimensions the tool actually accepts. It correctly avoids restating return values since an output schema exists, but an agent could reasonably conclude the tool only sets capture_enabled.

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 capture_enabled, daily_recap, timezone and the capability fields, is already documented in the schema. The description adds no syntax, default, or interaction detail beyond that, 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 effect: it toggles whether future successful calls are captured in the private timeline. That is concrete and distinguishable from read siblings like continuity_get_recent. However, the name promises 'prefs' plural while the description only covers the capture flag, leaving daily_recap and timezone scope unstated.

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 guidance on when an agent should call this versus continuity_get_recent, continuity_start_thread, or journal_log. It never says under what circumstances to enable or disable capture, nor whether it must be called before other continuity 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?

Annotations already declare idempotentHint=true and destructiveHint=true; the description's 'creates or reuses' is consistent with the idempotency claim and adds useful context via the offline-verifiable AER-1 receipt. It does not disclose what is destructive about the operation, nor that a capability (_zambo_key / _caller_handle) may be required, leaving a gap against destructiveHint=true.

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

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

Three short sentences, front-loaded with the action and scope, then the chaining instruction, then the receipt note. No filler, though the 'Required arguments: name' clause duplicates the schema's required array.

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 correctly focuses on purpose and the session-id handoff. What it omits is the sibling disambiguation and the auth/capability requirement implied by _zambo_key and _caller_handle.

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 all eight parameters are already documented in the schema; baseline is 3. The description restates that 'name' is required and explains the thread_id→_session_id handoff, which is marginal added value rather than new parameter 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 gives a specific verb+resource ('Creates or reuses a named thread') and scopes it ('under an existing job ID'), which is concrete enough to act on. It does not, however, distinguish itself from the sibling continuity_open_thread, so an agent cannot tell from the description alone which of the two 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?

'Pass the returned thread_id as _session_id to append work from another AI client' gives real usage context for the chaining scenario. But there is no guidance on when to use this instead of continuity_open_thread or continuity_list_threads, and no prerequisites or exclusions are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds two real behavioral facts — that the data is a live, verified index and that results come with an AER-1 receipt verifiable offline — but leaves 'AER-1' unexplained and never states update cadence, verification method, or whether the _zambo_key capability is needed for full 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?

Four short sentences, front-loaded with the resource before the filters. Minor waste: enumerating 'count, updated_at, opportunities, and api' duplicates the output schema and 'api' is an opaque field name.

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 nine-parameter tool with a rich annotation set and an output schema, the description covers purpose and filters adequately. But unexplained jargon ('AER-1 receipt', 'api') and the absence of any note on freshness or verification leaves an agent guessing about what 'verified' actually guarantees.

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

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

Schema description coverage is 100%, so the schema already documents all nine parameters including the underscore-prefixed continuity fields. The description only echoes the three business filters (stack, stage, min_value) without adding syntax or semantics, which is the expected baseline 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 names a specific resource: a live verified index of AI and cloud startup credit programs, with the filter dimensions spelled out. An agent can tell what it retrieves, though it never distinguishes itself from plausible siblings like capability_search or live_price.

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 says the filters are optional and lists them, but gives no when-to-use condition, no prerequisites, and no named alternative for overlapping needs (capability_search, leadsignal). The only "leave empty to include all" guidance lives in the schema, not the description.

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 destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is partially covered. The description adds useful behavioral context beyond annotations: it may return a payment challenge before activation, activation is gated on a verified transfer, and results include a spend receipt and verifiable AER-1 receipt. It still does not explicitly explain what is destructive or what costs are incurred.

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

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

The description is compact and front-loaded, moving from purpose to accepted inputs to return behavior and activation gating. Every sentence contributes useful information without redundant repetition.

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

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

Given the output schema and full schema description coverage, the description supplies enough context to invoke the tool: input modes, challenge-versus-result behavior, verified-transfer gating, and receipt outputs. It is slightly incomplete because it does not route the agent among sibling day_pass tools or spell out destructive/payment implications beyond annotations.

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 10 parameters are already documented in the schema. The description only adds a high-level contrast between an optional payment envelope and an existing access key, without explaining the remaining parameters such as sponsor, workflow_id, session_id, or caller labels.

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: activating a Day Pass, with optional payment envelope or existing access key, and returning either a payment challenge or verified activation result. It is clear what the endpoint does, but it does not explicitly differentiate itself from siblings such as day_pass_redeem, day_pass_checkout_link, or day_pass_status.

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

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

The description implies the usage flow: call with a payment envelope or access key, and activation occurs only after a verified transfer. However, it does not explicitly say when to use this tool versus the day_pass_* alternatives, nor does it state when not to use it.

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

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

Annotations only say readOnlyHint=false, idempotentHint=true and destructiveHint=false; the description adds substantive context beyond that — link creation is non-charging, the sponsor flag never transfers branding ownership, and an offline-verifiable AER-1 receipt is issued. It does not cover rate limits or what the returned link's lifetime is, which keeps 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?

The core content is front-loaded and dense, but the definition ends with a dangling fragment, 'Required arguments: .', which is leftover template noise implying required parameters that do not exist (required=[]). That artifact works against the otherwise efficient single-paragraph structure.

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 no explanation, and annotations cover the safety profile; the description supplies the pricing, payment, sponsorship and receipt facts an agent needs to call it correctly. Only the sibling-routing guidance and link expiry behavior are 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% across 11 parameters, so the schema already explains _ref, _zambo_key, _caller_handle, human_approved and the rest. The description adds only meaning for workflow_id and sponsor, which the schema also documents, so per the baseline rule a 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?

Specific verb and resource: it produces a checkout link for the $0.99 24-hour Day Pass, with payment-channel and fresh-session scope stated. It is clearly a different action from the sibling redeem/activate/status tools, though it never names them 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 implies the correct point in the flow ('Creating the link never charges anyone; payment requires completing checkout') and scopes the two conditional arguments (workflow_id for a closed run, sponsor for another team's run). It never states when to call this instead of day_pass_activate or day_pass_redeem, so the agent must infer the ordering.

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 (readOnly, idempotent, non-destructive, openWorld), it adds real context: no headers required, the link's expiry tied to the original pass, and that an offline-verifiable AER-1 receipt is issued. It still doesn't say whether a capability/session is minted, what the response holds, or what happens on an expired link, which matters for a redeem operation.

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

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

Four short sentences, front-loaded with the core action and credential requirement, with no filler. Each clause carries information about inputs, auth, or the receipt.

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

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

An output schema exists so return values needn't be explained, and the receipt/expiry notes help. But with an anyOf accepting four alias names and a dense set of optional continuity fields, an agent still lacks a clear picture of the redeem flow and the trigger conditions.

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 all ten parameters including the token_or_link aliases and the underscore-prefixed handover fields are documented in the schema. The description adds no parameter-level meaning (e.g., which alias to prefer when several are accepted), 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?

The description gives a verb+resource ('Unlock this AI with your private Day Pass link'), but 'unlock this AI' is vague about what actually happens, and it never distinguishes itself from the closely named siblings day_pass_activate, day_pass_status, or pass_status. An agent can tell it involves a Day Pass, but not precisely what redeeming produces.

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 'No headers needed' and that the link expires with the original pass, but gives no guidance on when to redeem versus activating, checking status, or requesting a checkout link. The choice among the four day_pass_* siblings is left 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 readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description still adds non-obvious behavior: it does not spend quota, product/provider limits may still apply, and it emits a private unlock link plus an offline-verifiable receipt. The 'AER-1 receipt' phrasing is opaque jargon, but the quota and limit disclosures are genuine extra value.

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 and the all-optional-arguments note are front-loaded and the whole thing is short. The trailing 'AER-1 receipt, verifiable offline' is compressed to the point of being cryptic rather than informative.

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

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

An output schema exists, so the return-value list in the description is redundant but harmless. The key behavioral facts (no quota spend, limits may apply, optional arguments) are present; what is missing is any statement of authentication requirements for the optional token_or_link or _zambo_key paths.

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 mentions only four of ten parameters (current session, token_or_link, thread_id, _zambo_key) and omits _ref, status_token, _caller_label, _caller_handle, and _continuity_ai_label; it adds no syntax or format detail beyond the schema.

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

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

States a specific verb and resource ('Check your current pass') and names the equivalent sibling alias 'pass_status', so an agent can tell it is the same as that tool. It does not clearly distinguish itself from day_pass_activate or day_pass_checkout_link, but the read-only status role is evident from the 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?

'All arguments are optional' implies the tool is safe to call without setup, which is useful context. However, it never says when to prefer this over day_pass_activate, day_pass_redeem, or pass_status, and no exclusions or prerequisites are stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds real value with 'AER-1 receipt, verifiable offline', but is silent on what happens when the audit_id is unknown or the audit is still running, and on whether the report is cached or regenerated.

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 deliverable and ending with the required argument. Slightly redundant to repeat the required-argument list that the schema already enforces.

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 and the description need not explain return values, so the main gap is operational: no guidance on the completed-audit prerequisite or the failure mode for an incomplete/invalid audit_id, which matters for a tool whose contract is 'completed' audits only.

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

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

Schema description coverage is 100%, so every parameter including the optional underscore-prefixed continuity fields is already documented. The description only restates that audit_id is required, adding nothing 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+resource ('Full markdown report for a completed Ghost Audit') and enumerates the payload (website score, severity-ranked findings, stage analysis, fixes). It does not distinguish itself from the sibling ghost_audit_status, which an agent could easily confuse with it.

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 'completed Ghost Audit' implies the prerequisite that the audit must already be finished, but there is no explicit 'use this when X, use ghost_audit_status when Y' routing. The agent must infer the sequencing from the sibling names alone.

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 destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is carried by structured data. The description adds genuinely new context — an AER-1 receipt verifiable offline plus live-stream and report URLs — but does not explain the destructive/credit-consuming behavior the annotations imply, nor whether the call is long-running and should be polled.

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 lead sentence wastes words on a tautology ("website audit for a website") and the bulk of the text is a long enumeration of return values that the output schema already covers. The useful scoping detail (required argument, receipt verifiability) is buried at the tail.

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, the return-value list is largely redundant, and what an agent actually needs is missing: how this relates to ghost_audit_status/ghost_audit_report, whether the audit is asynchronous, and what the destructiveHint implies. Adequate but with clear gaps for an 8-parameter, open-world 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% and every parameter, including all optional continuity/pass fields, is fully documented in the schema. The description only echoes that url is required, adding nothing about the seven optional fields (e.g., that email unlocks unlimited audits), 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 identifies the resource (a website audit) and enumerates what it produces, so an agent knows this is the audit-generation tool. The opening is circular ("website audit for a website") and it never names how it differs from the adjacent ghost_audit_report, ghost_audit_status, or provibe_audit 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?

There is no guidance on when to run an audit versus checking ghost_audit_status or fetching ghost_audit_report, and no mention of cost, credits, passes, or runtime. The only usage-adjacent line is "Required arguments: url," which is schema restatement, not routing 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add context — and it does: it discloses the state model (running vs complete), that elapsed-time data is returned, and that report availability is signalled, plus the 'AER-1 receipt, verifiable offline' trait. It does not mention the optional capability keys or any rate limits, which is the remaining gap.

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

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

Three short sentences, front-loaded with the purpose, then the return payload, then the receipt trait and required argument. Nothing is redundant with the annotations or schema beyond the minimal 'Required arguments' restatement.

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

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

An output schema exists, so return-shape detail is not required, and the description correctly spends its words on state semantics instead. What is missing is lifecycle context — whether completed audits expire, or how long the report stays retrievable — which matters for an open-world, idempotent status 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 100% and all seven parameters are documented in the schema, so the baseline of 3 applies. The description only restates that audit_id is required; it adds no semantics for the five optional continuity/capability parameters, which is acceptable given the schema does that work.

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 ('status report') and resource ('Ghost Audit identified by audit_id') and enumerates the returned fields: running/complete state, elapsed time, report availability. This implicitly separates it from ghost_audit_report (which fetches the report itself) and ghost_audit_site (which creates the audit), though neither sibling is named.

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 polling workflow is only implied: a status tool keyed on an audit_id returned elsewhere. The description never says to call this after ghost_audit_site, how often to poll, or when to switch to ghost_audit_report once the audit is complete. That linkage lives in the schema's audit_id property, not the description.

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

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

Annotations already declare a non-read-only, idempotent, non-destructive, open-world write, so the safety profile is covered. The description adds that the result is one proof link backed by an AER-1 receipt verifiable offline, which is real value. It omits consequential behavior for a publishing tool: the default visibility is public, dry_run exists as a preview path, redaction/shield defaults apply, and acceptance gating is not mentioned.

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

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

Four short sentences, front-loaded with the trigger conditions before the mode distinctions. Terminology like 'AER-1 receipt' is unglossed and the trailing 'verifiable offline' fragment is cryptic, but there is no filler.

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

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

An output schema exists, so return values need not be explained, and the schema documents every parameter. But for a 35-parameter publishing tool with open-world effects, the description never mentions the public-visibility default, the dry_run preview, or privacy controls — an agent could publish sensitive data without the description warning it off.

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% across all 35 parameters, so the schema carries parameter meaning and the baseline is 3. The description only adds semantics for continue_from ('chain off a job you picked up') and implicitly for session continuity; the other 34 parameters — redaction, visibility, payment, shield, dry_run — get no description-level framing.

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 handover) and two concrete modes: a resumable AI-to-AI handoff with the same session, and a client-facing proof link with verifiable receipts. An agent can distinguish the two output shapes without opening the schema. It stops short of naming sibling tools (handover_list, handover_status, handover_accept) to complete the routing picture.

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 literal user trigger phrases ('wrap up this session', 'continue in another AI', 'hand this over to <client>'), which is unusually concrete guidance, plus a condition for continue_from (chaining off a job picked up via handover_accept). It offers no exclusions and does not say when to prefer handover_list/status instead of creating 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?

Annotations already declare idempotentHint=true, destructiveHint=false and openWorldHint=true, so the description only needs to add context, and it does: it discloses the receipt side effect, the AER-1 offline-verifiable receipt, and the important guardrail that agent pickup is not client approval and that no client tokens should be generated. It stops short of saying whether the handover is locked to this agent after pickup or what happens on a repeat call.

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

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

Four short sentences, front-loaded with the action and return payload, then the guardrail, then the receipt artifact. Nothing is padded, though the 'Do not generate client tokens' rule is stated without saying what to do instead, which slightly weakens its economy.

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

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

An output schema exists, so return values need no elaboration, and the mutation guardrails plus receipt semantics are covered. The remaining gap is operational: with 11 all-optional parameters, the description should state that a handover_id or resume_code (and which credential) is effectively mandatory for a successful pickup.

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% across all 11 parameters, so the baseline is 3. The description only reinforces the handover_id/resume_code lookup path and never touches the credential parameters (token, client_token, _zambo_key, _session_id) or clarifies that at least one identifier must be supplied despite zero required 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?

The description uses a specific verb ('Accepts and picks up') on a specific resource ('a handover by ID or resume code') and states the two outputs (saved state plus private continuation thread) and the side effect (records a receipt). It distinguishes itself implicitly from handover_status/handover_list by the pickup action, but never names those siblings to make the boundary explicit.

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

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

The context is implied — you call this when you have a handover ID or resume code and want to take it over. There is no explicit statement of when to prefer handover_status, handover_list, or continuity_open_thread instead, and no prerequisites (e.g., which credential is needed for which access path) beyond the negative rule about not minting client tokens.

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, and destructiveHint=false. The description adds useful behavioral context: it returns real statuses, client-ready links, and an AER-1 receipt verifiable offline, which goes 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?

The description is short and front-loads the core action and required argument. The phrase 'AER-1 receipt, verifiable offline' is slightly jargon-heavy but still compact and relevant.

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

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

An output schema exists, so the description need not explain return values in detail. It covers the key session prerequisite and mentions statuses, links, and receipt verification, leaving only minor gaps such as pagination behavior, which the schema already documents.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters, including _session_id and cursor. The description only restates that _session_id is required and does not add syntax or format details 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 description states a specific verb and resource: list Zambo Handovers. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as handover_status or handover_accept.

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 usage by requiring Zambo Pass and the same _session_id, which gives a prerequisite context. However, it does not say when to use this tool instead of handover_status or other handover-related siblings.

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 this a safe, idempotent, read-only operation, so the description is freed to add domain semantics — and it does: it distinguishes agent pickup from the separate client decision/release hint and explicitly warns that pickup alone does not authorize payment release, which preempts a costly misinterpretation of the returned status. Minor gap: no error/permission behavior and the trailing 'AER-1 receipt, verifiable offline' is unexplained jargon.

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 purpose and the lookup keys, then the most decision-relevant caveat. The only fat is the closing 'AER-1 receipt, verifiable offline', which is opaque to an agent without context and does little work.

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, full annotation coverage, and a 100%-documented schema, the description only needed to supply lookup modes and interpretive semantics — both are present. It falls short of 5 because it says nothing about failure modes (invalid/expired code) or about the optional continuity/key parameters an agent must decide whether to supply.

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 all 8 parameters are already described, including the note that resume_code is for when an ID is unavailable. The description echoes the ID/resume-code alternation but adds nothing about the six underscore-prefixed metadata parameters (ref, zambo_key, session_id, caller label/handle, continuity label).

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 combination (checks a handover) and names both lookup keys (ID or resume code) plus what the response covers (pickup status, client decision/release hint). It is clearly a read of a single handover rather than a list or mutation, though it never names the neighboring handover/handover_list/handover_accept tools to remove remaining ambiguity.

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 lookup modes imply usage ('by ID or resume code'), but there is no explicit when-to-use guidance, no statement of when to prefer handover_list or handover instead, and no mention of fallback behavior when neither key is known beyond what the schema already says.

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 annotations: it discloses the trust model (an agent-reported claim, not an observation), the append-only nature, the free-tier limit of 20 calls per IP per day, and that an AER-1 receipt verifiable offline is issued. Annotations only declare non-read-only, open-world, non-destructive, non-idempotent; the description explains the semantics behind those hints.

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 tight sentences, front-loaded with what the tool is and what it records, followed by limits and the receipt guarantee. The final sentence listing required arguments is largely redundant with the schema's required array but is short enough not to hurt.

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, so return values need no explanation, and the description covers the remaining gaps an agent needs: authentication optionality, rate limits, append-only write semantics, and the evidentiary claim it produces. Nothing essential for a correct call is missing.

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

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

Schema coverage is 100%, so the schema already documents all 16 properties including redaction behavior for inputs and metadata. The description only restates the three required argument names, adding no meaning beyond the schema's own required list and 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 ('append-only log') and constrains scope to actions performed outside Zambo, which separates it from internal persistence tools. It does not explicitly name any sibling such as memory_remember or continuity_open_thread, so the differentiation is inferred from the 'outside Zambo' phrasing 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?

'For an action performed outside Zambo' is an explicit usage condition that tells the agent when this tool applies versus internal tools. No when-not-to-use conditions or named alternatives are given, leaving the agent to infer that internal actions go elsewhere.

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, openWorldHint, destructiveHint=false, so safety is covered. The description adds a real behavioral trait — 'AER-1 receipt, verifiable offline' — but leaves the term unexplained and does not address the idempotentHint=false implication (repeat calls may yield different results) or any cost/quota 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?

Four short sentences, front-loaded with what the tool does and what it returns before the argument reminder. The closing 'Required arguments: trade, city' is mildly redundant with the schema but is a cheap, useful call-site reminder 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?

An output schema exists, so return-value explanation is unnecessary, and the six optional params are fully covered by schema descriptions. What remains thin is the operational context — whether the tool consumes a pass or credit and what 'qualified' means — but for a read-only lookup this is close to 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 all eight parameters, including the optional plumbing params, are already documented. The description only restates the two required arguments and adds no format guidance (e.g., state handling, trade normalization) beyond what the schema examples give. 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 chain: accepts a trade and city, returns qualified local leads with contact info. Together with the target audience ('contractors and local service businesses') an agent can tell what it produces. No sibling covers lead generation, so explicit differentiation isn't required, but the description never says so.

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?

Audience framing ('contractors and local service businesses') implies the use case, and the required arguments are spelled out. There is no explicit when-to-use vs when-not guidance, no mention of alternatives among the many siblings, and no preconditions (e.g., whether a Day Pass or _zambo_key is needed to get real leads).

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 fallback resolution order, that cached values are returned with their age when live providers fail, and that an offline-verifiable AER-1 receipt accompanies the result. That is exactly the behavioral context an agent needs to interpret freshness.

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 followed by the fallback chain, with no wasted words. The trailing 'AER-1 receipt, verifiable offline' fragment is slightly terse/jargon-heavy but still carries useful 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 an output schema present, return-value detail is optional, and the description still names the key fields (USD price, 24h change, market cap). It is essentially complete for a zero-required-parameter lookup, though it could clarify the symbol-vs-coin alias relationship relied on by callers.

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 symbol/coin alias and the optional metadata fields (_ref, _zambo_key, _session_id, etc.) are already documented. The description adds nothing about which parameters drive the lookup, 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 and resource ('Real-time cryptocurrency price lookup for supported coins') and enumerates provider sources. No sibling tool covers price lookups, and the description makes the tool's domain unmistakable at a glance.

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?

Explains the provider priority chain (CoinGecko, then Coinbase, then cached value with age), which tells the agent when results may be stale. It does not explicitly state when to prefer an alternative or what to do if all sources fail, but no sibling performs this function.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context beyond them: reads consume 'the shared daily work-call allowance' (a quota concern the agent must budget for) and returns 'An AER-1 receipt, verifiable offline' (an artifact with verification properties). It does not describe pagination or result-set limits, which keeps it from a 5.

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

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

Two tight sentences with no filler, and the core capability is front-loaded before the quota and receipt details. The 'AER-1 receipt, verifiable offline' clause is terse to the point of being cryptic to an uninitiated agent, but 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?

An output schema exists and annotations are rich, so the description need not explain return values, and it correctly avoids doing so. The meaningful gap is the all-optional 8-parameter surface: the description never explains the default retrieval behavior when no code, handle, or query is given, which is the most likely misfire for an agent calling 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 description coverage is 100%, so every parameter is already documented in the schema, establishing a baseline of 3. The description adds selection semantics for the two main identifiers (handle vs. code) and confirms the query is a filter, but says nothing about the underscore-prefixed continuity, session, or referral parameters that the agent must still reason about.

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 and resource ('Read private saved facts') and names two access paths (caller handle or explicit memory code) plus an optional query filter. It clearly distinguishes itself from the write-side counterpart memory_remember by framing the operation as a read, though it never names that sibling.

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 usage by stating facts can be read 'by caller handle or explicit memory code,' which hints at two retrieval modes, and notes the query is optional. However, it gives no explicit when-to-use/when-not guidance, no mention of memory_remember as the alternative, and no indication of what happens if no handle, code, or query is supplied despite zero required parameters.

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 annotations by disclosing a consumable resource ('shared daily work-call allowance'), a gating condition ('respects Memory capture settings'), the secret-handling obligation on the returned code, and a verifiable AER-1 receipt. With readOnlyHint=false and destructiveHint=false already declared, this adds genuinely new operational context; only the non-idempotent behavior (repeated saves) is left unaddressed.

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

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

Four short sentences, front-loaded with the action and the returned artifact, with the security caveat immediately attached. The trailing 'AER-1 receipt, verifiable offline' is unexplained jargon but brief enough not to obstruct.

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 mutation tool with an output schema (so return values need no explanation), the description covers cost, consent gating, secret handling, and receipt generation. The main residual gap is whether supplying an existing 'code' versus omitting it changes the outcome, which is only implicit 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%, so all nine parameters are already documented, including the optional 'code' for appending to an existing memory. The description only restates the two required arguments (_session_id, fact), adding no semantics beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource ('Save a private fact for this work connection') and adds the outcome ('Returns a private memory code for cross-session pickup'), which clearly separates it from the retrieval sibling memory_recall. It stops short of naming that sibling explicitly, so differentiation is implied rather than stated.

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

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

The phrase 'for cross-session pickup' implicitly conveys when this tool is useful, and the quota note warns about cost, but there is no explicit when-to-use/when-not guidance and no reference to memory_recall as the read-side alternative. An agent must infer the 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?

The description adds real context beyond the annotations: a fresh context is created, the returned ID governs continuity, and an offline-verifiable AER-1 receipt is produced. However, it never says what that receipt is, where it is returned, or whether authentication (_zambo_key) is needed, and it leaves slight tension with readOnlyHint=true for an operation that mints new 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?

The first two sentences are front-loaded and earn their place. The dangling boilerplate 'Required arguments: .' is malformed and wasted, and the dangling period makes the call site look broken.

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 an output schema, so return values need not be explained, and the description covers purpose, ID reuse semantics and the receipt artifact. It is adequate for a zero-required-parameter session bootstrap 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 all six optional parameters are already documented, which sets the baseline at 3. The description's only parameter-adjacent statement is about the returned session_id, and it does not clarify the distinction between the returned ID and the optional _session_id input, which the schema describes as a stable bot-job 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?

States a specific verb and resource ('Starts fresh session context') plus the concrete return value ('returns a new session_id'), so the agent knows exactly what the call produces. It does not differentiate itself from continuity-related siblings like continuity_start_thread or zambo_home, 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?

'Reuse that ID on subsequent calls for continuity; changing or omitting it starts clean context' gives clear guidance on how to use the result and what happens if you omit it. It does not name an alternative tool or state when this should be used instead of the continuity/handover siblings.

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