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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's function and use cases but lacks details on permissions, rate limits, side effects (e.g., whether it's read-only or generates files), or error handling. It adds value by explaining the purpose and applications but misses operational 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?

The description is appropriately sized and front-loaded, starting with the core purpose and formats, followed by a TIP and use cases. Every sentence adds value (e.g., explaining applications), but it could be slightly more concise by integrating the TIP into the main flow rather than as a separate note.

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 complexity (7 parameters, nested objects, no output schema) and lack of annotations, the description is adequate but incomplete. It covers purpose and usage well but does not address output behavior (e.g., what is returned or how data is delivered), error conditions, or performance aspects, leaving gaps for an AI agent to infer.

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 parameters thoroughly. The description adds minimal parameter-specific semantics beyond the schema, only emphasizing 'filters.projectPath' in a TIP. It does not explain parameter interactions or provide additional syntax/format details, aligning with the baseline score when schema coverage is high.

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's purpose with specific verb ('Export') and resource ('chat data'), and distinguishes it from siblings by specifying it exports data for external analysis/visualization/integration, unlike tools like 'get_conversation' (fetch single) or 'list_conversations' (list metadata). The mention of formats (JSON, CSV, Graph) further clarifies its unique role.

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 for when to use this tool (e.g., for machine learning datasets, stakeholder reports, visualization tools, or backups) and includes a TIP recommending 'filters.projectPath' for project-specific conversations. However, it does not explicitly state when NOT to use it or name alternatives among siblings (e.g., 'extract_conversation_elements' might overlap for specific elements).

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool's function and use cases but lacks details on behavioral traits such as performance characteristics, rate limits, error handling, or authentication requirements. The description adds value by explaining the tool's purpose but does not fully compensate for the absence of 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 appropriately sized and front-loaded, starting with the core purpose and following with use cases. Both sentences earn their place by clarifying the tool's function and applications. It could be slightly more concise by integrating the use cases more tightly, but overall it is well-structured and efficient.

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 complexity (6 parameters, nested objects) and the absence of both annotations and an output schema, the description is somewhat incomplete. It explains what the tool does and why to use it but does not address behavioral aspects or output format, leaving gaps that could hinder an AI agent's understanding of how to invoke it effectively.

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% description coverage, so the schema already documents all parameters thoroughly. The description does not add any parameter-specific information beyond what the schema provides, such as explaining the semantics of 'elements' or 'filters' in more detail. Baseline score of 3 is appropriate when schema coverage is high.

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's purpose with specific verbs ('extract specific elements from conversations') and resources ('conversations'), listing concrete element types like file references, code blocks, and metadata. It distinguishes from sibling tools like 'export_conversation_data' or 'get_conversation' by focusing on element extraction rather than full export or 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?

