Zambo AI Tools

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely non-structured behavior: the ledger is private and receipt-backed (audit trail implied) and calls are free and exempt from the daily allowance — quota/billing context an agent cannot get from the annotations. It stops short of describing the link's lifetime or any access constraints.

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

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

Two short sentences with zero filler, leading with the action and following with the cost/no-allowance fact that most affects the decision to call it. Nothing could be removed without losing meaning.

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 explanation is unnecessary, and all 8 optional parameters are described in the schema. The remaining gap is that "Today link" is never unpacked and the relationship between the ledger, the continuity parameters, and the returned link is left to the output schema — minor for a read-only, zero-required-parameter tool.

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

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

All 8 parameters are fully documented in the schema (100% coverage), including optionality, formats, defaults, and security notes such as not placing _zambo_key in a URL. The description contributes nothing about parameters, which is acceptable given the schema does the work — 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 ("Read") and resource ("the private, receipt-backed work ledger for this job") and states the result shape ("return its Today link"). It does not distinguish itself from plausible siblings such as continuity_get_recent or journal_log, and "Today link" is somewhat proprietary phrasing, but the core action 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?

The line "Always free and does not use the daily call allowance" is a useful green light for liberal use, effectively a cost-based usage cue. However, nothing states when this tool should be preferred over the ledger/continuity siblings or when it should not be used, so the guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description still adds genuine value beyond that: it discloses the return shape (relevance scores, descriptions, taglines, callable endpoints) and the special referral behavior (invite-link tool, 2,000-call reward).

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 purpose, followed by return content and a targeted referral special case. Each sentence carries information, though the referral detail is narrow enough to feel slightly tangential in the top-level 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?

An output schema exists, so return values needn't be fully re-explained, and annotations cover the safety profile. The description completes the picture with purpose, result content, and the referral edge case, making it adequate for a 10-parameter read-only search 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% with all 10 parameters documented in the schema itself, setting the baseline at 3. The description adds no syntax or semantics for the alias parameters or the referral/continuity fields 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 (search) and resource (Zambo tool catalog) with a clear use-case scope, plus what the results contain. It does not explicitly distinguish itself from discovery-oriented siblings like zambo_universal or zambo_home, which is the only gap.

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 a use case' implies when to reach for it, and the referral sentence hints at a specific scenario. But there are no explicit when-not conditions or named alternatives among the many sibling tools, leaving usage selection partly inferential.

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, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by stating that the timeline is private, returning receipt links, has_more, and a cursor, and warning that AI client labels are self-reported rather than verified.

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-loaded: it states the read scope first, then return fields and pagination, then relevant filtering and trust caveats. It is efficient overall, though the AI-label caveat is somewhat duplicative of the schema.

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

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

Given an output schema and rich annotations, the description supplies enough context for correct invocation: what timeline is read, what pagination fields come back, how since works, and that AI labels are unverified. It is only missing explicit routing guidance versus sibling tools, which is captured under usage guidelines rather than core completeness.

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 twelve parameters are already documented, including since, cursor, limit, and the AI label caveat. The description repeats the inclusive RFC3339 meaning of since and the self-reported nature of AI labels, but adds no parameter meaning beyond what the schema provides; 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 uses a specific verb and resource: it reads the private receipt timeline for a supplied job or thread ID. That is clear enough to distinguish it as a recent-continuity read tool, though it does not explicitly name continuity_list_threads or another sibling as the alternative.

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 mentions using since for timestamp filtering, but it gives no explicit guidance on when to choose this tool over continuity_list_threads or other continuity tools. There are also no stated prerequisites or exclusions, so the agent must infer tool selection from the name and resource scope.

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 adds the useful downstream note that returned thread IDs are valid as _session_id for another client, but says nothing about scope when parameters are omitted or about auth/capability requirements.

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

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

Two short sentences, the core operation front-loaded and the downstream value second. There is no filler or restatement of the title.

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

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

