Fast.io

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

The description adds significant behavioral context beyond annotations. While annotations indicate readOnlyHint=false and destructiveHint=true, the description details side effects ('chat-create and message-send consume AI credits'), specific destructive actions ('chat-delete permanently removes a chat'), and operational constraints (e.g., 'workspace intelligence enabled' requirements, error conditions like 406 for folders). This enriches the agent's understanding of tool behavior.

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

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

The description is appropriately front-loaded with a clear purpose statement, but it includes a lengthy bulleted list of actions and parameters that could be more streamlined. While informative, the structure is dense, and some details (like parameter lists) might be redundant given the comprehensive schema. Every sentence adds value, but the presentation could be more concise.

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 (21 parameters, multiple actions, no output schema), the description is largely complete. It covers purpose, usage guidelines, behavioral traits, and parameter context. However, without an output schema, it lacks details on return values or response formats, which is a minor gap. The annotations and schema provide strong support, but the description compensates well for the missing output information.

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 baseline is 3. The description adds value by clarifying parameter semantics in the action list, such as indicating which parameters are required or optional for each action (e.g., 'chat-create: type, query_text (workspace req'd, share optional)'), and providing context like 'share-generate: node_ids (workspace) | files (share)'. However, it doesn't fully explain complex parameter interactions beyond what the schema covers.

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 as 'AI-powered RAG chat, document analysis, and shareable summaries' and enumerates specific actions like 'create chats, send messages, read AI responses, and generate shareable summaries.' It distinguishes this tool from siblings by focusing on AI chat functionality rather than file management, comments, or other workspace operations.

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, including when to use specific actions (e.g., 'chat-create' requires workspace, share optional), prerequisites ('all actions require profile_type + profile_id'), and exclusions (e.g., 'share-generate: node_ids (workspace) | files (share)'). It also notes side effects like credit consumption and destructive actions, helping differentiate from 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the widget's interactive capabilities (view/add/delete comments, emoji reactions, anchors, activity feed) which is helpful, but doesn't mention authentication requirements, rate limits, whether it's read-only or destructive, or what happens when launched. The description adds value but leaves gaps in behavioral understanding.

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 the core purpose in the first sentence, followed by feature details and parameter guidance. Every sentence adds value, though the parameter section could be more integrated with the main description rather than appearing as an afterthought.

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 6-parameter tool with no annotations and no output schema, the description provides adequate context about what the tool does and its parameters, but leaves gaps in behavioral understanding (authentication, side effects, response format). Given the complexity of launching an interactive widget with multiple parameters, more complete guidance would be helpful.

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 6 parameters thoroughly. The description adds minimal value beyond the schema - it mentions 'profile_type (workspace or share), profile_id (19-digit ID), node_id (optional): Storage node opaque ID to show file-level comments (omit for workspace/share-level), file_name (optional): File name for display in the header' but doesn't explain parameter relationships or provide additional context not in 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 clearly states the tool's purpose: 'Launch the Comments MCP App widget' with specific functionality including 'view, add, and delete comments with reply threading, emoji reactions (add/remove), comment anchors for image/video/audio/PDF, and chronological activity feed.' It distinguishes this from sibling tools like 'comment' by specifying it launches an interactive widget/app rather than performing direct comment operations.

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: 'Supports workspace and share contexts' and specifies optional parameters for file-level vs. workspace/share-level comments. However, it doesn't explicitly state when NOT to use it or name alternatives among sibling tools (e.g., when to use 'comment' tool instead).

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

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

With no annotations provided, the description carries full burden. It discloses behavioral traits like supporting 'workspace and share contexts', 'grid and list views', 'multi-select', and 'responsive layout', which are useful context. However, it lacks details on permissions needed, rate limits, or what happens during file operations (e.g., are deletions permanent?). The description adds value but leaves gaps for a tool with management capabilities.

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. However, it includes some redundancy (e.g., listing features like 'upload/download, move/copy/delete, rename' could be more concise) and the param note at the end is somewhat tacked on. Most sentences earn their place, but minor trimming could improve 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?