The description provides clear context for when to use this tool ('to build knowledge bases, analyze code patterns, extract reusable snippets, understand project file usage, or prepare data for further analysis and documentation'), which helps differentiate it from siblings. However, it does not explicitly state when not to use it or name specific alternatives among the 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool does (find related conversations based on specified relationship types) and mentions similarity scores, but doesn't cover important behavioral aspects like whether this is a read-only operation, potential performance characteristics, rate limits, authentication requirements, or error conditions. It adds some context about relationship types but leaves gaps in operational transparency.

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 appropriately sized with two sentences. The first sentence clearly states the purpose and relationship types, while the second provides usage guidance. There's minimal waste, though the second sentence could be slightly more concise. The structure is front-loaded with the core functionality.

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 moderate complexity (6 parameters, relationship-based matching), no annotations, and no output schema, the description provides adequate purpose and usage context but lacks details about behavioral characteristics, return format, error handling, and performance considerations. It's complete enough for basic understanding but has gaps for operational use.

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 coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description mentions relationship types (files, folders, languages, size, temporal) which aligns with the 'relationshipTypes' parameter, but doesn't add significant meaning beyond what's in the schema descriptions. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verbs ('find conversations related to') and resources ('reference conversation'), and distinguishes it from siblings by focusing on relationship-based discovery rather than listing, searching, exporting, or analyzing conversations. It explicitly mentions the relationship types (files, folders, languages, size, temporal) that differentiate its functionality.

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 guidance on when to use this tool: 'to discover related discussions, find conversations about the same codebase/project, identify similar problem-solving sessions, or trace the evolution of ideas across multiple conversations.' This gives clear context for application scenarios, though it doesn't explicitly mention when NOT to use it or name specific alternatives among siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool retrieves (complete content including specific elements) and mentions a performance consideration (summaryOnly to conserve context), but lacks details on permissions, rate limits, error handling, or response structure. It adds some context but is incomplete for a tool with no annotation coverage.

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 appropriately sized and front-loaded: the first sentence clearly states the purpose, followed by a workflow tip that adds practical guidance without redundancy. Every sentence earns its place by providing actionable information, with no wasted words or unnecessary elaboration.

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 moderate complexity (retrieving conversation data with optional filtering), no annotations, and no output schema, the description is mostly complete. It covers the purpose, usage guidelines, and key parameters, but lacks details on behavioral aspects like error handling or response format. It compensates well but has minor gaps in transparency.

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 parameters thoroughly. The description adds minimal value beyond the schema: it mentions using conversation IDs from specific sources (implied in the schema) and explains the purpose of summaryOnly=true for context conservation, but doesn't provide additional syntax or format details. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the specific action ('Retrieves') and resource ('complete content of a specific Cursor conversation'), listing concrete components like messages, code blocks, file references, title, and AI summary. It distinguishes from siblings by specifying this tool retrieves full conversation content, unlike list_conversations (which lists IDs) or get_conversation_analytics (which provides analytics).

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 guidance on when to use this tool: it specifies obtaining conversation IDs from list_conversations, search_conversations, or analytics breakdowns, and includes a 'WORKFLOW TIP' for using summaryOnly=true to conserve context. It implicitly distinguishes from siblings by not suggesting alternatives for retrieving full conversation content.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it explains that using projectPath 'analyzes only conversations that worked on files in that project,' mentions that includeConversationDetails 'increases response size significantly,' and provides workflow tips for efficient usage. However, it doesn't address potential rate limits, authentication needs, or error conditions, leaving some gaps in behavioral context.

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 well-structured with clear sections (purpose, best practice, workflow tip) and uses bold text for emphasis. It's appropriately sized for a tool with 6 parameters and no annotations, though it could be slightly more concise by avoiding repetition of schema details (e.g., projectPath explanation appears in both description and schema). Every sentence adds value, but minor trimming is possible.

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 complexity (6 parameters, no output schema, no annotations), the description does a good job of providing context: it explains the tool's purpose, usage guidelines, and key behavioral aspects. However, it lacks details on output structure (since no output schema exists) and doesn't fully cover all behavioral traits like error handling or performance considerations, leaving room for improvement in 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?

The description adds some semantic context beyond the input schema, such as emphasizing projectPath as 'HIGHLY RECOMMENDED' and explaining its impact on relevance. However, with 100% schema description coverage, the schema already documents all parameters thoroughly (e.g., scope, recentDays, includeBreakdowns). The description reinforces but doesn't significantly expand on parameter meanings, meeting the baseline for high 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 clearly states the tool's purpose: 'Get comprehensive analytics and statistics about Cursor chats including usage patterns, file activity, programming language distribution, and temporal trends.' It specifies the verb ('Get') and resource ('analytics and statistics about Cursor chats') with detailed scope, distinguishing it from siblings like 'list_conversations' or 'get_conversation' that focus on individual conversations rather than aggregated analytics.

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 guidelines: it includes a 'BEST PRACTICE' section recommending the projectPath parameter for project-specific analytics and a 'WORKFLOW TIP' advising to always include 'files' and 'languages' in breakdowns for follow-up analysis with get_conversation. It also mentions when to use includeConversationDetails=true, offering clear alternatives and context for effective tool selection.

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?