An output schema exists and annotations cover safety, so return values need not be explained. The remaining gap is meaningful: the description says threads are 'owned by the supplied job ID' while all 7 parameters are optional, leaving the agent unsure what the listing scope is when no job ID is passed, or whether results are paginated.

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 every one of the 7 parameters is documented in the schema, which sets the baseline at 3. The description reinforces the relationship between the 'job ID' and the thread IDs used as _session_id, but it does not clarify the session_id/_session_id alias or the role of the optional caller/capability parameters.

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

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

States a specific verb and resource ('Lists named threads') plus the ownership scope ('owned by the supplied job ID'), so the operation is unambiguous. It does not differentiate itself from adjacent siblings such as continuity_get_recent, continuity_start_thread, or continuity_open_thread, which is what keeps it from 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?

The second sentence implies the intended workflow — retrieve thread IDs, then use them as _session_id from another AI client — which is real usage context. However, it never says when to call this versus continuity_get_recent or continuity_start_thread, and it never states what happens when no job ID is supplied.

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 that this is a read-only, idempotent, non-destructive, open-world operation. The description adds useful behavioral detail beyond that: it returns only events with stored receipts, rather than all thread events, and includes links for opening and checking each receipt. It does not explain auth/capability implications, but the annotations lower the burden.

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

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

The description is a single compact sentence that front-loads the action and then states the return behavior. It is appropriately sized, though the phrase 'opens a named thread or thread ID' is slightly ambiguous and could be sharper.

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 a full output schema, complete parameter descriptions, and rich annotations, the description does not need to explain return values or safety traits. It adequately covers the core read behavior and receipt filtering, with the main remaining gap being the relationship to sibling thread-management 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 description coverage is 100%, so the schema already documents all ten optional parameters in detail. The description mentions the name/thread-ID distinction, which mildly reinforces parameter meaning, but adds no meaningful syntax or constraints beyond the schema baseline.

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

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

The description states a specific verb and resource — opening a named thread or thread ID and returning matching receipt-bearing events. It is clear what the tool does overall, but it does not explicitly distinguish itself from siblings such as continuity_start_thread, continuity_list_threads, or continuity_get_recent.

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 when to use it — to retrieve events from a thread that have stored Zambo receipts — but gives no explicit when-not guidance or named alternatives. An agent must infer the boundary between opening/accessing a thread here versus starting or listing threads with sibling 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 readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context that annotations cannot express: the setting is forward-looking only and leaves already-created public receipts untouched. It still omits whether the change is scoped per-AI/thread/timezone or what happens when no parameters 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?

Two short sentences, front-loaded with the effect and followed by the one caveat that matters. Nothing is wasted and no sentence 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?

An output schema exists and parameter docs are complete, which lowers the burden. Still, for a 12-parameter preference tool with zero required fields, the description should at least signal that other preferences (daily recap, timezone, thread/AI scoping) are also settable and that omitting all of them is meaningful. As written it reads like a single-boolean toggle.

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 every one of the 12 parameters carries its own documentation, so the schema does the heavy lifting. The description only implicitly maps to capture_enabled and says nothing about daily_recap, timezone, or the scoping parameters, so it neither adds nor subtracts meaning.

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

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

The description states a concrete effect on a concrete resource: it toggles whether future successful calls land in the private timeline. That is specific enough to distinguish it from read-only siblings like continuity_get_recent. However, the tool is named 'set_prefs' and its schema includes daily_recap, timezone, thread_id and ai_label scoping, none of which the description acknowledges, so the stated purpose is narrower than the tool's actual surface.

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 when-to-use guidance, no prerequisites, and no mention of alternatives among the many continuity_* siblings. Only the effect boundary ('does not remove or hide public receipts') hints at what the tool is and is not for.

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=false, openWorldHint=true, idempotentHint=true and destructiveHint=true; the description's 'creates or reuses' corroborates idempotency. It never explains the destructive side — e.g. whether reusing an existing name overwrites or merges prior thread content — and says nothing about the _zambo_key/_caller_handle capability material. No contradiction with 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 short sentences, front-loaded with the action (creates or reuses) and then the continuation workflow. No filler or redundancy; 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?

