Fast.io

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered by structured data. The description reinforces the read-only nature and notes that answers carry citations, but adds little behavioral detail beyond the annotations (no rate limits, no pagination behavior). With annotations carrying the burden, a 3 is appropriate.

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

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

Three short sentences, front-loaded with the read scope and resource list, then the write-boundary, then the self-reference pointer. No wasted words despite covering a 7-action, 16-parameter 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 wide read tool with 16 parameters and no output schema, the description covers the domain, the read/write boundary, and defers detailed action semantics to action='describe', which is an effective completeness strategy. It does not explain return shapes for the citation or transaction actions, a minor 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 all 16 parameters — including the alias relationships and the `wait` long-poll semantics — are already documented in the schema. The description adds no parameter-level meaning beyond what the schema provides, only deferring to action='describe'. Baseline 3 applies.

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

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

States a specific domain ('Fastio AI chat (read)') and enumerates the resources covered: chats and their details, messages, a message's answer with citations, and AI credit transactions. It explicitly marks the read scope and names the sibling that handles writes, so an agent can separate it from `ai_manage` without opening either schema.

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?

Explicitly routes write operations to `ai_manage` and points to action='describe' for the full action/param reference, which is real usage guidance for a tool with seven actions. It stops short of saying when to pick each action (e.g. message-read vs message-details), so it is clear context without full 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 declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. The description adds value beyond that by identifying exactly which action is destructive (chat-delete) and by disclosing that ask, status, chat-create, and message-send consume AI credits. It stops short of stating reversibility or permission 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?

Three dense sentences, front-loaded with the write-vs-read distinction and the action inventory, with no filler. Every clause carries operational information (destructive action, cost, fallback reference).

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 20-parameter multi-action tool with no output schema, the description covers scope, destructive surface, cost, and the read alternative, and points to action='describe' for the full reference. It only lightly gestures at return content ('a cited answer', 'a workspace status summary'), which is the remaining 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% across all 20 parameters, so aliasing, enum meanings, and limits are already documented. The description adds only marginal parameter-level meaning, mainly tying credit consumption to specific actions; 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?

States a specific verb and resource ('Fastio AI chat (write)') and then enumerates the concrete action surface: ask, status, chat create/update/publish/cancel, message-send, share-generate. It also explicitly distinguishes itself from the read counterpart ('Reads are on `ai`'), so an agent can separate it from the sibling `ai` tool without opening the schema.

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?

Names the alternative for reads ('Reads are on `ai`') and flags the destructive action ('Destructive: chat-delete') plus the credit-consuming actions. It does not, however, explain when to pick one action over another (e.g. chat-publish vs share-generate), instead deferring to action='describe', which is a reasonable routing move but shifts the guidance out of the description.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that reads return an asset's bytes and that mutations live elsewhere, but says nothing about permission requirements, rate limits, or byte-return size/format.

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

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

A single front-loaded sentence: resource, scope, capabilities, then the exclusion. No padding whatsoever.

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 5-param read-only tool with full schema coverage and no output schema, the description covers scope, entities, and capabilities adequately. It omits the 'describe' action and any detail on what 'read bytes' returns, but those gaps are minor given the schema enumerates every action.

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 per-parameter descriptions and two enums, so the schema does the heavy lifting. The description's enumeration of operations (types, list, read) loosely maps to the action enum but adds no format or syntax detail beyond it. Baseline 3 applies.

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

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

States the resource concretely (brand assets: logos, banners, profile photos), the scoping entities (org, workspace, share, user), and the read operations performed (types, list, read bytes). An agent can distinguish this from asset_manage purely from the description.

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?

Explicitly routes writes to the sibling `asset_manage`, which is a clean when-not-to-use rule. It lacks a positive trigger statement ('use this when you need to inspect or retrieve assets'), but the read/write split with the alternative named is clear guidance.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds precision annotations cannot: it pinpoints that `delete` specifically is the destructive path, leaving `upload` non-destructive-by-capability. It stops short of describing what deletion removes (asset only vs. referencing entities) or any auth/permission 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?

Three short clauses, front-loaded with the resource and scope, followed by the destructive-action warning and the sibling pointer. No filler and nothing buried.

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

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

For a 10-parameter, multi-action tool with no output schema, the description covers scope, entity types, the destructive action, and the read alternative. The notable omission is the `describe` action, which the schema itself surfaces and the description never mentions.

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 all 10 parameters are already documented in the schema, and every field carries its own description. The tool description adds no parameter-level meaning beyond that, so the baseline applies.

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

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

Names the resource (brand assets: logos, banners, profile photos), the scope (org, workspace, share, user), and the two mutating verbs (upload, delete). It also explicitly distinguishes itself from the read-only sibling `asset`, so an agent can route without opening either schema.

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?

States the conditional split clearly: writes belong here, 'Reads are on `asset`.' It also flags which action is destructive. It gives no guidance on the third action (`describe`) or on when a given entity_type should be chosen over another.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description adds the useful behavioral boundary that all credential-mutating operations live on a different tool, preventing an agent from expecting write capability here. It does not mention auth requirements, rate limits, or error behavior, but those are lower-priority for a read-only inspection 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?

Two sentences, zero filler. The read scope is front-loaded and the routing constraint to `auth_manage` follows immediately, so the most decision-relevant information arrives first.

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

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

For a read-only tool with no output schema, the description covers the resource families an agent needs to recognize relevance and correctly routes writes elsewhere. It leaves the per-action semantics to the schema's `describe` action, which is a reasonable division of labor, though it does not hint at what `describe`/`check` return.

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% and each of the five parameters is documented in-schema, including the 11-value action enum and the `describe_action` modifier. The description adds no parameter-level syntax or format detail, so the baseline 3 applies.

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

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

