Fast.io

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

The description adds behavioral context beyond annotations by specifying credit consumption, idempotent cancellation, and per-action destructiveness. Annotations only indicate possible destructive behavior; description clarifies which action is destructive.

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 dense but well-structured, front-loading purpose and key guidance. It efficiently covers scope, instructions, destructive actions, side effects, and verbosity. Some details could be delegated to 'describe' reference, but overall it earns its length.

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 (22 parameters, 15 actions, no output schema), the description provides high-level guidance and points to 'describe' for details. It covers side effects and defaults but does not explain output formats. It is reasonably complete for the context.

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 baseline is 3. The description adds value by recommending 'describe' for action and explaining verbosity defaults based on action type, providing context not in 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 domain: 'AI RAG chat, document analysis, shareable summaries on workspaces and shares.' It distinguishes itself from sibling tools (e.g., app-comments, app-file-picker) by focusing on AI operations. The use of 'action' parameter for sub-tasks is highlighted.

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 advises calling action='describe' for full reference and explains side effects for credit-consuming actions and idempotency for chat-cancel. It also notes verbosity defaults. However, it does not explicitly state when to use this tool over alternatives.

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

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

The description states the tool can 'add and delete comments', implying mutations, while annotations set readOnlyHint to true. This is a direct contradiction. No additional behavioral details beyond the annotated hints are provided to resolve this inconsistency.

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 structurally clear, with a feature list and separate parameter section. While somewhat verbose, it efficiently conveys the tool's capabilities and key details without significant redundancy.

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

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

The description lacks information about the tool's return value or output behavior (no output schema defined). Combined with the readOnlyHint contradiction, the description is incomplete for understanding the tool's full behavior, especially for a widget-launching tool.

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

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

Schema description coverage is 100%, so the description adds minimal value beyond the schema. It repeats parameter descriptions already present, such as for node_id and file_name. No further semantic enrichment 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 launches a Comments MCP App widget and lists its capabilities (view, add, delete, threading, reactions, etc.). However, it does not explicitly distinguish itself from the sibling 'comment' tool, which could indicate a simpler comment operation.

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

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

The description mentions supported contexts (workspace, share) and optional parameters, but lacks explicit guidance on when to use this tool over alternatives like 'comment'. The usage context is implied but not contrasted.

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 claims the tool supports write operations (upload, delete, rename) while the annotations have readOnlyHint=true, creating a contradiction. Additionally, it lacks disclosure of behavioral traits beyond the contradictory 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 front-loads the main purpose in the first sentence, but the second sentence is lengthy and covers many features, slightly reducing conciseness.

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

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

The tool is complex with many operations and no output schema, yet the description does not explain what the tool returns (e.g., selected file identifiers). It also conflates multiple file management actions without clarifying their boundaries.

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 explains the parameters. The description only restates profile_type and profile_id without adding new semantic meaning beyond what the schema provides.

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

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