An output schema exists, so return values need not be explained, and parameter documentation is fully covered. But for a tool flagged destructive and openWorld, the description leaves out the prerequisites for obtaining an existing job ID and the meaning of the destructive flag, which an agent needs before calling 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?

Schema coverage is 100% across all 8 parameters, so the schema carries the documentation burden and baseline 3 applies. The description adds only the 'required: name' restatement plus the thread_id-to-_session_id linkage, the latter being a useful cross-parameter hint not in 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: creates or reuses a named thread scoped to an existing job ID. The create-or-reuse framing is informative, but it does not distinguish this from siblings such as continuity_open_thread or continuity_list_threads, which an agent may 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 one concrete operational instruction — pass the returned thread_id as _session_id to continue work from another AI client — which implies usage context. However, it never says when to choose this over continuity_open_thread or continuity_list_threads, nor what prerequisites 'existing job ID' entails.

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, open-world, and non-destructive behavior, so safety is covered. The description adds only that the index is 'live' and 'verified' and lists return fields already documented by the output schema; it does not address freshness cadence, result limits, or pagination.

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 with the core resource front-loaded before filters and returns. No filler, though it is brief enough that it leaves real gaps rather than trimming excess.

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 a full output schema and 100% schema coverage the description needn't explain return values or most parameters, so it is nearly complete. The notable omission is any mention of the _ref referral ID or the continuity/session parameters, which carry meaningful semantics an agent might want surfaced.

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 including stack, stage, and min_value are already documented. The description merely reiterates those three filter names and adds no syntax or semantics beyond the schema, which is the baseline for full coverage.

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 live verified index of AI/cloud startup credit programs, and names the filters it accepts. The purpose is clear enough to distinguish it from unrelated siblings like live_price or leadsignal, though it doesn't explicitly contrast with any one alternative.

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 you call it to look up credit programs and can narrow with stack/stage/min_value, but it gives no explicit when-to-use/when-not or alternative routing. Usage is inferable but not spelled out.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true. The description adds useful behavior beyond that by explaining the payment-gated activation flow and the challenge-vs-result response modes, but it does not clarify what is consumed or destroyed by activation, whether the spend is immediate, or how irreversible the operation is.

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

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

The description is front-loaded and reasonably efficient: purpose first, then input modes, then output/result context. Some phrases like 'Agent-native' and the result list are less essential, especially since an output schema exists, but the prose remains compact and readable.

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?

It covers the core payment challenge to verified activation flow, and the existence of an output schema reduces the need to explain return values in detail. Still, for a 10-parameter destructive activation tool, it leaves sibling selection and the roles of optional session/workflow/sponsor parameters largely to the schema or inference.

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 conceptually maps 'payment envelope' to x_payment and 'existing access key' to _zambo_key, but it does not add meaning for the other optional parameters such as session_id, workflow_id, sponsor, _ref, or caller 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 states that this tool activates Day Pass/access and describes the accept/return modes: payment envelope or access key in, payment challenge or activation result out. However, 'Agent-native access activation endpoint' is somewhat jargon-heavy and it never names day_pass_redeem, day_pass_checkout_link, or day_pass_status, so sibling differentiation is left implicit.

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 important prerequisite, 'Activation occurs only after a verified transfer,' and implies usage when an agent has a payment envelope or existing access key. But it does not explicitly say when to use this versus day_pass_redeem, day_pass_checkout_link, or day_pass_status, 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 declare readOnlyHint=false but destructiveHint=false and idempotentHint=true; the description adds meaningful context beyond that by explaining that link creation is side-effect-free with respect to money and that charging only occurs at checkout completion. The sponsor clause also warns that sponsoring 'never transfers branding ownership,' a real behavioral constraint. Minor gap: no note on link expiry or how many times a link can be reused.

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 sentences are dense and front-loaded, but the definition ends with a dangling artifact, 'Required arguments: .', which is an empty list left over from templating and conveys nothing. Since no parameters are required, that fragment is both wasted and mildly confusing.

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 annotations cover the safety profile. What is missing for an 11-parameter, open-world, payment-adjacent tool is guidance on which of the many optional parameters (session_id vs _session_id vs _caller_handle vs _zambo_key) matter in which scenario, and how this step sequences against the other day_pass_* 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%, so every one of the 11 parameters is already documented in the schema. The description's notes on workflow_id ('targets a closed run') and sponsor:true largely restate what the schema descriptions already say, adding little new meaning. Baseline 3 applies when the schema carries the load.

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 with concrete terms: 'Get a checkout link for the $0.99, 24-hour Day Pass by card or PayPal.' Price, duration, and payment rails make the purpose unmistakable. It does not, however, distinguish itself from siblings like day_pass_activate, day_pass_redeem, or day_pass_status, so an agent must infer the routing.

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 situational context ('including in a fresh session') and clarifies the payment lifecycle ('Creating the link never charges anyone; payment requires completing checkout'), which implies this is the pre-payment step. But it never explicitly says when to use this instead of day_pass_activate or day_pass_redeem, leaving the workflow ordering 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?

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds two genuinely useful facts beyond that: no headers/auth plumbing are required, and the link expires with the original pass. It still doesn't say what redemption returns or what happens on an expired or already-redeemed link, which matters for a call whose name implies a state change.

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 declarative sentences with no filler, and the core action is front-loaded. It is arguably too terse for the tool's complexity, but 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?