States the specific resource and mode ('Fastio session and credential state (read)') and then enumerates exactly what is covered: sign-in check, session/scope details, email availability, 2FA status, API keys, OAuth sessions. It explicitly distinguishes itself from the sibling `auth_manage`, so an agent can pick between them without opening either schema.

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 names the alternative tool and the condition that selects it: mutations ('Sign-in, sign-up, 2FA changes, PKCE login and credential changes') go to `auth_manage`, everything read stays here. That is an explicit when/when-not routing rule, not an inference.

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 flag destructiveHint=true and readOnlyHint=false, but the description goes further by naming exactly which actions are destructive (api-key-delete, oauth-revoke, oauth-revoke-all) and which are refused. It also signals the auth/consent flow implicitly through the action vocabulary, giving the agent concrete per-action risk information that the boolean annotations cannot.

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 dense sentences that front-load the purpose before the enumeration, and every element earns its place (action groups, refusals, destructive list, read routing). Slightly list-heavy, but not padded.

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 25-parameter, action-dispatch tool with no output schema, the description is appropriately complete: it scopes the tool, names the alternatives, flags the destructive subset, and points to action='describe' for the per-action reference the schema declines to inline. Nothing critical is missing given the schema's own richness.

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% and the schema descriptions are unusually rich (per-action meaning of `code`/`token`, `scopes` syntax, `admin`/`account_settings` ceiling semantics, `agent_name` provenance caveat), so the schema carries the parameter burden. The description lists the action set but adds no parameter syntax or format detail beyond what the schema already provides, so the baseline 3 is correct.

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

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

The description opens with a precise verb+resource ('Fastio sign-in and credentials (write)') and then enumerates the concrete operations covered — PKCE sign-in, signup, signout, API key CRUD, 2FA, OAuth session update/revoke. It explicitly carves out what is NOT handled here ('Password signin and 2fa-verify are refused') and routes reads to the sibling `auth` tool, so an agent can distinguish it from `auth` without opening either schema.

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?

States both when to use this tool (write-side auth operations) and when not to ('Reads are on `auth`'), plus the explicit refusal cases ('Password signin and 2fa-verify are refused'). The alternative tool is named rather than implied, which is the textbook 5 condition.

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, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds context beyond that: it makes the read/write division of labor with comment_manage explicit and points to action='describe' for a full action/param reference, which is genuinely useful self-documentation 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?

Two tightly written sentences: the read scope and its four operations are front-loaded, and routing to the write sibling plus the describe hint follow. No filler, every clause earns its place.

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

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

For a 17-parameter tool with no output schema, the description covers the essentials: scope, the operation set, and a pointer to action='describe' for the full reference. It doesn't explain the alias relationships (e.g., context_id/share_id/workspace_id vs profile_id), but the schema documents those, and no output schema means return values needn't be described.

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 17 documented parameters and 6 enums, so the schema already carries parameter meaning. The description only reinforces the 'action' parameter via action='describe' and adds no syntax or alias guidance beyond what the schema provides, 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?

States a specific verb+resource ('comments on files (read)') and enumerates the four concrete operations: list a file's comments, all comments in a workspace or share, comment details, and a comment's attachments. It also explicitly differentiates itself from the write sibling comment_manage, so an agent can distinguish the two without opening schemas.

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?

'Writes are on comment_manage' explicitly routes mutation intent to the correct sibling, and the parenthetical '(read)' plus the enumerated action list make the read context clear. It stops short of per-action selection guidance (e.g., when to choose list vs list-all), but the main when-to-use/when-not split is legible.

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=false and destructiveHint=true, so the description's job is to add detail — and it does, naming exactly which actions are destructive (delete, bulk-delete) rather than leaving the agent to guess across nine actions. It stops short of describing permission requirements, reversibility, or side effects of attachment detach.

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

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

Three tightly packed sentences: the write scope first, the destructive warning second, the routing to `comment` and 'describe' last. No filler and every clause carries information the agent needs.

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 17-parameter tool with nested objects and no output schema, the description covers scope, destructiveness, and the read alternative, and delegates exhaustive detail to action='describe'. What is missing is any hint about required identifiers (profile_id/node_id) or what a successful mutation returns, though the describe action mitigates that.

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

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

Schema description coverage is 100%, so the schema already documents all 17 parameters in detail, including the nested anchor object and the region coordinate conventions. The description only alludes to 'optional anchor or attachments' and adds no syntax or constraint detail beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource ('Fastio comments on files (write)') and then enumerates the exact operations covered: add with anchor/attachments, edit, delete, bulk-delete, reactions, attach/detach. It also distinguishes itself from the sibling read tool `comment`, so an agent can route without opening either schema.

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?

Explicitly routes reads to the `comment` tool and points to action='describe' for the full action/param reference. It does not give per-action when-to-use conditions (e.g. when to prefer bulk-delete over repeated delete), but the write/read split and the describe escape hatch are clear 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 declare readOnly/idempotent/non-destructive/openWorld, and the description adds genuinely new context: it consumes bandwidth credits and flags quickshare-details as deprecated. It does not describe URL expiry or output shape, so not a 5.

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?

Front-loaded with the core capability, then the deprecation caveat, then the cost and the describe pointer in a compact two-sentence block. Dense but every clause carries information; slightly telegraphic phrasing costs it a point.

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 an 11-parameter tool with no output schema, the description covers the action space, the credit cost, the deprecation status, and a discovery escape hatch via describe. It omits return-value/URL-lifetime details, but annotations carry the safety profile and the schema carries parameter detail.

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%, and the schema already documents the polymorphic profile_id aliases, node_id, and version_id in detail. The description only repeats the action-value names, adding little beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb (download) plus the exact resources returned (file URLs, folder ZIPs) and maps the action enum values file-url/zip-url/quickshare-details to those outcomes. It also distinguishes itself from the sibling fileshare_manage for link creation, so an agent can tell it apart without inspecting schemas.

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

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