The description clearly states that the tool launches a File Picker widget for browsing, picking, and managing files, distinguishing it from siblings like app-file-viewer (view only) and app-uploader (upload 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 specifies when to use the tool (to browse, pick, and manage files) but does not explicitly state when not to use it or list alternatives among siblings, though the context is clear.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context: always dark mode, keyboard navigation, slide-out info panel with version history and AI summary. This supplements the annotations 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 concise (4-5 lines) and front-loaded with the core purpose. It efficiently lists features and parameters without unnecessary elaboration. Minor improvement: could use bullet points for better scannability.

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 (multi-format preview, version history, AI summary) and lack of output schema, the description covers key features adequately. However, it omits error behavior (e.g., what happens on invalid node_id) and return value specifics (e.g., does it return a URL or embed the viewer?).

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

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

Schema coverage is 100%, so the description adds marginal value beyond the schema. It lists parameters in a readable format and clarifies some details (e.g., '19-digit ID' for profile_id, 'Storage node opaque ID' for node_id). However, this information is already present 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 File Viewer MCP App widget' and details its multi-format preview capabilities. It distinctly positions itself as a unified file preview tool, differentiating from siblings like app-file-picker (selection) and download (raw retrieval).

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

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

The description implicitly conveys usage for previewing files, but lacks explicit guidance on when to use this tool versus alternatives (e.g., when to use app-file-viewer vs. download or app-comments). No when-not-to-use or prerequisites are mentioned.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. Description adds specifics: 'Destructive: delete, bulk-delete' and directs to the 'describe' action for full parameter reference, providing additional behavioral context beyond annotations.

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

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

Two concise sentences covering purpose, actions, scope, and destructive behavior. Efficient and front-loaded, though the instruction to call 'describe' could be integrated more naturally.

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?

Despite high parameter count (21) and complexity, description only provides high-level actions and delegates to the 'describe' action. Without calling that first, the description is insufficient for full tool usage. No explanation of action semantics or prerequisites.

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

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

Schema coverage is 100%, so baseline is 3. Description does not add meaning to individual parameters beyond what schema provides. The meta-instruction to use 'describe' action is helpful but not parameter-level semantics.

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

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

Clearly states it's an 'Approval workflow' with a list of actions (list, create, resolve, update, delete) and scope (workspaces/shares). Differentiates from sibling tools like task or comment by focusing on approval-specific 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?

No guidance on when to use this tool versus alternatives or when not to use it. Mentions calling action='describe' for reference, but does not provide context or exclusions for different use cases.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds that it handles UI widgets and suggests 'describe' for details, no contradiction. Slight value beyond annotations.

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

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

Two sentences, immediately clear and efficient. Every sentence adds value: defines purpose and provides actionable guidance.

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

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

With 8 parameters and 5 actions, the description is too minimal. It lacks explanation of which action to use when, parameter roles (like app_id, tool_name, context_id), and return behavior. The 'describe' suggestion helps but insufficient for a complex tool.

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

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

Schema coverage is 100%, so baseline 3. Description does not add parameter-specific meaning; it only references the 'describe' action for full reference. No extra value beyond 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 lists and launches interactive UI widgets (file browser, etc.), distinguishing it from sibling tools that are more app-specific. It also instructs to use action='describe' for full reference.

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

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

The description implies use for launching UI widgets but does not explicitly contrast with sibling tools like app-comments, app-file-picker, etc. No when-not or alternative guidance.

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

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

The description claims the tool performs file uploads (mutation), but annotations indicate readOnlyHint: true and destructiveHint: false, implying no side effects. This is a clear contradiction, scoring 1 per rubric.

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 relatively concise but the opening phrase 'Launch the Upload Files MCP App widget' is unclear and wastes the front-load. The content is brief but lacks clarity, reducing effectiveness.

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

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

The description does not explain the outcome of calling the tool (e.g., UI widget launched, files uploaded, return value). It mentions features like chunked uploads and progress tracking but lacks completeness given the contradictory annotations and absence 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?

Schema coverage is 100%, so baseline is 3. The description restates two parameters (profile_type, profile_id) but does not clarify the alias parameters (context_id, context_type) or when to use them, adding minimal value 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 is ambiguous: it says 'Launch the Upload Files MCP App widget' which suggests opening a UI, but then says 'Upload files to a workspace or share' which implies actual file transfer. It does not clearly state the tool's primary action, especially when compared to siblings like 'upload' or 'app-file-picker'.

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

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

No guidance on when to use this tool instead of siblings like 'upload' or 'app-file-picker'. The description lists parameters but does not provide context for selection or 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?

Annotations declare readOnlyHint=true, yet the description mentions 'create/resolve actions' and 'inline add and bulk toggle' which imply writes, creating a contradiction. Beyond annotations, the description does not clarify behavior (e.g., opens UI widget, no side effects). No explicit statement about safety or idempotency.

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 moderately sized, front-loaded with purpose, and each sentence adds information. It could be slightly more concise but avoids 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?

Given the complexity (multiple features) and lack of output schema, the description adequately enumerates widget capabilities. However, it fails to explain what the tool returns or any side effects, and behavioral concerns are unaddressed. Annotations compensate partially but not fully.

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 covers all 4 parameters with descriptions (100% coverage). The description adds aliases (context_id, context_type) and clarifies the 19-digit ID format, providing marginal extra value beyond the schema. 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 it launches the Workflow Manager MCP App widget and details its unified interface features (Kanban, approvals, todo, worklog). It distinguishes from sibling tools by specifying a comprehensive workflow management scope, which no sibling explicitly covers.

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

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

The description mentions support for workspace and share contexts via profile_type and profile_id, and provides aliases. However, it lacks explicit guidance on when to use this tool versus alternatives like task, todo, or worklog, nor does it state when not to use it.

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

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

Annotations indicate readOnlyHint=true, but the description mentions creating workspaces and shares via wizards. This could be confusing; however, the tool is just a launcher and the mutations occur within the widget. The description adds context about wizard steps and real-time checks, but doesn't explicitly clarify that the tool itself does not perform mutations.

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

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

The description is concise with two paragraphs and a parameter line. It front-loads the main action and is efficient, though the parameter list could be better integrated.

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

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

The description covers the tool's core functionality (launching a picker with search/filter and creation wizards), but does not specify return behavior or what the agent receives upon invocation. Given no output schema, this is a gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mentions 'profile_type (workspace or share)' and 'profile_id (19-digit ID)', which repeats schema info. It adds no significant new meaning beyond what the schema already provides.

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

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

The description clearly states the tool launches a 'Workspace Picker' widget for managing workspaces and shares, with specific functionalities like selection, search, filtering, and creation wizards. It distinguishes itself from sibling tools like 'workspace' and 'share' which are likely CRUD operations, by being a UI launcher.

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 does not provide explicit guidelines on when to use this tool versus alternatives like direct CRUD tools for workspaces or shares. It implies usage for selection and creation via a UI, but lacks when-not or alternative references.

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 mentions that delete is destructive, which aligns with the destructiveHint=true annotation. However, it does not elaborate on other behavioral traits such as authorization requirements, idempotency, or side effects beyond deletion. The annotation already signals destructiveness, so the description adds minimal additional 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 concise (two sentences) and front-loaded with the core purpose. The mention of 'Destructive: delete' is slightly redundant given the annotation, but does not detract significantly. It could be slightly 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 complexity (10 parameters, no output schema) and the presence of many sibling tools, the description is adequate. It covers the main operations and directs the agent to use 'describe' for full details. However, it lacks information about return values or error scenarios, which may necessitate the agent calling describe first.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds the suggestion to use action='describe' for a full reference, but does not elaborate on individual parameters beyond what the schema provides. No additional semantic value is given.

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 that the tool manages brand assets (logos, banners, profile photos) on specific entities, and lists the major operations (upload, delete, list, read). This distinguishes it from sibling tools like generic upload/download or app-uploader, which likely handle non-brand 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?

While the description implies usage for brand assets, it does not provide explicit guidance on when to use this tool versus alternatives like 'upload' or 'download'. No exclusions or alternative tool mentions are given, leaving the agent to infer context.

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

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

The description explicitly names destructive actions (api-key-delete, oauth-revoke, oauth-revoke-all), adding value beyond the destructiveHint annotation. It also highlights the tool's scope but omits other behavioral traits like rate limits or request/response patterns.

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 relatively concise with three sentences covering scope, guidance, and destructive actions. It is front-loaded with key info, though the first sentence could 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 complexity (22 parameters, many sub-actions) and no output schema, the description leaves gaps—it does not explain return values or common usage patterns. However, it directs to 'describe' for details, which mitigates incompleteness.

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

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

The input schema has 100% coverage with descriptions for all 22 parameters. The description does not add additional parameter-level meaning beyond what the schema provides, matching the baseline.

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

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

The description clearly defines the tool as handling auth and sessions, listing major features like signin, signup, 2FA, etc. However, it is a broad list rather than a concise verb+resource, slightly reducing 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 only usage guidance is to call action='describe' for full reference. There is no explicit advice on when to use this tool over others (though no alternative auth tools exist) and no conditions or prerequisites for 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 significant behavioral context beyond annotations. It confirms which actions are destructive (delete, bulk-delete), explains verbosity defaults ('list/list-all/linked default to terse, details defaults to full'), mentions character limits and mention syntax, describes anchoring capabilities (image regions, timestamps, PDF pages), and notes single-level threading. No contradiction with annotations (readOnlyHint=false, destructiveHint=true).

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 capabilities and uses multiple short sentences to convey complex information. It is efficiently structured given the tool's complexity (22 parameters, 11 actions). However, it could be slightly more concise by grouping related details, and it's not minimal—but appropriate for the scope.

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 (many actions, parameters, nested objects), the description covers essential behaviors: destructive actions, verbosity defaults, anchoring, linking, and character limits. It directs users to 'describe' for full reference, compensating for lack of output schema. Some details (e.g., context vs profile IDs) rely on schema, but overall it's very complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the 'detail' parameter defaults ('terse for list/list-all/linked, full for details') and noting aliases (context_id for profile_id). It also mentions the 'describe' action for full param reference. While schema descriptions already cover most fields, the description's contextual notes enhance understanding.

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: 'Comments on files: add/list/delete/react, anchor to image regions, A/V timestamps, PDF pages, or text selections, link to tasks/approvals.' It specifies the verb (comment) and resource (files) and enumerates supported actions, making it highly specific and unambiguous. While not explicitly differentiating from siblings like 'app-comments', the scope is well-defined.

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 usage guidance: it advises to 'Call action='describe' for the full action/param reference' and explicitly flags destructive operations ('Destructive: delete, bulk-delete'). It also explains verbosity defaults for different detail levels. However, it does not directly compare to sibling tools or specify when not to use this tool, 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it consumes bandwidth credits, which is a behavioral trait not captured by annotations. It also clarifies that the tool returns URLs (indirect downloads) rather than file data directly. No contradictions 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 two sentences: the first explains the three action modes, the second notes bandwidth cost and a discoverability hint. Every sentence is informative and there is no redundancy or fluff. Perfectly front-loaded.

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 8 parameters, no output schema, and annotations present, the description covers core functionality but omits details like URL expiry, authentication requirements, or whether repeated calls are needed. It is adequate but not comprehensive for a complex tool with multiple parameters.

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

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

Schema coverage is 100% with each parameter having a description. The description does not add meaning beyond the schema; it merely lists action options and mentions the 'describe' action. The baseline for high schema coverage is 3, and the description does not elevate it further.

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

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

The description clearly states it provides download URLs for three resource types (files, folder ZIPs, quickshare links). The verb 'Download URLs' is specific to the resource. However, it does not differentiate from sibling tools like app-file-viewer or storage that may also handle file retrieval, but the action enum explicitly defines the scope.

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 only guidance is 'Consumes bandwidth credits' implying cost, and a reference to use action='describe' for full reference. There is no explicit statement of when to use this tool vs. alternatives, such as using app-file-viewer for preview instead of download.

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 confirm read-only, idempotent, non-destructive. Description adds detailed behavioral context: long-polling via wait parameter, incremental polling via cursor/lastactivity, and action-specific verbosity. 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?

Description is moderately long but structured: first sentence states purpose, then explains actions and verbosity. Information is front-loaded and relevant. Could trim some redundancy but overall 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 tool with 23 parameters and no output schema, description covers core concepts (actions, verbosity, filtering, polling). Refers to describe action for full details. Lacks output structure but acceptable for monitoring tool.

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

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

Schema covers 100% parameters with descriptions. Description adds practical context (e.g., 'use describe for catalog', verbosity defaults). Does not explain every parameter beyond schema, but baseline of 3 is appropriate given full schema coverage.

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

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

Description clearly states 'Event log and activity monitoring for workspaces and shares.' It identifies the resource (events/activity) and the nature (monitoring). Differentiates from siblings like 'comment', 'task', etc., which are specific record types.

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?

Explains different actions (describe, search, summarize, etc.) and their use. Provides verbosity defaults per action and recommends calling action='describe' for full reference. Lacks explicit when-not-to-use but gives sufficient context.

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

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

Annotations already indicate destructiveHint=true. The description adds 'Destructive: delete,' which aligns with annotations but does not detail further behavioral traits like side effects of updates or revocations. With annotations covering the destructive nature, the description provides minimal additional 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 extremely concise, consisting of two short sentences. It front-loads the core purpose and operations, then adds a pointer to the 'describe' action and a note about destructiveness. No unnecessary words.

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

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

Despite high parameter count and multiple actions, the description is minimal. It does not explain how parameters relate to actions, nor does it describe return values. The suggestion to use 'describe' acknowledges incompleteness, making the tool harder to use without extra steps.

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

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

Schema coverage is 100%, so the input schema already fully documents all parameters. The description does not add any extra meaning or usage guidance for the parameters beyond what the schema provides, resulting in a baseline score of 3.

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 manages 'Workspace/share invitations' and lists the operations: list, filter by state, update, revoke. This is specific about the verb and resource, and distinguishes it from sibling tools like 'share' and 'workspace' which handle different 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 does not provide any guidance on when to use this tool versus alternative tools. It only suggests calling 'describe' for full action reference, but lacks explicit context for choosing between siblings or prerequisites.

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

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

Annotations already indicate destructiveHint=true. The description adds 'Destructive: remove', which aligns but does not disclose other behaviors like authentication or rate limits. No contradiction with annotations.

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

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

Two sentences efficiently convey the tool's purpose and a key usage hint. Could benefit from minor structural improvements, but overall no wasted words.

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

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

Despite high parameter count (17) and no output schema, the description only hints at using 'describe' for details. It omits return value expectations and error conditions, making it incomplete for a complex tool.

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

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

The description does not add meaning beyond the schema, which already covers all 17 parameters with 100% coverage. Baseline 3 is appropriate as the schema carries the full burden.

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 'Workspace/share member management' and lists specific actions (add, remove, update, etc.), making the verb and resource explicit. It is distinct from sibling tools like 'auth' or 'comment' which have different purposes.

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

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

The description advises calling action='describe' for full reference, guiding the agent to discover specific parameters. While it does not explicitly state when not to use this tool, the context of sibling tools (none are member-related) makes usage clear.

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

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

Annotations indicate destructiveHint=true and readOnlyHint=false. The description adds specific behavioral context: 'Destructive: close (permanently deletes org and all data)' and details on verbosity defaults for list/discover operations. This enriches the annotation data. It does not contradict annotations. However, it omits other behaviors like rate limits, idempotency, or authentication requirements, which would further improve 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 relatively concise but could be better structured. It front-loads the purpose quickly, then adds action reference, destructive note, and verbosity rules. However, the final sentence about verbosity is a bit clunky. The information is present but not organized in an easily scannable way.

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 (57 parameters, 60+ actions), the description provides a reasonable overview and a pointer to 'describe' for full details. It also highlights key behavioral aspects. However, it lacks guidance on which actions are suitable for what scenarios (e.g., when to use 'list' vs 'discover-all'). The absence of output schema or return value description is compensated by the action-reference strategy, but the description still feels incomplete for effective first-time 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?

The input schema has 100% description coverage for all parameters, so the description does not need to add much per-parameter meaning. It does add value by explaining the verbosity defaults and highlighting the destructive nature of 'close', but these apply to multiple actions. The description does not elaborate on uncommon parameters, so it meets the baseline.

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

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

The description clearly states 'Organization management: CRUD, billing, members, invitations, ownership transfer, assets, discovery, custom domains, AI instructions.' It provides a specific verb (manage) and resource (organization), and the enumeration of sub-areas makes the tool's scope immediately obvious. The mention of 'action=\'describe\' for the full action/param reference' further clarifies how to explore capabilities.

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

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

The description gives some usage guidance: it notes that destructive action 'close' deletes org and data, and explains verbosity defaults and how to override. However, it does not explicitly tell the agent when to use this tool versus sibling tools (e.g., workspace, member, asset). It implies that all org-related operations go here, but fails to compare with alternatives like 'workspace' or 'member' which might handle specific sub-areas. The instruction to call 'describe' is helpful but incomplete for selecting the 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 significant behavioral context beyond annotations: destructive delete is permanent, intelligence costs credits (10/page) and defaults to false, verbosity defaults per action, quickshare default expires are detailed. Annotations already indicate destructiveHint=true, but the description elaborates on specific risks and defaults without contradicting annotations.

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

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

The description is a single paragraph that front-loads key capabilities and important warnings (destructive, cost, verbosity). It is efficient given the tool's complexity, though it could benefit from bullet points for easier scanning. However, every sentence adds value, and the structure is logical.

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 41 parameters and lack of output schema, the description provides essential overarching context: actions list, cost warning, verbosity defaults, and a pointer to 'describe' action for full details. It covers the most critical aspects but could briefly summarize a few key actions (e.g., create vs. quickshare) to reduce reliance on 'describe'.

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 baseline is 3. The description adds extra context that enriches parameter understanding: it warns about intelligence credits, explains verbosity defaults for detail parameter, and highlights quickshare expiration defaults. This goes beyond the schema descriptions, which are present but less contextualized.

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 'Share management' and lists key actions (create/update/delete, archive, password auth, members, quickshare, AI instructions). It distinguishes this tool from sibling tools, which cover entirely different domains (ai, comment, apps, etc.), so there is no ambiguity about purpose.

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: 'Call action="describe" for the full action/param reference' and notes about destructive actions ('delete (permanent)') and cost implications of intelligence. However, it does not explicitly contrast with alternative tools, though siblings are largely unrelated, so this is less critical.

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

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

Annotations already indicate destructiveHint: true and readOnlyHint: false. The description adds useful nuance: 'Destructive: purge (irreversible). delete moves to trash.' It also explains verbosity defaults and the effect of the 'detail' parameter. This goes beyond the annotations by clarifying behavioral specifics, though it omits details on auth or rate limits.

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

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

The description is front-loaded with the main purpose and then provides specific guidance. It is somewhat lengthy due to the tool's complexity (37 parameters, many actions), but every sentence adds value. Could be slightly more concise, but overall it is well-organized.

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, lack of output schema, and annotations that partially cover destructive behavior, the description adequately covers key aspects like destructive operations and parameter defaults. However, it does not describe return values (since there is no output schema), and it could better explain aliases and the full action list without relying on action='describe'. It is adequate but has clear gaps.

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 coverage, the schema already describes each parameter. The description enhances this by explaining relationships (e.g., 'q is alias for query', 'context_id alias for profile_id') and providing context for the 'detail' parameter's default behavior and override options. This adds significant value beyond 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 broad scope: 'Files & folders on workspaces/shares: list, search, copy, move, delete, rename, trash, transfer, versions, locks, previews.' It enumerates specific actions and resources, and distinguishes from sibling tools like app-file-viewer by covering a comprehensive set of file 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 some guidance, such as 'Call action="describe" for the full action/param reference' and notes on destructive vs. non-destructive actions. However, it does not explicitly state when to use this tool over siblings (e.g., for file previews, there are specific tools). Lacks explicit 'when not to use' or alternative tool recommendations.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=true. The description adds specific destructive actions ('delete-list, delete-task'), providing additional context beyond the annotations. However, no details on rate limits or auth requirements are given.

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

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

The description is concise (3 sentences) and front-loaded with a general overview, followed by an instruction and a list of destructive actions. It is efficient, but for a tool with 27 parameters, it could be slightly more structured. Still, every sentence serves a purpose.

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?

Despite the tool's complexity (27 parameters, diverse actions, no output schema), the description is minimal. It does not cover return values, action-specific details, or how to use the many parameters. The rely on the describe action is a workaround, not full 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 baseline is 3. The description does not elaborate on parameter meanings beyond the schema; it merely points to the describe action for full reference, adding no extra semantic value.

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 manages task lists and tasks, listing features like statuses, priorities, assignees, dependencies, and bulk ops. It specifies the resource (tasks in workspaces/shares) and distinguishes from siblings by its comprehensive scope.

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 advises calling action='describe' for the full reference, but does not explicitly state when to use this tool versus alternatives or when not to use it. The guidance is indirect, lacking clear exclusions or comparison to siblings.

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

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

Annotations already declare destructiveHint=true; the description adds 'Destructive: delete' but no additional behavioral context (e.g., permissions, side effects). With annotations present, this is adequate but not enhanced.

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

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

The description is extremely concise: two sentences plus a note, front-loaded with purpose and actionable guidance. No wasted words.

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

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

For a tool with 18 parameters and no output schema, the description relies on the 'describe' action for full detail. It covers scope and destructive nature but omits return values, pagination, and operation-specific context.

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

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

Schema coverage is 100% with thorough descriptions for each parameter; the description lists operations but adds minimal meaning beyond what the schema provides, warranting the baseline of 3.

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

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

The description clearly states it manages todo checklists scoped to workspaces and shares, listing all supported operations (list, create, update, toggle, delete, etc.), and distinguishes it from sibling tools like 'task' by scoping.

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 explicitly advises calling action='describe' for full reference, but does not contrast with alternatives like 'task' or specify when not to use this 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?

Discloses side effects: file creation, storage credit consumption, overwrite behavior with versioning. Explains binary vs text handling, hard ceilings, and failure modes (code 10522). Adds context beyond annotations (destructiveHint).

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?

Well-organized with clear sections, bullet points, and prioritization. Every sentence adds value (warnings, defaults, alternative methods). No redundancy.

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

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

Covers all upload methods, error codes, parameter interdependencies, and side effects. For a complex tool with 35 parameters and many actions, the description is remarkably thorough, leaving no major gaps.

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 coverage, description adds rich semantics: explains when to use content vs content_base64 vs blob_id, relationship between filesize and chunking, and parameter dependencies (e.g., hash pairing). The 'UPLOAD STRATEGY' section ties parameters to use cases.

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

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

The description clearly states it handles file uploads with multiple methods (streaming, chunked, web import, batch), distinguishing from sibling tools like 'download'. The purpose is unequivocal.

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

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

Provides explicit decision strategy (UPLOAD STRATEGY) with conditions like 'Have a URL?', 'Have content but don't know exact size?', etc. Warns about common errors (e.g., guessing filesize) and recommends defaults. Directs to action='describe' for full reference.

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 indicate destructiveHint=true, and the description explicitly notes 'Destructive: close', which aligns well. No contradictions. It does not disclose other behaviors like authentication needs or side effects beyond the mention of 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 very concise (two sentences) and front-loaded with capabilities. However, it is arguably too sparse for a tool with 18 parameters and many actions, sacrificing completeness for brevity.

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 (18 parameters, many actions, no output schema), the description is incomplete. It fails to explain how actions relate to parameters or what to expect in responses, relying heavily on the 'describe' action to fill gaps.

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

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

Schema coverage is 100%, so the schema documents all parameters. The description does not add meaning beyond pointing to the 'describe' action for details. Baseline of 3 is appropriate.

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

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

The description lists key capabilities (profile, contacts, invitations, assets, AI instructions) and mentions the key action 'describe' for full reference. It is clear that this tool handles user-related management, but it does not explicitly differentiate from sibling tools like 'profile' or 'invitation'.

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

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

It advises calling action='describe' for full reference, which is helpful. However, it lacks explicit guidance on when to use this tool versus alternative tools like 'asset', 'contact', or 'invitation'.

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 indicate readOnlyHint=false and destructiveHint=false, but the description adds only 'append-only' and 'interjections requiring acknowledgement'. It does not disclose behavioral traits like mutation scope, permission needs, or side effects beyond the basic append nature.

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

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

The description is two sentences, concise and front-loaded with the tool's purpose. No wasted words, but could be slightly expanded for clarity.

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, many enums, no output schema), the description is insufficient. It does not explain return values or the behavior of different actions, relying on a call to action='describe' as a workaround.

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 baseline is 3. The description does not add additional meaning to the parameters beyond what is already 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 identifies the tool as an activity log, specifying 'append-only entries on tasks/profiles plus urgent interjections requiring acknowledgement'. This distinguishes it from sibling tools like 'comment' or 'event' by highlighting unique capabilities.

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 vs alternatives. It only instructs to call action='describe' for internal reference, but does not indicate appropriate contexts 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?

