GrowthKit Revenue Intelligence

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

Annotations only declare readOnlyHint=true, but the description adds meaningful behavioral context: it returns counts only, not content, and offers an optional chapter filter. It signals the tool is safe for quick sizing checks, which goes beyond the annotation.

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 concise sentences each serve a purpose: stating what the tool returns, giving the typical use case, and directing users to a sibling tool when the requirement is different. There is no wasted wording.

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 takes only one optional parameter, has an output schema, and is low-risk (readOnly). The description clarifies the main behavioral distinction (counts vs content) and gives routing guidance, making it a complete, self-sufficient 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?

The schema already fully documents metadata_filter and explicitly mentions 'chapter' in its property description, so the description adds little beyond reinforcing that filtering by chapter is optional. With 100% schema coverage, score 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 states a specific verb+resource ('Return only counts, not content') and clearly differentiates from siblings like listMemories and searchMemory by emphasizing that it does not return content. It also distinguishes from getChapterOverview by its aggregation level.

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

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

It explicitly says use for overview/sizing before deciding whether to list or search, giving a concrete scenario ('how many competitor memories exist?'). It also names getChapterOverview as the preferred alternative for per-chapter breakdowns.

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 readOnlyHint annotation already establishes safety, and the description aligns with that. It adds that the output includes briefing details and lead-stage counts, but nothing else about behavior like auth or error handling. No contradiction exists.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently captures the tool's purpose and output.

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

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

For a simple one-parameter read tool with annotations and no output schema, the description is complete: it names the input, the scope ('single'), and the returned content ('full briefing details and lead-stage counts'). No significant gaps remain.

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% because campaign_id is fully explained, including its provenance from listCampaigns. The description adds no extra parameter meaning, so the baseline score of 3 applies.

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

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

The description uses a precise verb ('Get') and identifies a specific resource ('a single campaign') while clearly stating the distinguishing return content ('full briefing details and lead-stage counts'). This separates it from sibling tools like listCampaigns (returns multiple) and getCampaignLeadFields (specific lead fields).

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 use when a single campaign's full details are needed, but it does not explicitly state when-not to use or mention alternatives. It leaves the agent to infer when to choose this over sibling list 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 only declare readOnlyHint=true; the description adds genuine value by disclosing exact return behavior (standard fields with non-null values, metadata keys with usage counts and sample values) beyond anything annotations provide. It holds back slightly by not addressing edge behavior like empty campaigns or error cases, hence not a 5, but there is no contradiction with the read-only annotation.

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

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

Three sentences, each earning its place: (1) purpose, (2) return format, (3) operational trigger. Front-loads the verb and scope, with the time-sensitive workflow warning saved for last. Zero filler, high signal density — model example of efficient tool documentation.

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

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

For a simple 1-parameter read tool with rich readOnlyHint annotation, the description is substantial: it explains the return shape and provides a practical usage rule. The minor inconsistency between 'campaign' and 'list' terminology causes negligible ambiguity, and no output schema exists to lean on — for this complexity tier, the description is 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%, with the parameter already documented as 'ID of the campaign (from listCampaigns).' Per rubric, high schema coverage sets a baseline of 3, and while the description's phrase 'for this list' subtly reinforces that campaign_id is a list reference, it doesn't add meaningful syntax or format details beyond the schema — description correctly relies on the schema here.

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?