Gives clear context for each action and explicitly routes quickshare link creation to fileshare_manage, plus points to action='describe' for the full reference. It lacks explicit when-not-to-use guidance versus read siblings like find or storage, so it falls just short of a 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful scope context — the changes feed being 'one cursor for every workspace and share in an org' and the per-member dashboard feed — but says nothing about auth requirements, rate limits, or polling cost beyond what the schema already states.

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

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

A single dense paragraph that front-loads the read-only scope and the operation inventory before the hand-off to `event_manage`. Every clause carries information, though the sentence is long and could be broken for scanability.

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 27-parameter, action-dispatch tool with no output schema and full schema coverage, the description covers scope, the read/write boundary, and defers detailed action semantics to the describe action. That is sufficient for correct invocation; the omission of return-shape or pagination expectations is minor given the schema.

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

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

Schema description coverage is 100%, so all 27 parameters (including the 6 enums and cursor/long-poll semantics) are already documented in the schema. The description's mentions (cursor over an org, dashboard-list scoping) add framing but no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

The description opens with an explicit verb+resource+mode ('Fastio event log and activity (read)') and then enumerates the concrete read surfaces: audit event search, event details, activity list/long-poll, dashboard-list, and the org-wide changes feed. It names the sibling it is not ('Writes and the billed AI summary are on event_manage'), so an agent can route between `event` and `event_manage` without opening either schema.

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

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

It gives explicit routing guidance (reads here, writes/billed summarization on `event_manage`) and points to action='describe' for the full action/param reference. It does not spell out when to pick search vs details vs activity-list vs dashboard-list, leaving that to the action names and the describe 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 only give a blanket destructiveHint=true, but the description differentiates the operations: summarize incurs a billed LLM call against org AI credits, acknowledge is idempotent and only marks read for the caller, and dashboard dismiss/snooze is a per-caller view change that leaves the underlying item unchanged. That is exactly the kind of nuance the annotations cannot express.

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?

Front-loaded with the write-scope and each action's effect in a single dense sentence, followed by the sibling routing and the describe pointer. Every clause is informative, though the stacked parentheticals make it slightly heavy to parse.

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

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

For a 5-action, 22-parameter write tool with no output schema, it covers what each action does and where to find full parameter details. It stops short of describing what each action returns, but the describe pointer partially compensates.

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 carries the parameter semantics (including the nuanced user_id/subcategory/category notes), making 3 the baseline. The description adds only the pointer to action='describe' for the full reference rather than new per-parameter meaning.

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

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

States a specific verb+resource ('Fastio events (write)') and enumerates the three distinct write capabilities (summarize, acknowledge, dashboard dismiss/undismiss) with their effects. It explicitly distinguishes itself from the read sibling by saying 'Reads are on `event`', so an agent can separate the two without opening either schema.

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 read/write split against the `event` sibling is stated explicitly, which is the primary routing decision. It also points to action='describe' as the authoritative reference for the action/param catalog, giving a clear fallback when details are needed.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, yet the description still adds non-obvious behavior: recipient 404s are deliberately uniform so not-found/revoked/expired are indistinguishable, URL actions return a direct API URL rather than content, and gated shares require Authorization and/or x-ve-password headers on the GET. It does not cover rate limits or pagination edge behavior, so it stops short of a 5.

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

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

Three tightly packed sentences with no filler, front-loaded with the read-scope statement and the sibling routing. The 404 and header details are dense but each earns its place; slightly heavy clause density is the only cost.

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

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

For a read-only, no-output-schema tool with 8 fully documented parameters, the description covers scope, action set, sibling boundary, ambiguity behavior, and auth requirements for the URL actions. Only the shape of list/details results and pagination semantics go unmentioned, which is minor given the schema and the action='describe' escape hatch.

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, but the description adds meaning the schema does not: it explains that the password is transmitted only as the x-ve-password header on the resulting GET, and that version_id comes from versions-list. That ties the URL actions back to the parameters rather than merely restating them.

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

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

The description opens with a specific verb and resource ('Fastio File Shares (read)') and enumerates the exact capabilities: list/details, grants, version history, and download/preview/version URLs. It explicitly distinguishes itself from the write sibling by naming `fileshare_manage`, so an agent can route correctly without opening a schema.

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 clearly states the when-not condition ('Writes are on `fileshare_manage`') and routes to action='describe' for the full action/param reference. It doesn't spell out when to pick `list` vs `details` vs `grant-list`, but the enum plus per-action parameter descriptions make that inferable.

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

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

Annotations already mark this destructive/openWorld, but the description adds non-obvious behavior the booleans cannot convey: delete removes the share and not the file, the file binding is immutable, and grant-by-email to an unregistered address creates a pending invite. These are exactly the operational nuances an agent needs before calling a destructive 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?

Three sentences, front-loaded with the write scope and destructive actions, no filler. The action/param reference is delegated to `describe` instead of bloating the description with 13 parameters.

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?

Thirteen parameters are fully documented in the schema, annotations carry the safety profile, and there is no output schema to explain. The description fills the remaining gaps (destructive semantics, sibling routing, describe escape hatch), so nothing an agent needs to invoke correctly is missing.

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% and each parameter already documents its own constraints (enums, exclusivity, expiry ranges). The description restates a couple of these (immutable binding, pending invite) rather than adding syntax the schema lacks, but its framing of grants and access tiers gives useful orientation. Slightly above the baseline-3 case for full 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?

Names a specific verb set (create/update/delete/grant-add/grant-revoke) on a specific resource (Fastio File Shares), and explicitly scopes it as the write side by pointing reads to the `fileshare` sibling. An agent can distinguish it from `fileshare`, `share_manage`, and `workspace_manage` without opening a schema.

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?