An output schema exists, so return values need no explanation, and the schema documents all 10 parameters. What's missing is the operational context: the relationship to day_pass_activate/day_pass_status, and the failure/expiry behavior of redemption, which is the main risk an agent needs to know.

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 every parameter (token, url, unlock_link, token_or_link, _session_id, _zambo_key, etc.) carries its own description, so the schema does the work. The description only gestures at 'your private Day Pass link' and adds no alias or precedence guidance (e.g., that token/url/unlock_link are all aliases of token_or_link).

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 the verb 'unlock' (redeem) and the resource 'Day Pass link', so the general intent is graspable. But it never distinguishes redemption from the sibling tools day_pass_activate, day_pass_status, and day_pass_checkout_link, so an agent cannot tell from the text which one actually grants access versus activates or checks.

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?

'Unlock this AI with your private Day Pass link' implies a precondition (you have a private link) but gives no explicit when-to-use / when-not-to-use rules and never names the alternatives it competes with. An agent arriving with a token but no guidance on activate-vs-redeem is left to guess.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety floor is covered. The description still earns credit by adding that the call consumes no quota, that provider/product limits may still apply, and what the response surface looks like — real context beyond the structured fields.

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 no-quota guarantee are front-loaded in the first and third sentences. The closing line about provider limits is a useful caveat rather than filler, though the enumerated return fields duplicate the output schema 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, annotations fully cover the read-only safety profile, and all ten parameters are documented in the schema, so the description only needs to add operating context — which it does via the no-quota and provider-limit notes. Nothing an agent needs in order 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%, so each of the ten parameters is already documented, establishing a baseline of 3. The description names only four (session, token_or_link, thread_id, _zambo_key) and adds the useful fact that all are optional, but it explains no syntax or precedence rules 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 clear verb and resource ('Check your current pass') and names the alias sibling pass_status, which helps an agent map two names to one capability. It does not explicitly contrast with day_pass_activate, day_pass_checkout_link, or day_pass_redeem, so the boundary against the other pass tools 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?

The phrase 'without spending quota' implies this is the safe, non-consuming way to inspect a pass versus the activate/checkout/redeem siblings, but that comparison is never made explicit. There is no statement of when not to use it or what to do if no pass exists.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds useful context beyond them by specifying the output medium (markdown) and the report's sections, which tells the agent what it will receive.

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 what the tool produces, then the argument requirement. No waste or hedging.

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 spelled out, and the description still covers the prerequisite (completed audit) and the required input. Only the sibling relationship to ghost_audit_site/ghost_audit_status is 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 coverage is 100%, so all seven parameters are already documented in-schema. The description only restates the single required argument ('Required arguments: audit_id') and adds nothing about the optional continuity/referral parameters.

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

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