Presents a specific verb+resource ('Discover...fields used in a campaign's leads') and details the exact return shape: standard columns with non-null values plus custom metadata keys with usage counts and sample values. The title 'Discover Lead Fields' and description clearly distinguish it from the data-returning sibling listCampaignLeads, so an agent won't confuse schema vs. record retrieval.

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, actionable when-to-call guidance: 'ALWAYS call this BEFORE asking the user about lead structure or before adding new custom fields.' This provides clear trigger conditions and implies when it's not needed, though it never names an alternative sibling for the when-not path, keeping it a notch below a perfect 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?

The description is consistent with the existing readOnlyHint: true annotation and adds a modest behavioral detail—that the tool returns aggregated counts rather than the full memory contents. However, since the annotation already establishes the safe read-only profile, the description's additional behavioral disclosure beyond that is thin, mirroring the get_calls calibration case.

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

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

Two tightly packed sentences with zero wasted words: the first states the function, the second prescribes when to use it. Every word earns its place, front-loaded with the key verb and resource.

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 tool with no parameters, an existing output schema (documenting the return), and a readOnlyHint annotation, the description covers purpose, output nature (counts per chapter), and call timing. Given the tool's low complexity, nothing essential is missing—only hypothetical color about ordering or edge cases could add anything.

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

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

With zero parameters and 100% (vacuously) covered schema, there is literally nothing for the description to add about arguments or inputs. Per the rubric's baseline for a 0-parameter tool, a 4 is appropriate—the description correctly implies this is a fire-and-forget aggregate call requiring no user input.

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

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

"Get memory count per chapter" pairs a specific verb (Get) with a specific resource (memory count per chapter), clarifying that this is an aggregate, grouped operation rather than a raw listing. This meaningfully differentiates it from siblings like countMemories, listMemories, and searchMemory, while decoding what the vague title 'Chapter Overview' actually does.

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?

"Use as FIRST STEP in new conversations or reviews" provides an explicit trigger for when to invoke the tool, effectively positioning it as the entry point for fresh context. However, it stops short of naming alternatives or exclusions (e.g., when to choose countMemories or searchMemory instead), so it doesn't fully reach the top of the scale.

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 mark readOnlyHint: true, covering safety. The description adds behavioral context by stating it returns a 'fresh download URL' (implying time-limited or regenerated) and 'linked insights' (additional data), which are not obvious from the schema. This goes beyond the read-only annotation without contradicting it.

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

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

A single, front-loaded sentence with no fluff. Every word adds value: 'specific' scopes it, 'fresh download URL' and 'linked insights' describe key outputs. Ideal conciseness.

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

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

For a simple single-parameter read operation with annotations and no output schema, the description provides sufficient detail on what the response contains. It could elaborate on what 'linked insights' entails, but overall it's complete enough for an agent to invoke correctly.

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

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

Schema coverage is 100% with document_id already described as coming from listDocuments. The description does not add any parameter-specific meaning beyond echoing the need for a specific document. Baseline 3 is appropriate as the schema fully documents the parameter.

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

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

Description clearly states the tool retrieves a specific document by ID, and highlights two distinctive outputs (fresh download URL and linked insights) that separate it from listDocuments and other siblings. The verb 'Get' and resource 'specific document' are explicit and 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 use when a specific document's details are needed, especially to obtain a fresh URL or insights. It does not explicitly mention when not to use or name alternatives, but the context (sibling listDocuments) provides implicit differentiation. Clear enough but lacks exclusionary 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: true, so the description doesn't need to repeat that. It adds useful behavioral detail about what is included (timestamps and who made changes), which goes beyond the basic read-only trait. No contradictions found.

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 concise sentences deliver the purpose and output details without redundancy. Every word adds value, and it is front-loaded with the core action.

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

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

For a simple read tool with one parameter and no output schema, the description fully explains the tool's behavior. It mentions the key output aspects (timestamps and authors) and is sufficient for an agent to know when and how to use 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?

The schema description for embedding_id is already clear ('ID of the memory to get history for'), and coverage is 100%. The description does not add meaningful semantics beyond what the schema provides; it simply restates that it's for a specific memory. 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 clearly states the action (get version history), the resource (a specific memory), and what it shows (all previous versions with timestamps and authors). This unambiguously differentiates it from sibling tools like listMemories or searchMemory, which serve different purposes.

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 specifies the context (for a specific memory) and implies that it is used when you need past versions. However, it does not explicitly mention when not to use it or alternatives, so it lacks explicit exclusions. The context is clear enough for a simple read operation.

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, and the description builds on that by disclosing the null return value, session scoping, and the important automatic injection behavior. It clearly explains what the tool does and when its output may be redundant, going beyond the annotation's minimal safety signal.

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 carry exactly the necessary information: the operation and return behavior, the intended use case, and the critical auto-injection caveat. No filler, no repetition of schema fields.

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

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

For a simple read-only getter with full schema coverage, the description is complete. It addresses the return value, session scope, when to call it, and when not to call it. No output schema is needed for this tool, and all necessary behavioral context is present.

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

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

Schema description coverage is 100%, so the parameters are already well-documented. The description adds context about the purpose of (kind, key) in relation to existing state and the same key used in setWorkingMemory, but it does not materially extend the schema's per-parameter semantics. 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 states a specific verb+resource: 'Retrieve the current state for a (kind, key) in the current session.' It clearly distinguishes this get-by-key operation from sibling tools like listMemories, countMemories, and searchMemory, and adds the key behavior of returning null if unset.

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 explicit when-to-use guidance: 'Use this when you need to merge into existing state or verify what's stored.' It also provides a strong when-not-to-use note: active entries are auto-injected into the system prompt by Build Messages, so manual calls are usually unnecessary and should only happen for on-demand full state.

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 annotation readOnlyHint=true already indicates a safe read operation. The description adds value by clarifying pagination with 'Returns up to 100 per call' and the optional filter options, which help the agent understand expected behavior without contradicting any annotation.

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, well-structured sentence that front-loads the primary action ('List leads in a campaign') and packs optional filters and pagination into a compact statement. Every word adds value, with no redundancy.

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

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

For a simple listing tool with little complexity, the description covers the essential behavior: list items, optional filters, and pagination limit. There is no output schema, so the description could mention what fields appear in returned leads, but the omission is minor for a resource from which leads are listed.

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

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

The input schema has 100% coverage with descriptions for all parameters, so the description itself does not need to explain parameter semantics. It does restate lifecycle_stage and enrichment_status, but adds no meaning beyond the schema such as how filters interact or pagination mechanics beyond what 'limit' already explains.

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 'List' and clearly identifies the resource as 'leads in a campaign', distinguishing it from sibling tools like listCampaigns and getCampaignLeadFields. It also mentions optional filters and pagination, which makes the purpose crisp and specific.

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 clear usage: to list leads within a specific campaign, optionally filtering by lifecycle_stage or enrichment_status. It does not explicitly mention alternatives, but the 'campaign_id' parameter's schema description points users to listCampaigns, providing indirect selection guidance.

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

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

Annotations include readOnlyHint=true, so the description doesn't need to restate safety. It adds context about the return content (metadata plus per-stage lead counts), which is useful. However, it doesn't disclose pagination behavior beyond the limit parameter, or any other behavioral traits like ordering or default status.

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 sentence, front-loaded with the main action and filter, and adds a brief note on return content. No wasted words.

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

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

For a simple list tool with two optional parameters, full schema coverage, and a readOnly annotation, the description is adequate. It mentions the return includes per-stage lead counts, which is useful. It could mention pagination or ordering, but given the simplicity, it's nearly complete.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (limit with default/max, status with enum). The description adds minimal extra meaning beyond restating the filter by status. Baseline 3 is appropriate since 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 clearly states the tool lists campaigns for the current user with optional status filtering, and mentions the return includes campaign metadata and per-stage lead counts. It distinguishes from siblings like getCampaign (singular) and listCampaignLeads (leads), though it doesn't explicitly name alternatives.

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

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

The description implies usage for listing campaigns with optional filtering, but does not explicitly state when to use this vs. alternatives like getCampaign for a single campaign or listCampaignLeads for leads. No exclusions or alternative tool names are provided.

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 readOnlyHint annotation is provided and the description aligns with it. The description adds value beyond the annotation by disclosing that the output includes content preview and deletion info, and that the items are 'recently deleted' and 'can be restored', which are useful behavioral details not covered by the annotation.

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 concise and front-loaded, with two sentences that efficiently convey the purpose and key output details without fluff. Every word contributes value.

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 tool's simplicity (single optional parameter, read-only, no output schema), the description is adequately complete. It covers the core function and mentions preview/deletion info, filling gaps beyond the schema. The annotation already indicates read-only, so no further behavioral disclosure is needed.

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

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

The single parameter 'limit' is fully described in the schema with default value. The tool description does not add further semantics beyond what the schema already provides. Since schema coverage is 100%, a baseline of 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 clearly states the tool lists recently deleted memories that can be restored, distinguishing it from listMemories (which likely lists active memories) and searchMemory. It specifies the content shown (preview and deletion info), making the purpose unmistakable.

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 usage for restoration scenarios but does not explicitly state when to prefer this over sibling tools or exclude other cases. It gives context (recently deleted, restorable) but lacks direct guidance on alternatives.

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 readOnlyHint annotation already establishes the safe read-only nature. The description adds minimal behavioral context beyond that, mainly confirming it lists stored documents with optional filters. No additional details are given about return format, sorting, or pagination behavior, though the schema covers pagination 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?

The description is a single front-loaded sentence that states the action and scope without wasted words. It earns its place and is easy to parse.

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 straightforward read-only listing tool, the description plus annotations and fully documented optional parameters are mostly sufficient. It lacks an explicit statement of the return value shape, but the simple purpose, filter options, and pagination schema keep the gap acceptable.

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 parameters like limit, offset, chapter, and category are already well documented. The description adds only a high-level restatement of the chapter/category filters, providing no substantial new 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 clearly identifies the action ('List'), the resource ('stored documents'), and the optional filter dimensions ('category or chapter'). This distinguishes it from sibling tools like getDocument or listDeleted.

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

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

The intended context of enumerating documents is implied by the verb 'List' and the optional filters, but there is no explicit guidance on when to prefer this tool over alternatives such as getDocument or listDeleted.

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 include readOnlyHint: true, which already indicates a safe read operation. The description adds behavioral context beyond that by specifying the ordering ('stored order'), pagination support, and the intended use case (browse/audit vs search). It does not contradict annotations and provides useful behavioral context, though it could mention that no guarantees are made about ordering stability across pages, but that's not essential.

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 two sentences, front-loaded with the core purpose and then immediately contrasting with the sibling tool. Every word contributes: it states the operation, the ordering, the pagination, the filter option, and the alternative tool. No filler or redundancy.

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

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

For a read-only list operation with three optional parameters and no output schema, the description covers all essential aspects: purpose, differentiation from search, pagination, filtering, and ordering. It gives enough information for an agent to decide when to use it and how to invoke it, and the lack of output schema details is not a gap because no output schema is expected for a list tool like this.

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

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

The input schema already describes all three parameters (limit, offset, metadata_filter) with 100% coverage. The description adds extra value by explicitly advising to use metadata_filter.chapter for chapter scoping, which is not fully explained in the schema (though it does mention 'Use chapter to list within a specific chapter'). This guidance improves clarity 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 uses the specific verb 'List' with resource 'memories' and clarifies it returns in 'stored order' with pagination. It explicitly contrasts with searchMemory by stating it is for browsing/enumerating/auditing rather than semantic search, which clearly differentiates it from the sibling tool.

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

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

The description provides explicit usage guidance: 'Unlike searchMemory (semantic relevance ranking), use this to browse, enumerate, or audit a chapter — not to find the most relevant memory for a question.' It also names the alternative tool and gives a concrete example of filtering via metadata_filter.chapter, making when-to-use very clear.

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, and the description adds valuable behavioral context: default pending-only results, the status values that widen the scope, ordering by remind_at, and the exact fields returned. This goes beyond the annotation without contradicting it.

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

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

Three concise sentences, front-loaded with the core action and ordering, then default behavior, optional filters, and return fields. No wasted words or repetition of schema details.

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 read-only annotation, the description covers all essential aspects: ordering, default filter, status options, task scoping, and returned fields. It is fully sufficient for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra meaning by explaining the default status behavior, how status values widen results, and the purpose of task_id scoping, which enriches the schema 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?

The description uses a specific verb ('List') and resource ('reminders'), and adds distinctive details: ordering by remind_at ascending, default pending status, and optional task scoping. This clearly distinguishes it from sibling list tools like listMemories and listCampaigns.

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 clear context for when to use the tool: to list reminders with optional status filtering and task scoping. It does not explicitly name alternatives or exclusions, but the default behavior and filter options make the intended usage obvious.

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 readOnlyHint annotation is consistent with 'List'. The description adds value by disclosing the returned fields (display names, roles, and which token is yours), which helps set expectations beyond the annotation alone. No contradictions.

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

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

Two sentences, front-loaded with the core action and followed by a brief description of the output. Every word earns its place with no fluff.

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

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

For a no-parameter, read-only list tool, the description fully covers what to expect in the output. It does not mention pagination or sorting, but these are not required for the tool's simple purpose and the description is sufficient for an agent to decide when to use 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?

There are no parameters, so the baseline is 4. The description does not need to add parameter details, as none exist. The description correctly implies no input is required.

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 clearly states the tool lists all team members (token holders) for the account. The verb 'list' and resource 'team members' are specific, and the parenthetical clarifies scope. It distinguishes from siblings like listCampaigns and listDocuments by explicitly naming the team member context.

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

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

The description gives clear context that this is for listing team members for your account, which differentiates it from other list* tools. However, it does not explicitly mention alternatives or when not to use it, though the scope is obvious given the sibling list.

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 declare readOnlyHint: true, so the description carries the burden of explaining behavior. It discloses semantic matching, auto-tagging, and metadata filtering, plus a chapter list. This adds meaningful context about how search operates beyond the annotation.

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 well-organized: purpose first, then usage guidance, then filter details. Each sentence adds information, and the chapters list is presented as a scannable inline list. No filler or redundancy.

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

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

For a read-only search tool with no output schema, the description covers the key functional context: semantic search behavior, chapter options, and tag filtering. It doesn't describe result ordering or fields, but given the simplicity and the schema coverage, it's adequately 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 coverage is 100% for all 4 parameters, so baseline is 3. The description adds value by explaining the metadata_filter's tags key and listing valid chapter values, which the schema does not include. It also reinforces the query style with 'short, specific keywords.'

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 'Search long-term memory using semantic similarity,' which clearly states a specific action and resource. It distinguishes itself from sibling tools like listMemories by emphasizing semantic search, and further clarifies scope with available chapters.

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 an explicit directive: 'ALWAYS SEARCH BEFORE ANSWERING marketing/strategy questions,' and advises using short, specific keywords. This provides clear context for when the tool should be invoked, though it doesn't explicitly name alternative tools for other contexts, hence not a 5.

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