Explicitly routes reads to `fileshare`, flags exactly which actions are destructive (delete, grant-revoke), and offers `action='describe'` as the lookup path for the full reference. This covers when-to-use, when-not-to-use, and the alternative in three compact clauses.

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 read-only, non-destructive, open-world behavior, so the safety profile is covered. The description adds real context beyond that: the bucket model (files, metadata workspace-only, comments), independent pagination, and health reporting. It omits any auth or rate-limit notes, but the annotation baseline makes this solid.

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

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

Three dense sentences with the core purpose front-loaded before the sibling comparisons. Nothing is wasted, though the middle sentence is heavily parenthetical and slightly harder to parse on first read.

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 20-parameter tool with no output schema, the description conveys the essential shape of results (typed buckets, per-bucket pagination) and defers detail to action='describe'. That is close to sufficient, though a single clause on what 'health-reported' means for a bucket would close the remaining 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 schema already documents all 20 parameters including enums, aliases and pagination defaults. The description adds only a pointer to action='describe' for the full action/param reference and does not elaborate meaning beyond what the schema carries. 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?

States a specific verb and resource ('unified search across a workspace or share') and immediately clarifies the distinguishing behavior — results grouped by type into buckets. It explicitly separates itself from the two closest siblings (`storage action=search` and `metadata action=search`), so an agent can route without opening schemas.

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?

Names the alternatives and the exact condition selecting each: storage is files-only with a smaller page and depth surface, metadata covers lexical metadata alone, and find adds metadata-only hits plus comments in one call. It also routes deep dives to action='describe'. This is explicit when/when-not guidance.

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

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

Annotations already cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=true), yet the description adds non-trivial context beyond them: it performs NO platform action, returns guidance text only, costs no credits, needs only authentication, and phrases answers as concrete '<tool> action=…' calls rather than guessed endpoints.

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?

Dense but front-loaded: the core purpose leads, then boundaries, then sibling differentiation, then cost/auth notes. Slightly heavy with parentheticals and repeated emphasis on the no-action guarantee, but every sentence carries actionable information.

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 no output schema, the description still tells the agent what comes back (grounded answer or clarifying question) and what does not (no actions, no side effects). Combined with full schema coverage and rich annotations, an agent has everything needed to select and invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds value by explaining that action='describe' yields the full action/param reference and that a vague question yields a clarifying question instead of an answer, which shapes how the agent should phrase input.

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

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

States a specific verb and resource: a natural-language 'how do I…' question about Fastio returns a grounded, product-aware answer (or clarifying question) in one call. It explicitly distinguishes itself from the closest sibling by declaring 'Q&A over the user's uploaded files (RAG) is the ai_manage tool; how-to answers questions about Fastio ITSELF.'

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

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

Gives explicit when-to-use (questions about Fastio itself), when-not (RAG over uploaded files goes to ai_manage), the precondition (authenticated user, no org needed), the cost profile (no credits), and the operational boundary (explain-only, no platform actions). Nothing is left to inference.

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 establish readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: intents are workspace-scoped with no share variant, browse returns topics only while expand returns full records. Pagination/return-shape detail is left to the schema.

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

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

Three tight sentences: identity/scope first, mode distinction second, routing to the write sibling last. No filler, and the most decision-relevant facts are 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?

There is no output schema, and the description compensates by sketching what each action returns (topic summaries vs full records). Cursor pagination and the describe action are only implied, but the schema covers those parameters, so coverage is adequate.

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 every parameter is already documented in the schema (including browse-only cursor and expand-only intent_ids). The description reinforces the browse/expand parameter mapping but adds no syntax or format detail beyond it, matching the baseline 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?

States a specific verb+resource ('Agent Intents (read): workspace-scoped declarations of what agents are working on') and immediately distinguishes the two read modes, browse vs expand. It also names the sibling that owns writes, so an agent can separate this tool from intent_manage without opening either schema.

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 clearly routes writes to `intent_manage` and explains the browse/expand split (list topics vs full records). It does not cover the third action, 'describe', or when to prefer this over other read tools, so the guidance is strong but not exhaustive.

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 give a blanket destructiveHint=true, but the description narrows it: only `release` is destructive, which is genuinely useful disambiguation. It also discloses that allocate is get-or-create (may return an existing slot) and that fill doubles as the heartbeat — behavior not visible in the schema. Auth/permission requirements and rate limits are still unstated.

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?

Tight and front-loaded: the write scope and the destructive action appear immediately, and the sibling routing is at the end. The parenthetical nesting makes it dense but every clause carries information; no filler sentences.

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 9-parameter write tool with no output schema, the description covers the action lifecycle, the destructive action, and sibling routing, while the schema covers per-parameter constraints (version CAS, 409, ID formats). Missing is any mention of permissions or what release actually destroys.

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 already documents all 9 parameters; baseline would be 3. The description earns above baseline by adding action-level semantics the schema lacks — get-or-create on allocate and heartbeat behavior on fill — which help the agent choose the right action.

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?

Names a specific resource (Agent Intents) and enumerates the three write operations — allocate, fill, release — with concrete semantics for each. It also explicitly distinguishes itself from the sibling `intent` tool, so an agent can route without opening either schema.

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?

Explicitly routes read operations to `intent`, and the allocate→fill→release lifecycle implies the intended ordering. It does not, however, state preconditions for each action (e.g., when allocate is preferable to reusing a slot) beyond the get-or-create hint.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description reinforces '(read)' and adds the write-path routing, but discloses nothing about pagination, result size, or output shape. Consistent with annotations, no 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?

Two short sentences with the read scope front-loaded and the delegation to invitation_manage immediately after. Zero 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?

A read-only list tool with fully documented parameters and no output schema; the description plus schema covers what an agent needs to invoke it. Minor gap on intra-action selection (describe vs list-by-state) keeps it short of a 5.

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 all four parameters (action, state, entity_id, entity_type) are already documented inline, including enum values. The description only restates the state filter, adding no syntax or format detail beyond the schema; baseline 3 applies.

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

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