Annotations already indicate destructiveHint: true, and the description reinforces that by warning that delete destroys the workspace and all files. It adds value beyond annotations by disclosing that intelligence features cost credits (10/page) and are rate-limited, and by explaining verbosity defaults per action.

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 summary of actions, followed by key warnings and verbosity defaults. It is dense but each sentence adds value. It could be more structured (e.g., bullet points) but overall efficient.

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

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

Given the high complexity (44 parameters, many actions), the description covers essential high-level usage and important warnings. However, it does not detail return values (no output schema) and lacks per-action explanations, relying on the 'describe' action for full reference. Still, it provides enough context for an AI agent to understand the tool's scope and caution points.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some context beyond the schema (e.g., default verbosity, intelligence cost, note size limits), but does not systematically explain each parameter. The added value is marginal relative to the schema's existing 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 'Workspace management' and lists the broad categories of actions (list, details, update, delete, archive, members, notes, quickshares, share import, metadata, AI instructions, workflow/import toggles). It provides a high-level summary that distinguishes this tool from sibling tools like storage or share.

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

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

The description includes warnings about destructive delete and intelligence costing credits, but does not explicitly state when to use this tool versus alternatives. It lacks guidance on when not to use it or which sibling tool to use for related tasks (e.g., file storage). Implied context but no clear exclusions.

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