Names a specific verb+resource ('Full markdown report for a completed Ghost Audit') and enumerates what the report contains: score, severity-ranked findings, stage analysis, fixes. It implicitly separates itself from ghost_audit_site by requiring a completed audit, but never names that sibling 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?

'for a completed Ghost Audit' implies a precondition (the audit must be finished), and the schema note says audit_id comes from ghost_audit_site. There is no explicit when-to-use/when-not guidance or pointer to ghost_audit_status for polling.

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 destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the agent knows this is a non-repeatable, consequential call — yet the description never says what is consumed (credits/Pass balance) or why it is destructive. Mentioning an audit ID, live stream URL and report URL hints at an asynchronous pipeline, but the polling/fetch workflow and runtime are never explained.

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 output enumeration is informative but consumes the bulk of the text despite an output schema existing, while the leading sentence wastes words on 'website audit for a website'. The most useful fact for an agent (cost/async nature) never appears, so length is not well allocated.

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, listing return fields is redundant; the description instead omits what an agent actually needs — that this is a credit-consuming, non-idempotent, asynchronous audit whose results are retrieved via ghost_audit_status/ghost_audit_report. For a destructive, 8-parameter tool, that is a meaningful completeness gap.

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 url format and every optional continuity/auth parameter are already documented in the schema; the description's 'Required arguments: url' adds nothing. Baseline 3 applies since the schema carries the parameter burden entirely.

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 first sentence ('website audit for a website') is near-tautological, but the enumeration of what the audit produces (SEO gaps, AI discoverability, conversion leaks, competitor intelligence, score) makes the tool's scope concrete. It does not, however, distinguish this tool from its siblings ghost_audit_status and ghost_audit_report, which the agent must infer start/poll/fetch roles for.

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: nothing says whether this must be called before ghost_audit_status or ghost_audit_report, no prerequisites (valid public URL, credits/Pass), and no exclusions. 'Required arguments: url' merely restates the schema rather than clarifying invocation context.

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, so the safety profile is covered. The description adds that the call reports a running/complete state plus elapsed-time info, which helps an agent decide whether to poll again, but says nothing about expired/invalid audit_ids, retention, or rate limits.

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

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

Three short sentences, front-loaded with the purpose and return content. Slight redundancy in the trailing 'Required arguments: audit_id' sentence, which merely restates the schema's required array, keeps it from a 5.

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

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

The tool is a simple read-and-report call with an output schema present and full parameter documentation, so the description needn't explain return structure or the optional continuity fields. It covers the one thing an agent must know — what state the audit is in and how to reference 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?

Schema coverage is 100% and every parameter (including the optional continuity/telemetry fields) is documented in the schema. The description only restates that audit_id is required and does not add semantics beyond the schema's own 'audit_id returned by ghost_audit_site' note. 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 ('Status report for a Ghost Audit'), keyed by audit_id, and enumerates what it returns (running vs complete, elapsed time, report availability). This distinguishes it reasonably from ghost_audit_site (which produces the audit_id) and ghost_audit_report (which it says becomes available), though it never names those siblings outright.

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/status-check use case is implied by 'Returns whether the audit is running or complete,' and the audit_id provenance ('returned by ghost_audit_site') is stated in the schema. But the description offers no explicit when-to-use or when-not-to-use guidance relative to ghost_audit_report, and no hint about polling frequency.

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=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), and the description adds the important 'one proof link with verifiable receipts' framing plus the chaining rule. However, it never discloses that the artifact is published with visibility defaulting to 'public', that shield/redaction run by default, or that acknowledge_warnings gates publication despite warnings — material behavior for a publishing tool with 35 parameters.

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, trigger phrases front-loaded, and each sentence adds a distinct fact (triggers, AI-switch mode, client-delivery mode, chaining). Zero 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?