States a specific verb+resource ('list invitations, filter by state') scoped to workspace and share invitations, and explicitly marks it as the read-side tool. An agent can distinguish it from invitation_manage without opening either schema.

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?

Explicitly routes write operations to `invitation_manage`, which is a clear when-not-to-use signal. It does not explain when to choose 'describe' vs 'list' vs 'list-by-state', so the intra-tool routing is left to inference.

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=false, destructiveHint=true, and openWorldHint=true, so the safety profile is covered; the description adds value by pinpointing that 'delete' specifically is the destructive action rather than the update path. It does not disclose side effects of update (e.g., notification behavior) or permission requirements, which keeps it below a 5.

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 short sentences with the write scope, the destructive action, and the read alternative all front-loaded and free of filler.

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 9-parameter mutation tool with no output schema, the description covers routing and the destructive path, and the fully described schema carries the parameter burden. It omits the `describe` action and any indication of required combinations per action, leaving a small completeness 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% and three parameters carry enums, so the schema fully documents action, entity_type, new_state, expires, and the rest. The description adds no parameter-level meaning beyond the action names, making the baseline 3 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?

Names a specific resource (workspace and share invitations) with concrete write verbs (update, revoke) and explicitly marks delete as the destructive path. It also draws a clean boundary against the `invitation` sibling, which handles reads, so an agent can route without opening either schema.

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?

Explicitly routes read operations to `invitation`, which is exactly the alternative-selection guidance an agent needs for this family. It stops short of stating preconditions (required IDs, entity_type/entity_id matching, permissions needed), so it is clear context rather than full when/when-not coverage.

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, so the safety profile is already structured. The description adds value by clarifying that it lists both active and pending members, which the annotations don't say. It could add more (pagination behavior, permissions), but it's solid.

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, zero waste, and the sibling routing is front-loaded. Every word earns its place.

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

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

Complete for a read tool with full schema coverage and annotations covering safety. It clearly routes to the write counterpart. The only minor gap is not detailing return structure, but with no output schema and a list operation, that's acceptable and could be inferred.

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 does the heavy lifting. The description maps the two list modes ('active and pending', 'details') to the `action` enum values, which is useful but minimal. 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 uses a specific verb ('read') on a specific resource ('workspace and share members') and explicitly distinguishes the read tool from its write sibling ('member_manage'). It also clarifies the sub-operations (list active and pending, details).

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

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

It explicitly states when to use this tool versus the alternative: 'read' operations belong here, 'Writes are on member_manage'. This is the exact sibling routing pattern.

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 and readOnlyHint=false, but the description goes further by naming exactly which actions are destructive: remove, transfer-ownership, leave. That specificity is genuine added value, though it does not cover auth requirements, reversibility, or side effects like notification emails triggered on add.

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 short sentences with zero filler; the action inventory leads and the destructive warning plus sibling pointer are front-loaded. Every clause earns its place.

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

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

For a 17-parameter multi-action tool, the description covers the action set, the destructive subset, and the read/write boundary with its sibling, while the schema carries the parameter detail and there is no output schema to explain. The remaining gap is per-action parameter pairing, which is only partially implied by schema hints like '(share)' and '(workspace)'.

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% across all 17 parameters, with enums and format constraints (e.g., the UTC date format and the 406 rejection note) already documented in the schema. The description adds no parameter syntax or pairing information beyond what the schema provides, so the baseline 3 applies.

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

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

Names a specific verb+resource ('Fastio workspace and share members (write)') and enumerates all eight operations, so the agent knows exactly what surface it covers. It also explicitly distinguishes itself from the sibling read tool by ending with 'Reads are on `member`.'

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 clear routing context: this tool is the write path, and reads belong to `member`. However, with eight distinct actions in one tool, it gives no per-action selection guidance (e.g., when to use 'join' vs 'join-invitation', or 'remove' vs 'leave'), so the agent must fall back on the enum descriptions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful non-obvious context: retired features, that template_id now fails on every action, and that a describe action exists to fetch the full reference. It does not discuss rate limits or response shape beyond pointing at describe.

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?

Front-loaded with the tool scope and the read/write split, with the long action parenthetical placed mid-sentence. The sentence listing eight actions is dense but every clause maps to a real enum value, so little is wasted.

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 16-parameter, 9-action router with no output schema, the description is compact yet covers scope, sibling boundaries, deprecations, and a pointer to action='describe' for the full reference. That pointer compensates for the lack of per-action detail in the description itself.

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 every one of the 16 parameters is already documented in structured form, including the cursor, offset, and required-for-compound-search details. The description adds only the action glosses (fields-list, search, compound-search, etc.), which is the expected baseline 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?

States a specific verb and resource ('Fastio workspace metadata (read)') and enumerates the nine operations it exposes, so an agent knows exactly what capability set this covers. It also explicitly separates itself from metadata_manage (writes) and storage_manage (extraction), making sibling disambiguation immediate.

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?

Names the alternatives by tool ('Writes are on metadata_manage', 'extraction is on storage_manage') and flags the removed capabilities (templates, saved views). It also gives the escape hatch for deeper detail via action='describe', which is an explicit when-to-use instruction.

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 and readOnlyHint=false, but the description adds which specific actions are destructive (fields-merge, filter-delete) and that fields-merge is workspace-wide and irreversible unless confirm is set. The 'unconfirmed it is a preview' phrasing is slightly murky about what remains unverified, which keeps this short of a 5.

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

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

Three tight clauses with zero filler, front-loading the write scope, then the destructive-action list, then the read alternative and the describe escape hatch. Every sentence earns its place.

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

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

For a 12-parameter, no-output-schema tool with a retired `template_id`, the description covers the safety-critical surface (which actions destroy data, preview behavior) and the alternatives. It relies on the schema for field-level detail, which is reasonable, but does not mention result shape or how filter_id is obtained.

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% and the schema already documents every parameter, including the preview semantics of `confirm`. The description's only parameter-level contribution is pointing at action='describe', so the baseline 3 for schema-carried semantics 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?