No annotations are provided, so the description carries full burden. It describes what information is available (date, timezone, other context) but doesn't specify format, precision, or limitations. It mentions this is 'helpful context that AI assistants may not have access to' which hints at its utility, but lacks details on rate limits, authentication needs, or error conditions.

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 efficiently structured in two sentences: first stating the purpose and scope, then providing clear usage guidelines. Every element serves a purpose with no redundant information, making it easy to parse and understand quickly.

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 utility tool with 1 parameter and no output schema, the description provides good context about what information is available and when to use it. However, without annotations or output schema, it could benefit from more detail about the format and scope of 'other helpful context' returned.

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 fully documents the single parameter with enum values and default. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for adequate coverage through structured data alone.

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's purpose with specific verbs ('Get system information and utilities') and resources ('current date, timezone, and other helpful context'). It distinguishes itself from sibling tools (all conversation-related) by focusing on system-level information rather than conversation data.

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 guidance on when to use this tool: 'Use this when you need reference information for date filtering, time-based queries, or other system context.' It clearly differentiates from sibling tools by addressing a completely different domain (system utilities vs. conversation management).

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

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

With no annotations provided, the description carries full burden and does well by disclosing key behaviors: ordering ('ordered by recency'), default inclusion of AI-generated summaries, date format requirements ('YYYY-MM-DD format'), and a warning about timestamp reliability. It doesn't mention pagination, rate limits, or authentication needs, but covers substantial operational context.

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 appropriately sized and front-loaded with core functionality. The bold recommendation about projectPath is prominent, and the workflow tip provides practical guidance. Some sentences could be more concise, but overall it's well-structured with zero wasted content.

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 13-parameter tool with no annotations and no output schema, the description provides substantial context about usage patterns, filtering importance, and relationship to other tools. It doesn't describe the return format in detail (though mentions conversation IDs), but given the rich parameter documentation in the schema, it's reasonably complete for guiding effective tool selection.

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 adds some value by emphasizing the importance of 'projectPath' parameter and providing workflow context, but doesn't significantly enhance understanding of individual parameters beyond what the schema already documents thoroughly.

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 verb ('Lists') and resource ('Cursor chats') with specific attributes ('summaries, titles, and metadata ordered by recency'). It distinguishes from siblings like 'search_conversations' by emphasizing comprehensive listing with filtering rather than search functionality, and explicitly mentions the relationship to 'get_conversation' 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 guidance on when to use this tool ('HIGHLY RECOMMENDED: Use projectPath parameter...'), includes a workflow tip ('Start with projectPath filtering... then call get_conversation'), and implicitly distinguishes from alternatives like 'search_conversations' by focusing on filtered listing rather than search operations.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains the search method (exact text matching, NOT semantic search), provides warnings about unreliable timestamps, and mentions the need to call 'get_system_info' for date context. However, it doesn't fully describe return format or pagination behavior, leaving some gaps.

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 well-structured with clear sections (warning, usage guidelines, search methods, examples) and uses formatting effectively. While comprehensive, some sentences could be more concise, and the warning is repeated multiple times, slightly reducing efficiency.

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 10-parameter search tool with no annotations and no output schema, the description does an excellent job covering purpose, usage, and parameter semantics. It provides concrete examples and warnings. The main gap is the lack of information about return values or result format, which would be helpful given the absence of an output schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds significant value by explaining the four search methods (simple text matching, multi-keyword, LIKE patterns, date range) with concrete examples and clarifying the relationship between parameters. This goes well beyond what the schema provides in isolation.

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 'searches through Cursor chat content using exact text matching' and distinguishes it from sibling tools by explicitly warning against using it for project-specific searches, directing users to 'list_conversations with projectPath instead'. This provides specific verb+resource+scope and clear sibling differentiation.

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

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

The description includes explicit 'WHEN TO USE THIS TOOL' and 'WHEN NOT TO USE THIS TOOL' sections with concrete examples and clear exclusions. It names the alternative tool ('list_conversations') and provides specific guidance on what queries to avoid, making it highly actionable for an AI agent.

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