Even granting the output schema covers return values, this is a 35-parameter, nested, publication-producing tool with a public-by-default artifact, and the description explains none of that machinery — no mention of redaction defaults, payment fields, dry_run, or how 'AI switch' vs 'client delivery' is expressed in parameters. Adequate as a trigger router, inadequate as a definition for the tool's actual surface.

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 only 37% across 35 parameters, so the description must compensate — it does not. It explains only continue_from; the complex surface (redact modes, shield, payment/x402, dry_run, visibility, deliverables, acknowledge_warnings) is left entirely to a partially documented schema, leaving an agent to infer how the two advertised modes are actually selected via parameters.

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

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

The description concretely states the two things this tool produces: a resumable session handoff for AI switching, and a single proof link with verifiable receipts for client delivery. That is specific enough to distinguish it from siblings like handover_accept or handover_status, though it never states a plain verb+resource (e.g. 'create a handover') and the name 'handover' carries much of the load.

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?

Strong trigger-based routing: 'wrap up this session', 'continue in another AI', 'hand this over to <client>' map directly onto the two operating modes, and 'Pass continue_from to chain off a job you picked up' tells the agent how to continue an accepted handover. Missing only explicit exclusions (when to use handover_status/handover_list instead).

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=false but destructiveHint=false and idempotentHint=true; the description adds real context on top: acceptance/receipt side effects, the recipient-only eligibility rule, creator-authority rejection, access-token requirement for private handovers, and that calls are free with no quota. It stops short of covering repeat/invalid-handover 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 dense, front-loaded sentences with the core action first and the conditional caveats after. The closing 'Required arguments: handover_id' is redundant with the schema's required list, a small wasted line.

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 explanation; the description instead covers the side-effect and authorization model, which is the right allocation. Error paths (unreadable, expired, or already-accepted handovers) are not addressed.

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 70%, so most parameters are already documented in the schema, and the description mainly restates that handover_id is required. It does add that private handovers need their access token and ties token/client_token to the acceptance semantics, but leaves the underscore-prefixed continuity parameters unexplained.

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 concrete verb and resource: pick up handed-over work and retrieve its private continuation thread. The conditional acceptance semantics further sharpen what the call does. It is distinguishable from handover_list/handover_status by implication, but no sibling is named 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?

Gives explicit when-conditions (recipient_type agent plus client token records acceptance) and when-not (otherwise the client decision stays pending), plus a hard exclusion (creator authority is rejected). It never routes to an alternative sibling such as handover_status or handover_list, 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description does add a genuine auth requirement ('using Zambo Pass') and the 'same _session_id' binding constraint, but 'returns real statuses and client-ready links' is largely redundant with the existing output schema.

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

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

Three short sentences, front-loaded with the action and resource, then the auth/session prerequisite. No wasted preamble, though the final 'Required arguments' sentence largely duplicates what the schema's required array already declares.

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 7 parameters, an output schema, and full annotations, the structured data does most of the work. The description is adequate but leaves gaps on pagination (cursor) and on how this differs from the other handover_* tools, which matters given five similarly named 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 description coverage is 86%, so the schema already carries parameter meaning and the baseline is 3. The description only restates that _session_id is required and adds no insight into cursor, _ref, _zambo_key, or the caller/continuity 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 pairs a specific verb ('List') with a specific resource ('Zambo Handovers'), so the operation is unambiguous. It does not distinguish itself from close siblings like handover, handover_status, or handover_accept, which is the only thing keeping it from 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?

'using Zambo Pass and the same _session_id' implies a prerequisite and a reuse pattern, but it never states when to call this versus handover_status or handover. Usage is inferred rather than spelled out.

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

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

Beyond annotations, it discloses that the call does not spend execution quota, explains the payment-release implication of an accepted status, and states 'Zambo never holds funds.' These are meaningful behavioral and trust details not captured by readOnlyHint/idempotentHint alone.

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 status-check purpose is front-loaded in the first sentence, followed by payment guidance and session scoping. Most sentences earn their place, though 'Required arguments: handover_id' is partly redundant with the schema.

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

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