States a specific verb and resource ('Fastio workspace metadata (write)') and enumerates the concrete operations: field folding, saved-filter create/replace/delete. It explicitly distinguishes itself from the read sibling ('Reads are on `metadata`'), so an agent can route without opening either schema.

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

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

Gives clear routing context: use this for writes, use `metadata` for reads, and use action='describe' to get the full action reference. It does not, however, say when to pick fields-merge versus filter-* operations or state prerequisites beyond workspace scoping.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description's read/write split reinforces that and points to org_manage, but adds nothing about pagination, default time windows, or permission requirements for the org-scoped reads.

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, no filler, with the read scope and the org_manage handoff front-loaded. The middle clause is a dense keyword list rather than prose, which is efficient but slightly reads as a dump of action names.

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 16-parameter, 22-action multiplexed tool with no output schema, the description gives the agent a category map but no per-action requirements (which actions need org_id, meter, or workspace_id) and no return-shape hints. The `describe` action in the schema partially compensates, so this is adequate but not complete.

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

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

Schema description coverage is 100% and every parameter (detail defaults, meter, starting_after, describe_action, workspace_id scoping) is already documented inline. The description only repeats the action category names, adding no format, default, or interaction semantics beyond the schema. Baseline 3 is correct.

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?

States the resource (Fastio organizations) and the read-only scope, then enumerates the operation families (list, details, limits, workspaces, shares, billing, members, invitations, discovery, assets) that map onto the 22-value action enum. That is enough to tell it apart from org_manage, though it never names a single verb+resource pair per action.

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?

Explicitly routes write operations to the sibling `org_manage`, which is a genuine when-not rule. It does not, however, say when to pick a specific action over another (e.g. details vs public-details, discover-all vs discover-available), leaving that to the schema's 'describe' action.

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, openWorldHint=true, readOnlyHint=false, but the description adds real value by naming which actions are destructive and spelling out the worst consequence (close destroys the org and all data). It does not cover auth/permission requirements or rate limits. Note the tool does expose a `describe` read action even though the text says reads live on `org` — a minor inconsistency, not an annotation 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?

Three tight clauses with zero filler: scope first, capability families second, destructive actions third, sibling routing last. Every phrase earns its place in a tool whose schema carries the bulk of the detail.

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 an 18-action, 45-parameter tool with no output schema, the description covers the high-risk information (which actions destroy data) and the read/write split. It omits mention of the `describe` mechanism and the `confirm` requirement for close, though both are fully documented in the schema.

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

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

Schema description coverage is 100%, so the schema already documents all 45 parameters with constraints, enums, and cross-references (billing-plans, industry-list). The description adds no parameter-level detail beyond grouping the actions, 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?

States the resource (Fastio organizations) and the scope (write) and enumerates the operation families it covers: create, update, workspaces, billing, members, invitations, assets. It explicitly distinguishes itself from the read sibling by naming `org` as the read path, so an agent can route without opening either schema.

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

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

Gives a clear routing rule — writes here, reads on `org` — and flags the destructive subset, which tells the agent when caution is required. It stops short of stating when a write should be avoided entirely or what prerequisites (e.g. confirm for close) gate each action.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description reinforces the read scope and mentions password-auth for protected shares, but adds nothing about pagination, response shape, or auth prerequisites beyond what the schema already encodes.

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 tight sentences with the read scope front-loaded, followed by the routing pointer and the describe hint. No filler; each clause carries information.

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 11 parameters and three enum fields but no output schema, the description supplies the essential orientation: read-only scope, the write alternative, and the action='describe' escape hatch for full parameter detail. Only minor gaps remain around return-shape expectations, which annotations and the describe action largely absorb.

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 all 11 parameters are already documented in the schema (including action, name, password, display_limit, limit). The description only gestures at 'password auth' and 'name availability' and adds no format or syntax detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('Fastio shares (read)') and enumerates the concrete capabilities: list and details, public details, members, available shares, name availability, password auth. It also names share_manage as the write counterpart, so an agent can distinguish it from the sibling without opening a schema.

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?

Explicitly routes writes to `share_manage` and points to action='describe' for the full action/param reference, which is a clear usage signal. It stops short of explaining which read action (details vs public-details vs members) to pick when, so it is clear context without full 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 declare destructiveHint=true, but the description sharpens it ('Destructive: delete (permanent)') and then adds traits annotations cannot express: credit consumption for autotitle and Deep Indexing (10 per page), plus a deprecated action that fails with a specific error code. That is meaningful cost/behavior context beyond the structured fields.

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?

Five dense sentences cover eight actions, deprecation, cost, and a reference escape hatch with no filler, and the write-scope statement is front-loaded. It is terser than the surface area warrants in a couple of places (e.g. cost mentions appear twice: ai/autotitle and Deep Indexing), but nothing is wasted.

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 an 8-action, 38-param tool with no output schema, the definition supplies the essentials: action set, sibling routing, destructive/cost warnings, and a discovery mechanism for per-action detail. It does not characterize response shapes per action, but action='describe' is presented as covering that 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% across 38 params, so the schema already documents formats, defaults, enums and per-action applicability (e.g. expires differs between create and quickshare-create). The description adds almost nothing parameter-level beyond pointing at action='describe', so the baseline 3 for heavily schema-documented tools is correct.

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?

Opens with a specific verb+resource and enumerated write actions ('Fastio shares (write): create, update, archive/unarchive, delete, autotitle'), which maps directly to the action enum. It also names what it is not (reads are on `share`; single-file links are `fileshare_manage` action create), so an agent can separate it from siblings without opening a schema.

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?

