memoket

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that it fetches 'per-conversation' and 'short content-level evidence,' but no further behavioral traits (e.g., rate limits, auth) are disclosed.

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?

Single sentence with no wasted words. The tag '[content_fetch]' adds structure. Every part of the description earns its place.

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

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

The tool is simple with optional params and an output schema (not shown). Description lacks guidance on offset parameter and usage context. Adequate but not complete for an agent to use without further clarification.

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 67% (conversation_ids and brief_ids have descriptions; offset does not). The description only mentions conversation_ids in context, adding no extra detail beyond the schema. It does not compensate for the undocumented offset 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?

The description clearly states the tool fetches per-conversation brief bodies and defines 'brief' as short content-level evidence. This distinguishes it from sibling tools like get_summaries or get_transcripts, though it could be more explicit about the exact resource.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., get_summaries, get_transcripts). The '[content_fetch]' tag hints at a category but does not help the agent decide.

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 destructiveHint=false. The description adds value by specifying the exact scope of returned data (metadata only, no body content) and the query nature, which goes beyond the annotations.

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

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

The description is a single, front-loaded sentence that efficiently conveys the purpose, scope, and exclusions without any unnecessary 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?

The description covers the main purpose and distinguishes from siblings. With an output schema present, return values are documented elsewhere. Minor missing details like behavior for invalid IDs are acceptable given the schema hint of 'opaque recording ids'.

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

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

Schema description coverage is 100% for the single parameter, which already describes it as 'required, non-empty; opaque recording ids'. The tool description merely restates 'for the given conversation_ids', adding no new semantic 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 states it returns conversation-level metadata for given IDs, listing specific fields and explicitly excluding transcript, brief, and summary. This distinguishes it from sibling tools like get_transcripts, get_brief, and get_summaries.

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 clear context by listing what fields are returned and what is excluded, implicitly guiding when to use this tool over siblings. However, it does not explicitly name alternative tools or provide when-not-to-use 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 mark it as read-only and non-destructive. Description adds pagination via offset, which is useful but not extensive. No mention of limits, error handling, or additional behavioral traits beyond what annotations imply.

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?

Single, well-structured sentence that front-loads the category, lists two use cases, and mentions pagination. Every piece of information earns its place; 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?

Given the presence of an output schema and annotations, the description covers the essential behaviors: modes, pagination, and parameter relationships. However, it omits defaults for offset, error scenarios, and the fact that conversation_ids is implied required despite schema not marking it as required, causing a slight inconsistency.

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?

Adds significant meaning beyond schema: explains that summary_ids come from search_recordings, conversation_ids are opaque strings (potentially 19-digit snowflakes), and offset controls pagination. The schema had 67% coverage (offset missing description), so description compensates well.

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?

Clearly states it fetches per-conversation summary body with two distinct modes (by summary_ids or conversation_ids), distinguishing the resource and verb. The '[content_fetch]' tag subtly groups it with related tools but doesn't explicitly differentiate from siblings like get_brief, though the purpose 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?

Provides implicit guidance by explaining the two invocation modes (exact reports from search_recordings vs latest summary per conversation), but does not explicitly state when to use this tool over siblings like get_brief or get_transcripts. Lacks 'when not to use' or alternative tool recommendations.

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 indicate readOnlyHint=true and destructiveHint=false. Description adds that transcripts are verbatim, for one recording, and paginated, which provides useful behavioral context beyond annotations. 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?

Description is brief, with a single sentence and a parenthetical. It front-loads with a content tag [content_fetch]. No wasted words, but could expand slightly for completeness.

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 annotations and output schema, the description covers the core functionality (fetch transcript) and pagination. It is fairly complete for a simple read operation, though it could mention that it returns the full text (but output schema handles that).

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

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

Schema coverage is 50% (only conversation_id described). Description partially compensates by explaining offset's role in pagination, but does not fully define its semantics (e.g., starting point). This adds value but is not thorough.

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 it fetches the 'verbatim transcript of ONE recording' using conversation_id, specifying both the action and resource. However, it does not explicitly differentiate from sibling tools like get_summaries or get_transcripts_by_participant, leaving some ambiguity for agents.

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?

Description mentions pagination and the use of offset/next_offset, giving context on how to use it. But it does not state when to prefer this tool over alternatives (e.g., get_summaries for summaries, get_transcripts_by_participant for transcripts by participant), missing explicit usage guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that the tool fetches transcript lines and serves as evidence for search results, but doesn't disclose additional behaviors like authentication requirements, rate limits, or how the data is returned.

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 extremely concise with two sentences, front-loaded with a functional tag. Every part serves a purpose with 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?

Given the tool has 4 parameters and an output schema, the description is barebones but covers the core purpose. However, it lacks details on ordering, pagination, or precise behavior of 'limit'. With output schema present, the agent might infer return structure, but the description could be more 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 50%, with descriptions only for 'participant_ids' and 'conversation_ids'. The description mentions these two parameters but does not elaborate on 'limit' or 'query' parameters, which lack schema descriptions. Thus, it fails to compensate for the undocumented 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 clearly states the tool fetches transcript lines associated with participant_ids in conversation_ids, with a specific purpose ('turns participant metadata into transcript evidence'). It distinguishes itself from sibling tools by focusing on participant-based retrieval, though it doesn't explicitly differentiate from 'get_transcripts'.

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

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

There is no guidance on when to use this tool versus alternatives. The description implies usage when participant_ids and conversation_ids are available, but no exclusions or comparisons 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral details: pagination (count default 100, max 200, offset), order_by ranking within window, and the crucial note that participant names are speaker labels (placeholders unless tagged).

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 extremely concise: two sentences plus a brief note. Key information is front-loaded, and every sentence adds value without 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?

Given the tool has 7 parameters, pagination, and an output schema, the description covers all necessary context: it explains what data is returned, pagination mechanics, order_by behavior, and the semantic nuance about participant labels. The presence of an output schema adequately covers return value details.

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 100% schema description coverage, the description adds marginal value beyond the schema. The note about participant names being speaker labels provides context but partially overlaps with the schema's description of the participant_names 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?

The description clearly states the tool lists recordings by time window or participants, specifying the exact fields returned (id, title, etc.) and that it excludes content. This distinguishes it from siblings like get_transcripts that return content.

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 retrieving metadata listings but does not explicitly state when to use this tool over alternatives like search_recordings or get_conversations. No exclusions 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?

Annotations (readOnlyHint, destructiveHint) already declare safety, and the description adds valuable context: bounded searches, typed returns with IDs, and execution mode differences. 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?

The description is front-loaded with a clear label and purpose. While slightly wordy, each sentence adds value (scope, return info, execution differences). Could trim some technical 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?

Given the complexity (5 params, output schema, good annotations), the description covers purpose, scope, and behavior reasonably well. It could mention the date filtering parameters explicitly but the schema handles that.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minimal extra semantics beyond the schema (e.g., 'bounded searches' hints at time bounds but does not detail parameter usage).

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 it is a 'Unified recording search' that searches across multiple types (transcript, participant, title, brief, summary, action_item). It distinguishes itself from sibling tools (e.g., get_transcripts, get_brief) which are single-type retrievers.

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 cross-type searches and mentions behavior differences for chat vs external callers. However, it does not explicitly state when to use alternatives (e.g., when only one type is needed) or provide exclusions.

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