With rich annotations, an output schema, and high schema coverage, the description does enough: it explains the status/acceptance/release_hint outcome, the no-quota behavior, payment context, and private-delivery session requirement.

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 high at 86%, so the schema already carries most parameter meaning. The description adds only a small amount beyond schema, notably that the owning _session_id is needed for private deliveries and that handover_id is required, which is already structurally enforced.

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 precise verb and resource: 'Check a Zambo Handover's status, acceptance and release_hint.' It also makes the read-only status-check purpose distinct from sibling actions like handover_accept and handover_list, and names the specific fields returned.

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 usage context: 'Paying another agent? Check the handover first' and 'Release payment when status is accepted.' It does not explicitly name alternatives such as handover_list for listing or handover_accept for accepting, so it stops short of full when/when-not 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?

Goes well beyond the annotations: it discloses append-only immutability, that entries are unverified agent-reported claims, the free-tier rate limit of 20 calls per IP per day, and the anonymous-or-authenticated access model. These are exactly the traits an agent needs before deciding to log.

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, then trust semantics, then a hard limit. The trailing sentence listing required arguments largely duplicates the schema's required array, making it the weakest line.

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 covering the receipt and full annotation coverage, the description supplies what structured fields cannot: the unverified-claim framing and the rate limit. Nothing essential to calling this 16-parameter tool correctly is missing.

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

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

Schema coverage is 100%, so all 16 parameters including nested objects are already documented in-schema. The description only restates the three required arguments, adding no syntax, format, or interaction detail (e.g., how redacted_inputs_hash relates to inputs).

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

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

States a specific verb and resource: an append-only journal log for actions performed outside Zambo. The 'outside Zambo' scoping distinguishes it from internal-recording siblings like memory_remember or workflow_seal, though it never names an alternative explicitly.

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

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

The phrase 'for an action performed outside Zambo' implies the trigger condition, and the rate limit hints at call budgeting. However, no sibling is named and there is no statement of when NOT to use it (e.g., internal Zambo actions, or duplicate logging on retry).

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, destructiveHint=false, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The description adds that it returns qualified local leads with available contact information, but it omits operational context around the optional _zambo_key, _session_id, and continuity parameters, and gives no detail on rate limits or what 'qualified' means. This is useful but not rich behavioral 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 description is short and front-loads the core purpose before inputs and outputs. It is slightly redundant in saying both 'Accepts a trade type and city' and 'Required arguments: trade, city,' which prevents a perfect score, but otherwise every sentence is useful.

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 in detail. However, for a tool with eight parameters and several optional session/continuity arguments, the description does not address when to use the tool or how the optional operational parameters fit into a workflow. It is adequate for basic invocation but incomplete as agent guidance.

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 operational ones, are fully documented in the schema. The description only restates the required trade and city arguments, adding no meaning beyond what the schema already provides. Baseline 3 is appropriate given complete schema coverage.

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: generating qualified local leads for contractors and local service businesses, parameterized by trade and city. It clearly communicates what the tool does, but it does not differentiate itself from any sibling tools such as handover or zambo_home.

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 says it accepts trade and city and lists them as required, which implies usage, but it gives no explicit guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites. It effectively leaves routing decisions to 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, openWorld, non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the CoinGecko -> Coinbase -> cache resolution order, and the fact that a cached result carries its age so the agent can judge staleness. It omits rate limits or failure modes when all three sources miss, 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?

Three sentences, front-loaded with purpose, then fallback behavior, then return shape — every sentence carries information. Slightly dense phrasing ('the most recent cached verified value with its age') costs it the top score 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 an output schema present, the description needn't enumerate return values, and safety is covered by annotations. It fills the remaining gap — data provenance and staleness — well, though it never clarifies the interplay between the two overlapping price inputs (symbol vs coin) or the continuity parameters for a tool that carries eight of them.

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 8 parameters — including the symbol/coin alias and the underscore-prefixed continuity fields — are already documented in the schema. The description adds no parameter-level detail (e.g. alias precedence between 'coin' and 'symbol'), 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 and resource ('Real-time cryptocurrency price lookup for supported coins') and enumerates exactly what is returned: USD price, 24h change, and market cap. No sibling tool competes for this capability, so differentiation is trivially satisfied and 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?