Explicitly routes the agent: reads go to `share`, single-file links to `fileshare_manage`, and quickshare-create is deprecated with the exact error code (10756). It also tells the agent to call action='describe' to get the full per-action param reference, which is real when-to-use guidance for a multi-action 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered and the description's 'reads' is partly redundant. It does add useful context beyond the annotations – that some actions yield document and audit-certificate download URLs and that writes are delegated elsewhere – but discloses nothing about auth needs, rate limits, or return format specifics.

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

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

Two tightly written sentences: the first front-loads the read scope and the second names the write alternative. No filler, and the important routing information is placed early – only slightly terse for a tool with ten parameters and ten actions.

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

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

For a read-only, ten-parameter tool with full schema coverage and no output schema, the description covers the read/write split and the return categories but does not help an agent choose among the ten actions or explain the 'describe' workflow. Adequate, but a good part of the selection burden rests on the schema.

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

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

Schema description coverage is 100%, so the schema already documents all ten parameters (including the numeric workspace_id constraint and the action enum) and the baseline is 3. The description adds no parameter-level detail 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 names the domain (Fastio e-signature) and enumerates the read resource categories – sign envelopes, sign templates, and document/audit-certificate download URLs – within a workspace, and explicitly routes writes to the sibling sign_manage. It is clear and sibling-differentiating, though 'reads' is a broad category label rather than a single precise verb.

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 states a clear condition for use: read operations live here, while 'Writes are on sign_manage', naming the alternative explicitly. It gives no guidance on which of the ten read actions to pick or on ordering (e.g. describe first), leaving that to the schema.

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

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

Annotations only say destructiveHint=true generically; the description narrows it to the exact three actions (sign-send, sign-void, sign-template-delete) and states the confirm='true' gate, plus the billing side effect that send 'reserves signing credits'. It omits reversibility and rate-limit behavior, but the per-action destructive mapping is real added value.

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

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

Three dense sentences with zero filler: capability list first, destructive/confirm caveat second, sibling routing last. Every clause carries information an agent needs.

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 17-parameter, 11-action tool with no output schema, the description supplies scope, sibling routing, the destructive subset, and the describe escape hatch — enough to call it correctly given 100% schema coverage. It stops short of mapping actions to intents, which is the remaining 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% and every parameter carries a per-action note, so the schema does the heavy lifting; baseline 3 applies. The description only repeats the confirm='true' requirement and adds the credit-reservation note for send, adding little parameter meaning 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?

Opens with a specific verb+resource ('Fastio e-signature writes') and enumerates the concrete operations (draft, send, void, retry, signing link, templates), so the agent knows exactly what surface this tool covers. It also explicitly delimits itself from the sibling read tool ('Reads are on `sign`').

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 states the write-vs-read split and routes reads to `sign`, and it points to action='describe' for the full action reference. What it does not do is help choose among the eleven write actions for a given intent — the agent must go to the schema enum or call describe.

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, destructiveHint=false and openWorldHint=true, so safety is covered. The description still adds useful behavior: the read-only action inventory, the pointer to storage_manage for mutations, and the important note that metadata is AI-extracted and searchable, which steers agents away from expensive content reads. It does not describe rate limits or pagination semantics in prose.

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

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

Three compact sentences, front-loaded with the read scope and the write boundary before the metadata hint. The ALL-CAPS emphasis is slightly noisy but the content is dense and every sentence earns its place.

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

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

For a 43-parameter, 15-action tool with no output schema, the description cannot enumerate everything, and it correctly provides a discovery path via `action='describe'` plus the scope/mutation boundary. Return-value shape is left to the schema's per-action descriptions, which is acceptable given the deferral mechanism.

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% across all 43 parameters, and the schema descriptions are unusually rich (aliases, defaults, cross-param conflicts such as q vs max_bytes). The description adds only the pointer to `action='describe'` for the full action reference, so 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?

States a specific verb family (read operations) plus resource (files and folders) and enumerates the sub-operations: list, recent, search, details, trash, versions, locks, previews, content reads, and per-node metadata. It also explicitly contrasts itself with the sibling `storage_manage`, so an agent can tell the read tool from the write tool without opening either schema.

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?

Names the alternative for writes ('Writes are on `storage_manage`') and gives a real usage heuristic: files often carry AI-extracted metadata that is searchable and 'frequently answers the question without opening anything.' It does not say when to pick one of the 15 actions over another, deferring that to `action='describe'`.

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 flag destructiveHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds real value beyond that by grading destruction: delete goes 'to trash' while purge is 'permanent', and metadata-delete is destructive. It does not cover auth/permission requirements or return behavior, keeping it below a 5.

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

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

Three dense sentences, front-loaded with the write scope and followed by the destructive list and the escape hatch. Efficient, though the action list is compressed to near-telegraphic style with minimal connective 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 tool with 18 actions, 28 params, and no output schema, the description summarizes scope correctly and delegates full detail to action='describe', which is an adequate completeness strategy. It could say more about the dual-instance transfer/auth model, but nothing critical for correct invocation is missing.

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% and the schema itself documents every parameter (including aliases, lock durations, extract_fields). The description adds no parameter-level syntax beyond pointing the agent to action='describe', so the schema does the heavy lifting and baseline 3 applies.

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

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

States a specific verb class (write operations) on a specific resource (Fastio files and folders), then enumerates the mutation categories. It explicitly distinguishes itself from the 'storage' sibling by declaring 'Reads are on `storage`', so an agent can route without opening either schema.

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?