Given no annotations and no output schema, the description provides good context on functionality (browsing, picking, management) and parameters. However, for a tool with file management capabilities (including destructive operations like delete), it lacks details on error handling, return values, or security implications. It's adequate but has clear gaps for a tool of this complexity.

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 4 parameters with descriptions and enums. The description adds minimal param info ('profile_type (workspace or share), profile_id (19-digit ID)'), which slightly reinforces but doesn't provide meaning beyond the schema. Baseline 3 is appropriate as 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 ('Launch', 'Browse and pick files', 'attach to your conversation') and resources ('File Picker MCP App widget', 'files'). It distinguishes from siblings like 'app-uploader' by emphasizing file selection/browsing rather than just uploading, and from 'app-file-viewer' by focusing on picking/management rather than viewing only.

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 attach files to your conversation', 'file management'), but does not explicitly state when NOT to use it or name specific alternatives. It implies usage for file selection tasks without contrasting with tools like 'upload' or 'app-uploader' for simpler uploads.

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 does well by describing the tool's behavior: launching a widget with preview capabilities, dark mode interface, keyboard navigation, and specific features like zoom/pan, PDF viewer, HLS video support, etc. It mentions the tool provides 'file details, version history with restore, AI summary, and linked metadata' which gives good context about what information will be available. However, it doesn't mention potential limitations like file size restrictions, supported formats beyond those listed, or performance characteristics.

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 ('Launch the File Viewer MCP App widget') followed by key features. The second sentence efficiently lists multiple capabilities. The parameter section at the end is somewhat redundant given the schema coverage but provides a quick reference. Overall, most sentences earn their place by conveying important functionality, though the parameter listing could be more concise.

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 (rich file viewer with multiple features) and 100% schema coverage but no annotations or output schema, the description does a good job of explaining what the tool does and its capabilities. It covers the preview functionality, interface characteristics (dark mode, keyboard nav), and information panel features. However, for a tool with no output schema, it doesn't describe what the widget launch returns or how the preview interface integrates with the user's workflow, leaving some gaps in understanding the complete user experience.

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 7 parameters thoroughly. The description lists 4 parameters (profile_type, profile_id, node_id, file_name, mime_type) with brief explanations, but these don't add significant meaning beyond what's already in the schema descriptions. The schema provides more detailed information about parameter aliases (context_id/profile_id, context_type/profile_type) and enum values that aren't mentioned in the description. Baseline 3 is appropriate when 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: 'Launch the File Viewer MCP App widget' with specific details about its functionality including multi-format preview capabilities (image, PDF, video, audio, spreadsheets, code, documents) and additional features like info panel, version history, AI summary, and metadata. It distinguishes itself from sibling tools like 'app-uploader', 'download', and 'storage' by focusing specifically on viewing/previewing files rather than uploading, downloading, or managing storage.

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 context through phrases like 'Unified file preview and information' and 'Always dark mode preview with keyboard navigation,' suggesting this is for viewing files in a rich preview interface. However, it doesn't explicitly state when to use this tool versus alternatives like 'download' (for downloading files) or 'storage' (for storage operations). No explicit exclusions or comparisons to sibling tools 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 description adds significant behavioral context beyond annotations (which only indicate it's not read-only and not destructive). It discloses destructive operations (delete, bulk-delete marked as permanent deletion), role-based access requirements, prerequisites (enable-workflow), scope limitations (entities, profiles), and action-specific constraints (e.g., 'pending only' for update). No contradiction with annotations 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 front-loaded with a clear purpose and prerequisites, but the lengthy action-parameter list (12 actions with details) makes it dense. While informative, it could be more concise by summarizing parameter patterns rather than listing each action individually. Every sentence adds value, but structure is somewhat overwhelming.

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 (20 parameters, multiple actions, no output schema), the description is mostly complete. It covers purpose, usage, behavioral traits, and parameter guidance. However, it lacks details on response formats, error handling, or pagination beyond basic limits, leaving some gaps for agent invocation.

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 baseline is 3. The description adds value by grouping parameters by action, clarifying dependencies (e.g., 'omit profile_type/profile_id for cross-profile user view' for filtered-list), and noting aliases (context_id/profile_id, context_type/profile_type). However, it doesn't fully explain complex parameter interactions beyond schema basics.

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 as 'Approval workflow operations' and lists specific actions (list, create, view details, resolve) with their scope (workspaces and shares). It distinguishes this tool from siblings by specifying it handles formal approval requests on specific entities, unlike general workflow or task tools.

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: it states prerequisites (workflow must be enabled via enable-workflow actions), role requirements (admin or named member for shares), and distinguishes between actions with their required parameters. It also clarifies when to omit parameters (e.g., omit profile_type/profile_id for cross-profile view in filtered-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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes key behaviors: the launch action renders HTML widgets, and parameters have aliases (context_id/profile_id, context_type/profile_type). However, it doesn't cover important aspects like authentication requirements, rate limits, error conditions, or what 'renders' means operationally (e.g., returns HTML, opens a window).

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 a high-level purpose statement followed by an action-parameter table. Every sentence earns its place by providing essential information. It could be slightly more concise by integrating the table more smoothly, but overall it's efficiently organized with zero wasted text.

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 complex tool with 8 parameters, no annotations, and no output schema, the description is adequate but has gaps. It covers the purpose, actions, and parameter mapping well, but lacks information about return values (especially important for the HTML-rendering 'launch' action), error handling, and operational constraints. The context is complete enough for basic use but insufficient for robust implementation.

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 mapping parameters to specific actions in the 'Actions & required params' section, clarifying which parameters are needed for each action. This operational mapping goes beyond the schema's individual parameter descriptions, though it doesn't fully explain complex parameters like 'extra_params'.

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 as managing 'interactive UI widgets for file browsing, workspace dashboards, uploads, and more' and enumerates four specific actions (list, details, launch, get-tool-apps). It distinguishes this multi-action tool from single-purpose siblings like 'app-file-picker' or 'app-uploader' by showing it's a unified interface for app management.

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 each action (e.g., 'list all available apps', 'get full metadata for a specific app', 'renders the widget'), and the parameter requirements table implicitly guides usage. However, it doesn't explicitly state when to choose this tool over direct sibling tools like 'app-file-picker' or 'app-uploader', nor does it provide exclusion criteria.

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 for behavioral disclosure. It mentions 'launch the widget' which implies a UI interaction rather than a direct API call, and describes features like drag-and-drop, progress tracking, chunked uploads, and URL imports. However, it doesn't cover important behavioral aspects like authentication requirements, rate limits, error handling, or what happens after upload completion.

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 reasonably concise with two sentences covering core functionality and a separate Params section. The first sentence clearly states the main purpose, though the Params section could be integrated more smoothly. Overall, it's front-loaded with essential information without excessive verbosity.

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 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after widget launch, what the user experience entails, how results are communicated back to the agent, or any error conditions. The feature list is helpful but doesn't provide complete operational context for an AI agent to use this tool 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?

Schema description coverage is 100%, providing a solid baseline. The description adds minimal value beyond the schema by mentioning 'profile_type (workspace or share), profile_id (19-digit ID)' in a separate Params section, but this essentially repeats what's already documented in the schema with enum values and descriptions. No additional semantic context is provided.

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: 'Launch the Upload Files MCP App widget. Upload files to a workspace or share with drag-and-drop support and progress tracking.' It specifies the verb (launch/upload) and resource (files to workspace/share), but doesn't explicitly differentiate from sibling tools like 'upload' or 'download' beyond mentioning widget features.

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 no guidance on when to use this tool versus alternatives like the sibling 'upload' tool. It mentions features like drag-and-drop and progress tracking, but doesn't specify scenarios where this widget-based approach is preferred over direct API uploads or when to choose workspace vs. share contexts.

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 the interface features (drag-and-drop, inline editing, etc.) but doesn't clarify whether this is a read-only view or allows mutations, what permissions are required, whether changes are saved automatically, or any rate limits. For a tool that appears to manage workflows with potential write operations, this is a significant gap in 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 and front-loaded, starting with the core purpose ('Launch the Workflow Manager MCP App widget') followed by feature details. It uses efficient language without unnecessary fluff, though the parameter note at the end could be integrated more seamlessly.

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 apparent complexity (managing workflows with multiple features), no annotations, and no output schema, the description provides a good overview of interface capabilities but lacks critical behavioral context like mutation permissions, error handling, or response format. It's adequate as a high-level introduction but incomplete for safe and effective tool invocation by an AI agent.

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 four parameters with clear descriptions and enums. The description adds minimal value by mentioning 'profile_type (workspace or share), profile_id (19-digit ID)' in a note, but this mostly repeats what's in the schema. The baseline of 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 'launches the Workflow Manager MCP App widget' and provides a detailed overview of its unified interface capabilities including Kanban board, task editing, approvals panel, todo checklist, and worklog timeline. It specifies the verb 'launch' and resource 'Workflow Manager MCP App widget', though it doesn't explicitly differentiate from sibling tools like 'task' or 'todo' which might have overlapping 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 implies usage by mentioning it 'supports both workspace and share contexts with responsive layout', which suggests when to use it based on context type. However, it doesn't provide explicit guidance on when to choose this tool over alternatives like 'task' or 'todo' tools, nor does it specify prerequisites or exclusions for usage.

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 the tool as launching a UI widget with specific creation wizards and real-time checks, which helps understand it's interactive rather than purely programmatic. However, it doesn't mention important behavioral aspects like whether it blocks execution, requires user interaction, returns data, or has any side effects. The description adds some context but leaves significant behavioral questions unanswered.

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 at 4 sentences, front-loaded with the core purpose, followed by functionality details, creation workflows, and parameter highlights. Each sentence adds value: launching the widget, management capabilities, creation specifics, and parameter guidance. It could be slightly more concise by integrating the param note into the flow, but overall it's well-structured with minimal waste.

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

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

Given the tool's moderate complexity (UI widget with creation wizards), no annotations, and no output schema, the description is somewhat complete but has gaps. It covers what the tool does and its creation workflows but lacks details on behavioral outcomes, error handling, or what happens after widget launch. For a tool with interactive elements and no structured safety/behavior annotations, more context on user interaction and results would improve completeness.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly with descriptions and enums. The description adds minimal param information ('Params: profile_type (workspace or share), profile_id (19-digit ID)'), which partially overlaps with schema content. However, it doesn't explain parameter relationships or usage patterns beyond what's in the schema. The baseline is 3 for high schema coverage, but the description adds slight value by highlighting the two main parameters, warranting a 4.

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: 'Launch the Workspace Picker MCP App widget' and describes its functionality for workspace and share management including selection, search, filtering, and creation. It distinguishes itself from siblings by focusing on a specific UI widget for workspace/share selection rather than direct API operations. However, it doesn't explicitly contrast with specific sibling tools like 'workspace' or 'share' that might handle similar domains differently.

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 context through phrases like 'Workspace and share management' and mentions specific creation workflows, suggesting this tool is for UI-driven selection/creation tasks. However, it doesn't provide explicit guidance on when to use this widget vs. alternative programmatic tools (like 'workspace' or 'share' siblings) or when not to use it. The usage context is implied rather than explicitly stated.

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

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

The description adds valuable behavioral context beyond annotations by explicitly stating 'Destructive action: delete removes an uploaded asset' and detailing required parameters for each action. While annotations already indicate destructiveHint=true, the description provides specific context about what gets destroyed. It doesn't mention rate limits or authentication needs, but adds meaningful operational details.

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 a clear opening statement followed by action-specific parameter requirements. It's appropriately sized and front-loaded with the core purpose. Some redundancy exists between the description and schema, but every sentence serves a purpose in clarifying the multi-action tool.

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 complex multi-action tool with 10 parameters and no output schema, the description provides adequate but not comprehensive coverage. It explains the different actions and their parameter requirements, but doesn't describe return values, error conditions, or response formats. With destructiveHint=true annotation and no output schema, more behavioral context would be helpful for 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?

With 100% schema description coverage, the schema already documents all parameters thoroughly. The description adds some semantic context by grouping parameters by action (e.g., 'upload: entity_type, entity_id, asset_id or asset_type, content or file_base64'), but this mostly restates what's already in the schema's parameter 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 as 'Asset management (logos, banners, profile photos)' with specific verbs (upload, delete, list, read) and resources (organizations, workspaces, shares, user profiles). It distinguishes itself from sibling tools like 'upload' or 'storage' by focusing specifically on brand assets for entities.

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 about when to use different actions (list, upload, delete, read, types) with entity_type and entity_id requirements. However, it doesn't explicitly state when NOT to use this tool versus alternatives like 'upload' or 'storage' from the sibling list, which would be needed for a perfect score.

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

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

The description adds valuable behavioral context beyond the annotations. While annotations indicate destructiveHint=true, the description specifically identifies which actions are destructive ('api-key-delete permanently removes an API key, oauth-revoke/oauth-revoke-all revoke active sessions'). This clarifies the nature of the destruction, which helps the agent understand the specific risks. No contradiction with annotations 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 excessively long and poorly structured for an MCP tool. While the action-parameter mapping is useful, it should be in the schema, not the description. The description should be front-loaded with core purpose and key behavioral notes, but instead it dumps 28 action entries with parameter lists. This violates the principle that every sentence should earn its place.

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

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

Given the tool's high complexity (22 parameters, 28 actions, no output schema, destructive operations), the description provides good coverage of what actions exist and their parameters. However, it lacks critical context about return values, error conditions, authentication state transitions, and how different actions relate to each other. For such a complex authentication system, more behavioral guidance would be helpful.

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 baseline would be 3, but the description adds significant value by mapping each action to its required and optional parameters in a clear, tabular format. This provides practical usage guidance that complements the schema's technical descriptions, making it easier for an agent to construct valid calls without cross-referencing the schema extensively.

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 as 'Authentication and session management' and enumerates all specific actions it covers (sign-in/out, signup, 2FA, PKCE browser login, API key management, OAuth session management). This provides a comprehensive verb+resource mapping that distinguishes it from sibling tools like 'user' or 'member' which handle different aspects of user management.

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 no guidance on when to use this tool versus alternatives. While it lists all available actions, it doesn't indicate when to choose specific actions (e.g., when to use signin vs pkce-login) or when to use this authentication tool versus other tools in the sibling list. There's no mention of prerequisites, dependencies, or contextual triggers for different 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?

The description adds valuable behavioral context beyond annotations. While annotations indicate destructiveHint=true and readOnlyHint=false, the description specifies that 'delete removes a comment and all its replies' and 'bulk-delete removes multiple comments,' providing concrete details about destructive behavior. It also mentions support for various anchor types and workflow linking, which aren't covered by 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 front-loaded with a clear purpose statement, but becomes verbose with the detailed action/parameter listing. While informative, some details (like specific anchor coordinate ranges) could be streamlined since they're already in the schema. The structure is logical but could be more concise.

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 (21 parameters, nested objects, multiple actions) and lack of output schema, the description does well by explaining anchor types, destructive behaviors, and parameter groupings. It covers most essential context, though it could benefit from brief examples or more explicit guidance on action 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?

With 100% schema description coverage, the baseline is 3. The description adds significant value by organizing parameters by action ('Actions & required params' section), clarifying which parameters are required for each operation. This semantic grouping helps the agent understand parameter dependencies beyond what the schema provides individually.

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 performs 'comment operations on files' with specific verbs (list, add, delete) and resources (comments with various anchor types). It distinguishes itself from sibling tools like 'app-comments' by focusing on core comment management rather than application-specific 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 implied usage through the detailed action list and parameter requirements, showing when each action is appropriate. However, it lacks explicit guidance on when to choose this tool over alternatives like 'app-comments' or 'task' for workflow-related comments, and doesn't mention prerequisites or exclusions.

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

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

The description adds valuable behavioral context beyond annotations: it discloses that 'Downloads consume bandwidth credits'—a critical operational detail not covered by readOnlyHint or idempotentHint. While annotations already indicate safety (readOnlyHint: true, destructiveHint: false), this extra info enhances transparency for resource-aware decisions.

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: a clear purpose statement followed by a bulleted list of actions and their required parameters. Every sentence earns its place, with no redundant information, making it easy to scan 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?

Given the tool's complexity (8 parameters, 3 actions) and lack of output schema, the description is mostly complete: it covers purpose, actions, params, and a key behavioral trait (bandwidth usage). However, it omits details like response format or error handling, which could aid the agent, leaving room for slight improvement.

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 input schema already documents all parameters thoroughly. The description adds minimal value by listing required params per action, but this largely repeats schema info. It doesn't provide deeper semantics (e.g., format details), so the 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 tool's purpose with specific verbs ('Get download URLs') and resources ('files and folders'), distinguishing it from siblings like 'upload' or 'storage'. It enumerates three distinct operations, making the scope explicit and avoiding tautology.

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 the three supported actions and their required parameters, which implicitly guides when to use each. However, it lacks explicit guidance on when to choose this tool over alternatives (e.g., vs. 'upload' or 'storage') or any exclusions, keeping it from a perfect score.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating safe, non-destructive operations. The description adds useful context beyond this by specifying real-time polling capabilities and AI summarization, but does not disclose behavioral traits like rate limits, authentication needs, or response formats. With annotations covering safety, a 3 is appropriate as the description adds some value without 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 well-structured and front-loaded with a clear purpose statement, followed by a bulleted list of actions with required parameters. It efficiently conveys essential information without unnecessary fluff, though it could be slightly more concise by avoiding repetition in parameter lists (e.g., 'same filters as search').

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 (23 parameters, 5 actions) and rich schema/annotations, the description is adequate but has gaps. It lacks details on output formats, error handling, or pagination behavior, and there is no output schema to compensate. While it covers actions and parameters well, it doesn't fully address how results are returned or handled, making it minimally viable but incomplete.

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 all 23 parameters. The description adds semantic value by grouping parameters under specific actions (e.g., 'search: (all filter params optional...)'), clarifying usage contexts, and providing examples like 'Focus on uploads' for user_context. This enhances understanding beyond the schema's technical details, though it doesn't fully compensate for the lack of output 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 clearly states the tool's purpose with specific verbs and resources: 'Search audit events, get AI summaries of activity, view event details, and poll for real-time activity updates on workspaces and shares.' It distinguishes itself from sibling tools by focusing exclusively on event logging and activity monitoring, which is unique among the listed siblings like 'storage', 'comment', or 'workspace'.

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 each action (search, summarize, details, activity-list, activity-poll) based on specific needs like filtering, summarizing, or real-time updates. However, it does not explicitly state when not to use this tool versus alternatives (e.g., using 'storage' for file operations instead of event monitoring), which prevents a perfect score.

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

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

The description adds significant behavioral context beyond the annotations. While annotations indicate destructiveHint=true, the description elaborates specifically that 'delete removes the pending member from the member list and unassigns their workflow items (tasks, approvals, todos).' It also explains state support differences between workspace and share, and provides action-specific parameter requirements.

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

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

The description is efficiently structured with a clear purpose statement followed by a bulleted list of actions with their required parameters. Every sentence earns its place by providing essential operational guidance. The destructive warning is appropriately highlighted without 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?

For a complex tool with 10 parameters, 4 actions, and no output schema, the description provides strong operational guidance. It covers all actions, specifies parameter requirements, and adds important behavioral context. The main gap is the lack of information about return values or response formats, 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?

With 100% schema description coverage, the baseline is 3. The description adds value by organizing parameters by action ('Actions & required params'), clarifying which parameters are required for each operation, and providing context about destructive consequences. However, it doesn't add significant semantic meaning beyond what's already well-documented in the schema.

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

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

The description clearly states the tool's purpose as 'Invitation management for workspaces and shares' and specifies four distinct actions (list, list-by-state, update, delete), making it highly specific. It differentiates itself from sibling tools like 'member' or 'workspace' by focusing exclusively on invitation operations rather than general member or workspace management.

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 each action, including required parameters and optional ones. It specifies that 'list-by-state' is 'workspace only' and distinguishes between 'notifications' for workspace and 'notify_options' for share. The destructive warning for 'delete' also helps guide usage decisions.

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

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

The description adds significant behavioral context beyond annotations. While annotations indicate destructiveHint=true, the description explicitly marks specific actions as '[DESTRUCTIVE]' (remove, transfer-ownership, leave) and explains what 'remove' does ('revokes a member's access'). It also describes member list behavior ('includes both active and pending members') and pending member capabilities ('can be assigned tasks, approvals, and todos'), providing valuable operational context not captured in 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 well-structured with a clear opening statement, bullet-point action list, and organized parameter mapping. While comprehensive, some sentences could be more concise (e.g., the long parenthetical about pending members). The information is front-loaded with the core purpose, but the detailed parameter section is necessary given the tool's complexity.

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 complex tool with 8 actions, 17 parameters, and no output schema, the description provides substantial context. It covers actions, parameter mapping, destructive behaviors, and member status details. The main gap is lack of output information (what each action returns), which would be important given the absence of an output schema. However, the description compensates well with operational guidance.

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

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

With 100% schema description coverage, the schema already documents all 17 parameters thoroughly. The description adds value by grouping parameters by action ('Actions & required params'), showing which parameters are required for each operation and noting optional ones. This provides practical usage context beyond the schema's technical documentation, though it doesn't add new semantic meaning to individual 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's purpose as 'Member management for workspaces and shares' and lists all 8 specific actions (add, remove, update, transfer-ownership, etc.). It distinguishes this tool from siblings by focusing exclusively on membership operations, unlike tools like 'workspace', 'share', or 'invitation' which handle broader entity management.

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 through the action list and parameter requirements, but doesn't explicitly state when to use this tool versus alternatives. For example, it doesn't clarify when to use 'member' vs 'invitation' or 'user' tools, nor does it mention prerequisites like authentication requirements or permissions needed to perform actions.

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

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

The description adds substantial behavioral context beyond annotations. Annotations indicate destructiveHint=true and readOnlyHint=false, but the description explicitly marks specific actions as '[DESTRUCTIVE]' (e.g., 'close', 'billing-cancel', 'remove-member', 'asset-delete'), clarifies side effects ('billing-create/billing-activate change subscription state, create consumes credits'), and notes special requirements ('transfer-token-list (requires agent account type)'). This provides crucial operational details that annotations alone don't convey.

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 front-loaded with a clear purpose statement and key behavioral disclosures. However, the extensive list of 44 actions with parameter notes makes it quite long. While each action entry serves a purpose, the description could be more concise by grouping similar actions or using a table format. The structure is logical but verbose.

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 high complexity (54 parameters, 44 actions, no output schema), the description provides exceptional completeness. It covers purpose, behavioral traits, destructive actions, side effects, account requirements, and parameter mappings for all actions. The combination of the comprehensive description with the fully documented schema (100% coverage) gives the agent everything needed to correctly invoke this complex tool despite the lack of 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?

With 100% schema description coverage, the schema already documents all 54 parameters thoroughly. The description adds value by organizing parameters by action in the 'Actions & required params' section, showing which parameters are required/optional for each operation. This provides semantic grouping that helps the agent understand parameter context, though it doesn't add new semantic information beyond what's in 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 begins with a clear, comprehensive statement: 'Organization management. Core CRUD, billing/subscription, member management, invitations, ownership transfer, asset management, discovery, and custom domains.' This explicitly states the tool's purpose as a multi-faceted organization management system, distinguishing it from sibling tools like 'member', 'workspace', or 'asset' which handle more specific aspects. The verb 'management' coupled with the detailed resource scope provides excellent specificity.

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 by listing all available actions (e.g., 'list', 'create', 'update', 'close', 'billing-create', 'invite-member'). This implicitly guides usage for organization-level operations. However, it doesn't explicitly state when NOT to use it or name specific alternatives among sibling tools (e.g., when to use 'member' tool vs. the member-related actions here). The guidance is comprehensive but not comparative.

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

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

The description adds significant behavioral context beyond what annotations provide. Annotations indicate readOnlyHint=false, openWorldHint=true, and destructiveHint=true. The description elaborates with specific destructive warnings ('delete permanently removes the share'), authentication details ('password auth'), rate limit implications ('anonymous file drops'), and operational constraints ('Supports anonymous file drops on Receive/Exchange shares'). It also clarifies scope boundaries with the 'member' tool.

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 front-loaded with the core purpose, but the extensive parameter-by-action listing makes it quite long. While every sentence serves a purpose, the structure could be more concise - the parameter listing duplicates information available in the schema, though it adds valuable action-based organization. The description earns its length but could potentially be more streamlined.

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 high complexity (36 parameters, multiple actions) and lack of output schema, the description provides substantial context. It covers destructive behavior, authentication needs, sibling tool relationships, and action-specific parameter requirements. However, without an output schema, it doesn't describe return values or response formats, which would be helpful for a tool with this many possible actions.

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?

Despite 100% schema description coverage, the description adds crucial parameter semantics by organizing parameters by action in the 'Actions & required params' section. This provides operational context that the schema alone doesn't offer - showing which parameters are required for each specific action (e.g., 'create: workspace_id, name or title'), which helps the agent understand parameter dependencies and usage patterns beyond individual parameter 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 starts with a clear, specific purpose statement: 'Share management. Create, list, view, update, delete shares.' It explicitly distinguishes this tool from the 'member' tool by stating 'full member management is in the 'member' tool,' showing clear sibling differentiation. The description covers multiple specific operations with distinct verbs and resources.

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 about when to use certain actions (e.g., 'Member listing included; full member management is in the 'member' tool') and includes explicit guidance like 'Destructive action: delete permanently removes the share.' However, it doesn't provide explicit alternatives for when to use this tool versus other sibling tools (like 'workspace' or 'storage'), only distinguishing from 'member' specifically.

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

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

The description adds significant behavioral context beyond annotations: it clarifies the difference between delete (moves to trash) and purge (permanent destruction), explains that 'recent' lists across entire workspace/share (not scoped to folders), notes intelligence requirements for semantic search, and specifies size limits for read-content. Annotations already indicate destructiveHint=true and readOnlyHint=false, which the description reinforces by labeling destructive actions.

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 purpose statement but becomes a lengthy bulleted list of actions and parameters. While comprehensive, this structure is verbose (35+ lines) and could be more efficiently organized. Every sentence earns its place by providing necessary information, but the format isn't optimally concise.

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 high complexity (23 actions, 35 parameters) and lack of output schema, the description provides excellent coverage of operations, parameters, and behavioral nuances. However, it doesn't describe return values or error conditions, which would be helpful for a tool with this many actions. The annotations provide safety context, but output behavior remains unspecified.

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?

Despite 100% schema description coverage, the description adds crucial parameter semantics by mapping each action to its required parameters (e.g., 'list: node_id (+ optional: sort_by, sort_dir, page_size, cursor)'), clarifying which parameters are action-specific. This provides operational context that the schema alone doesn't offer, helping the agent understand parameter dependencies across 23 different actions.

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 explicitly lists all 23 specific operations (list, search, create folders, copy, move, delete, rename, etc.) with their required parameters, clearly distinguishing this as a comprehensive file/folder management tool. It differentiates from sibling tools like 'upload', 'download', 'share', and 'ai' by focusing on storage operations rather than upload workflows, sharing mechanisms, or AI features.

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 specific actions (e.g., 'delete moves to trash (recoverable via restore)', 'purge permanently destroys a trashed node (irreversible)'), and indicates workspace-only restrictions for 'trash-list' and 'add-link'. However, it doesn't explicitly mention when to use this tool versus alternatives like 'upload' for file uploads or 'share' for sharing 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?

The description adds significant behavioral context beyond the annotations. While annotations indicate destructiveHint=true and readOnlyHint=false, the description specifies that destructive actions involve 'soft-deletes' (not permanent deletion), clarifies that responses include 'created_by' (user ID of creator), details permission requirements for shares, and explains that move-task requires target list to be 'in the same profile as the source list.' This provides rich 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 well-structured with a clear opening statement followed by detailed action listings. While comprehensive, it's appropriately sized for a complex tool with 18 actions and 26 parameters. Every sentence serves a purpose, though the action list is lengthy but necessary for clarity. It could be slightly more front-loaded with key usage patterns.

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 high complexity (26 parameters, 18 actions, no output schema), the description provides exceptional completeness. It covers all major aspects: purpose, detailed action breakdown with parameters, behavioral traits (soft-deletes, permissions, constraints), and practical usage notes. The combination of comprehensive action listings and behavioral context fully compensates for the lack of 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?

Despite 100% schema description coverage, the description adds substantial parameter semantics through the 'Actions & required params' section that maps specific actions to their required and optional parameters. It clarifies relationships between parameters (e.g., 'status [required when filter=status]'), provides practical usage context (e.g., 'pass null to unassign' for assignee_id), and explains parameter interactions that aren't in the schema 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 as 'Task management operations' with specific verbs like 'Create and manage task lists and individual tasks' and details the scope including workspaces and shares. It distinguishes itself from sibling tools like 'todo' by specifying comprehensive task management with statuses, priorities, assignees, dependencies, and bulk operations.

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 with the 'Actions & required params' section that lists 18 specific operations, each with required and optional parameters. It includes contextual notes like 'On shares, requires admin or named member role' and identifies destructive actions (delete-list, delete-task), giving clear when-to-use guidance for different scenarios.

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

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

The description adds significant behavioral context beyond annotations. Annotations indicate readOnlyHint=false and destructiveHint=true, but the description elaborates with: 'Destructive action: delete soft-deletes a todo,' clarifying the nature of destruction. It also specifies permission requirements (workflow enabled, admin/member role on shares) and response details ('Responses include `created_by` (user ID of creator)'), which are not covered by 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 well-structured and front-loaded with a clear purpose, followed by usage guidelines and a detailed parameter mapping. Every sentence adds value, such as explaining destructive actions and permissions. However, it is slightly verbose due to the extensive parameter list, which is necessary but reduces conciseness, warranting a score of 4 rather than 5.

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

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

Given the tool's complexity (17 parameters, multiple actions) and the absence of an output schema, the description is highly complete. It covers purpose, usage guidelines, behavioral traits (e.g., soft-delete, permissions), and parameter semantics in detail. This compensates for the lack of output schema and provides sufficient context for an agent to use the tool 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 description adds valuable parameter semantics beyond the input schema, which has 100% coverage. It maps actions to required and optional parameters in a clear list (e.g., 'list: profile_type, profile_id (+ optional: sort_by, sort_dir, filter_done, limit, offset, format)'), helping the agent understand which parameters are needed for each operation. This goes beyond the schema's generic descriptions, though it doesn't fully explain all 17 parameters' nuances, so it scores 4 instead of 5.

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: 'Todo checklist operations. List, create, view, update, delete, toggle, and bulk-toggle todos scoped to workspaces and shares.' It specifies the exact verbs (list, create, etc.) and resources (todos), and distinguishes itself from siblings by focusing on todo operations rather than other entities like tasks, comments, or assets.

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 the tool: 'Requires workflow to be enabled on the target entity (workspace action enable-workflow or share action enable-workflow). On shares, requires admin or named member role.' However, it does not explicitly mention when not to use this tool or name specific alternatives among siblings (e.g., task tool), which prevents a score of 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 adds significant behavioral context beyond annotations: it discloses side effects ('finalize/stream creates new files that consume storage credits'), destructive actions (marked with [DESTRUCTIVE] for cancel, cancel-all, chunk-delete, web-cancel), and technical constraints (blobs expire after 5 minutes, single-use, bypasses MCP transport limits, up to 100 MB). Annotations only provide readOnlyHint=false and destructiveHint=false, so the description carries most of the burden effectively without contradiction.

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 (UPLOAD STRATEGY, STREAM MODE, etc.), but it is lengthy and includes some redundant details (e.g., repeating POST /blob sidecar information). While informative, it could be more concise by eliminating repetition and tightening explanations, as not every sentence earns its place efficiently.

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 high complexity (30 parameters, no output schema) and rich schema coverage, the description is largely complete. It covers upload strategies, side effects, destructive actions, and parameter semantics. However, it lacks explicit information on error handling or response formats, which would be beneficial for a tool with no output schema, leaving minor gaps in full contextual understanding.

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 baseline is 3. The description adds value by explaining parameter interactions and conditional requirements: 'When stream=true, filesize is optional', 'When target_node_id is provided, parent_node_id is ignored and filename is optional', and clarifying exclusive choices like 'content | blob_id (exactly one)'. It also groups parameters by action in the 'Actions & required params' section, enhancing understanding 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 explicitly states 'File upload operations' and details multiple upload strategies (chunked, streaming, web URL imports), providing specific verbs and resources. It clearly distinguishes this tool from sibling tools like 'download' by focusing on upload functionality, with no tautology present.

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 different upload strategies: 'For files with a URL: use `web-import`', 'For files with known size: create-session → POST to /blob → chunk with blob_id → finalize', and 'For files with unknown size: create-session with stream=true → POST to /blob → stream with blob_id'. It also advises against alternatives like 'don't delete+reupload' for updates.

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

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

The description adds significant behavioral context beyond annotations. While annotations indicate destructiveHint=true and readOnlyHint=false, the description explicitly calls out destructive actions ('close permanently deletes the account', 'asset-delete: [DESTRUCTIVE]'), specifies required parameters for each action, and clarifies optional parameters. This provides crucial operational details that annotations alone don't cover.

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 front-loaded with a clear purpose statement, but the detailed action-parameter list is lengthy (16 actions with parameter notes). While this information is valuable, it could be more structured (e.g., bullet points) for better readability. Every sentence earns its place, but the format is somewhat dense.

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 (17 parameters, 16 actions, no output schema), the description is largely complete. It covers purpose, actions, parameters, and destructive behaviors. The main gap is lack of output format details (e.g., what 'me' returns), but with annotations providing safety context and the schema covering parameters, it's sufficient for most use cases.

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?

Despite 100% schema description coverage, the description adds substantial value by mapping parameters to specific actions. It clarifies which parameters are required for which actions (e.g., 'update: first_name | last_name | email_address (at least one)'), indicates destructive parameters, and shows optional parameters. This action-parameter mapping is not in the schema and is essential for correct tool invocation.

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: 'User profile and account management' with specific verbs like 'View/update profile, search users, manage invitations, and handle user assets.' It distinguishes itself from siblings like 'auth', 'member', and 'invitation' by covering a comprehensive set of user-related operations beyond authentication or specific invitation handling.

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 specific actions (e.g., 'close: confirmation [DESTRUCTIVE]' for account deletion) and implies usage through action-parameter mappings. However, it lacks explicit guidance on when to choose this tool over alternatives like 'auth' for authentication or 'invitation' for invitation management, though the broad scope suggests it's the primary user management tool.

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

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

The description adds valuable behavioral context beyond annotations: it specifies that entries are 'append-only and permanent', discloses role requirements ('requires admin or named member role' for shares), and explains the acknowledgment system for interjections. Annotations only indicate it's not read-only and not destructive, so the description meaningfully supplements this with operational details.

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 core purpose and usage, but the lengthy 'Actions & required params' section is somewhat redundant given the comprehensive schema. While informative, it could be more concise by focusing on semantic guidance rather than restating parameter lists. The structure is logical but not optimally 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?

For a complex tool with 15 parameters, 9 actions, and no output schema, the description does a good job of explaining the tool's purpose, behavior, and parameter usage. It covers key aspects like permanence, role requirements, and the acknowledgment system. However, it doesn't detail response formats or error handling, leaving some gaps given the tool's complexity.

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 baseline is 3. The description adds significant value by organizing parameters into action-specific groups (e.g., 'append: entity_type, entity_id, content'), clarifying the relationship between actions and their required parameters, and providing semantic context like 'urgent correction requiring acknowledgement' for 'interject'. This goes well beyond the schema's technical documentation.

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 as an 'Activity log for tracking agent work' with specific verbs like 'log', 'create', and 'builds a searchable audit trail'. It distinguishes itself from siblings by focusing exclusively on worklog/audit trail functionality, unlike other tools for tasks, comments, or uploads.

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 the tool: 'after uploads, task changes, share creation, or any significant action' and for 'urgent interjections that require acknowledgement'. It doesn't explicitly mention when NOT to use it or name specific alternatives among siblings, but the context is sufficiently detailed for informed usage.

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 provide readOnlyHint=false, destructiveHint=true, and openWorldHint=true. The description adds valuable context beyond annotations: it explicitly marks destructive actions (delete, quickshare-delete, metadata-template-delete, metadata-delete), warns about credit costs for intelligence enabling, explains async behavior for metadata-extract, and details constraints like note type restrictions and large-content handling. No contradiction with annotations.

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

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

The description is excessively long and poorly structured—it reads like a parameter reference manual rather than a concise overview. While information-dense, it lacks front-loading of key concepts, making it hard to scan. Many details (e.g., specific error codes, versioning mechanics) could be trimmed or moved elsewhere.

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 high complexity (38 parameters, multiple actions) and lack of output schema, the description attempts to cover many aspects but remains overwhelming. It includes behavioral notes, async patterns, and warnings, yet fails to provide a clear high-level summary or expected return formats, leaving gaps for agent comprehension.

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 schema already documents all 38 parameters thoroughly. The description adds meaningful semantics by clarifying parameter usage per action (e.g., 'exactly one of content OR blob_id' for create-note, 'confirm [DESTRUCTIVE]' for delete), explaining interdependencies, and providing practical examples like blob handling for large notes.

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 starts with 'Workspace management' and lists specific operations (list, view details, update settings, etc.), clearly stating what the tool does. It distinguishes itself from sibling tools like 'storage' or 'share' by focusing on workspace-level operations, though it doesn't explicitly compare to siblings.

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

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

The description provides implied usage guidance through action-specific notes (e.g., 'use this for markdown you plan to edit incrementally from an agent' for create-note, warnings about destructive actions). However, it lacks explicit when-to-use vs. alternatives (e.g., when to use workspace vs. storage tools) or clear prerequisites.

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