The description implies when to use it (you want a current price) and explains the provider fallback chain, which tells the agent what data quality to expect. It never explicitly states when not to use it or points to an alternative, but no sibling offers overlapping functionality, so guidance is only implied rather than spelled out.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world. The description adds genuinely new context: the data is private to this work connection and the call is free with no quota, which affects whether an agent should hesitate to call it repeatedly. It does not cover result ordering or volume, 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?

Three short sentences, front-loaded with the purpose and followed by the cost signal. 'Required arguments: _session_id' largely duplicates the schema's required array and is the weakest sentence, but overall there is little waste.

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 only needs to cover purpose, cost, and privacy — all of which it does. It stops short of describing pagination or result limits, a minor gap for a list-style read 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 86%, so the schema already documents all seven parameters in detail. The description only restates that _session_id is required and query is an optional match, adding essentially no syntax or semantic detail beyond 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?

The description states a specific verb (read) and resource (private saved facts) scoped to 'this work connection,' with an optional query filter. It implicitly pairs with the sibling memory_remember (read vs. write) but never names it, so the 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?

'optionally matching a query' hints at when the filter is useful, but there is no explicit guidance on when to call this versus memory_remember or continuity_get_recent, both of which surface stored context. Usage is implied rather than stated.

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

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds genuinely new context: facts are private per work connection, capture settings may affect saving, and calls are free with no quota. It omits duplicate-handling behavior despite idempotentHint=false, which an agent would want to know.

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 and scoping constraint. The 'Required arguments' sentence largely duplicates the schema's required list but is brief enough not to be costly.

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 explanation, and annotations cover mutability. However, with 8 parameters the description never explains the optional fields or how saved facts surface later via memory_recall, leaving an agent to infer the write/read lifecycle.

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 75%, so the schema already documents most parameters. The description only restates that _session_id and fact are required — information already in the required array — and adds nothing about what counts as a valid fact (500-char cap) or the role of optional fields like agent_name. 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 concrete verb and resource ('Save a private fact') plus the scope ('for this work connection'), which is more specific than the bare name. It does not explicitly name memory_recall as the retrieval counterpart, so sibling differentiation is left to inference from naming.

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?

'Respects Memory capture settings' hints at preconditions, but there is no explicit statement of when to use this versus memory_recall, when not to use it, or what capture settings actually gate. Usage is implied by the remember/recall pairing rather than 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, destructiveHint=false, idempotentHint=false and openWorld=true; the description correctly implies a non-idempotent minting operation ('returns a new session_id') with no destruction. It adds the continuity/reset semantics, which is useful, but leaves unexplained the tension between the returned session_id and the _session_id parameter, which the schema describes as a 'stable bot-job ID', a potentially confusing overlap.

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, but the trailing 'Required arguments: .' is a broken fragment with a dangling empty list, which reads as a template artifact and wastes the reader's attention.

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 need not be in the description, and all optional params are documented in schema. What is missing is routing guidance against the many continuity_*/handover siblings, plus the empty required-arguments clause that signals an unfinished definition.

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 six optional parameters are documented in the schema and the baseline is 3. The description adds nothing about any parameter, and its 'Required arguments: .' clause is an empty, malformed sentence that provides no information; it also fails to clarify how _session_id relates to the returned session_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') and says what it returns (a new session_id). That is enough to distinguish it from read/query siblings like continuity_get_recent, though it never names an alternative tool 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?

It gives real usage guidance for the returned ID ('Reuse that ID on subsequent calls for continuity; changing or omitting it starts clean context'), which tells the agent how to behave after the call. It never says when to call this instead of continuity_start_thread, handover, or zambo_home, so the selection decision against siblings is left implicit.

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