Clearly routes read vs write via the 'storage' pointer and directs discovery through action='describe'. It gives clear context for when to use this tool versus the read sibling, but does not disambiguate among the many actions beyond grouping them.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description still adds value by disclosing that `wait` long-polls and that blob-info is a POST /blob sidecar, which are behavioral traits an agent needs. It does not mention auth requirements, rate limits, or what the read payloads contain.

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 dense sentences, front-loaded with the read scope and the sibling boundary, then the action reference escape hatch. Every clause maps to a capability or routing decision; nothing is padding.

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 14-parameter, multi-action read tool with no output schema, the description covers scope, sibling boundary, and points to `describe` for per-action detail, which is a sound completeness strategy. It leaves return shapes and per-action prerequisites unstated, though the describe mechanism mitigates that.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description earns a step above by tying key parameters to behavior: `wait` long-polling, `blob-info` for sidecar details, and action='describe' for the action/param index. It adds framing rather than raw syntax, which the schema already supplies.

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 names the specific resource (Fastio uploads) and scopes it precisely as the read half: session status, sessions, chunk status, web-import jobs, limits, extensions, blob-info. It explicitly contrasts itself with `upload_manage`, so an agent can distinguish it from its write sibling without opening either schema.

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

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

It gives an explicit boundary ("Writes are on `upload_manage`") and routes the agent to action='describe' for the full reference, which is a real usage rule. It does not say when to prefer one action (e.g. status vs chunk-status) over another, so it stops short of full when/when-not coverage.

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 the tool is destructive, and the description goes further by naming exactly which actions are destructive (cancel, cancel-all, chunk-delete, web-cancel), disclosing storage-credit consumption, and explaining that same-name uploads overwrite in place as a new version. These are side-effect details the annotations cannot express.

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?

Front-loaded with the action inventory before byte-source and side-effect details, which is the right ordering for a 12-action tool. It is dense and some clauses (base64 inflation, storage credits) duplicate schema text, but for a 33-parameter mega-tool the length is earned.

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 12 actions, 33 parameters, and no output schema, the description covers the decision-critical surface: which action, which byte source, size limits, and destructive semantics. It defers the exhaustive action/param matrix to action='describe', which is a reasonable pointer, though per-action return behavior remains unstated.

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 still adds cross-parameter routing value beyond the schema by synthesizing which byte source (blob_id vs content vs content_base64) to use and why, rather than restating field definitions 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?

Opens with a specific verb+resource framing ('Fastio uploads (write)') and enumerates the full set of write actions (stream-upload, chunked sessions, web import, batch, cancellation). It explicitly distinguishes itself from the read-side sibling by noting 'Reads are on `upload`', so an agent can route without opening either schema.

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 concrete selection rules: the POST /blob sidecar is the default byte source for files and binaries, chunked is for files over 100 MB, `content` is for text composed in-call, and `content_base64` is a rare fallback. It also names the alternative tool for reads and points to action='describe' for the full action/param 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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds the read/write boundary and the redirect to user_manage, which is useful context, but says nothing about pagination behavior, rate limits, or auth requirements for a 12-action 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?

Two clauses, zero filler, and the resource scope is front-loaded before the sibling redirect. Every word earns its place.

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

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

For a 10-parameter read-only tool with no output schema, the description plus 100% schema coverage and a built-in 'describe' action give an agent enough to invoke it correctly. The remaining gap is routing among the other read-oriented siblings, which the description does not address.

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 every parameter is already documented in the schema, including the 12-value action enum and the 'describe' self-documentation action. The description adds no parameter-level meaning beyond the schema, which is the baseline-3 case.

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?

States a specific resource (Fastio user account) and a clear scope (read: profile, contacts, limits, shares, invitations, assets). The parenthetical '(read)' plus the enumerated resource list lets an agent distinguish it from user_manage and from other read siblings at a glance.

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?

Explicitly routes write operations to `user_manage`, which is a concrete when-not-to-use signal. It stops short of distinguishing this tool from other read siblings such as member, invitation, or share, so it is not a full alternative map.

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 and readOnlyHint=false, but the description adds the specific destructive action set, which is useful beyond the generic annotation. It does not explain permissions, reversibility, or confirmation 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?

Three compact fragments, front-loaded with scope, then destructive actions, then the read alternative. Every clause carries routing or safety value and there is no padding.

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 23-parameter multi-action tool, the description supplies essential write-vs-read routing and destructive-action categorization. The fully described schema and safety annotations cover most remaining gaps, though the description omits confirmation/idempotency nuances and per-action return expectations.

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 all 23 parameters are documented in the input schema. The description adds grouping for the `action` enum and identifies destructive action values, but does not clarify conditional requirements such as when `confirmation` is needed or how the other parameters interact per action.

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?

States the resource (Fastio user account) and operation type (write), enumerates action groups (profile, invitations, assets, report-bug) and destructive actions. Explicitly distinguishes this tool from the read-only `user` sibling.

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?

Directs all read operations to the `user` sibling, which clearly scopes this tool to writes. It also flags destructive actions (close, asset-delete, invitation-decline) so the agent can route and call them cautiously.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real context on top: the `describe` self-reference mechanism, an async job-status action, and the terse/full verbosity behavior per action. It omits auth requirements and pagination nuance, keeping it short of a 5.

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?

Front-loads what the tool reads, then handles boundaries, then verbosity defaults in roughly three dense clauses. No wasted sentences, though the parenthetical action list and the trailing verbosity sentence are somewhat cramped for a single run-on block.

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 an 11-action multiplexed tool with 13 params and no output schema, the description covers scope, sibling boundaries, and the `describe` escape hatch for the full action/param reference. What remains unstated (pagination semantics, auth) is minor and partly covered by the schema.

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

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

Schema description coverage is 100%, so all 13 parameters are already documented. The description restates the `detail` verbosity defaults, which the schema already documents verbatim, and points to `describe` for per-action field lists, adding only marginal meaning 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?

States a specific resource and scope ('Fastio workspaces (read)') and enumerates the operations covered: list/details, members, shares, available, name availability, notes, QuickShare links, job status. It also names the sibling that handles the write side (`workspace_manage`), so an agent can separate the two without opening a schema.

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?

Explicit routing: writes go to `workspace_manage`, metadata vocabulary to `metadata`, node-level metadata to `storage`, and `action='describe'` for the full reference. This tells the agent both when to use this tool and which alternatives to reach for otherwise.

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