Local MCP

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

Goes well beyond the annotations by disclosing the Pro requirement, the exact-name matching constraint, the first-match-only behavior on duplicate names, and the returned id/name used to confirm which task was completed. What it omits is whether completion is reversible or how a no-match is reported, which matters given destructiveHint=true.

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

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

Four short sentences, front-loaded with the action and prerequisite, then the input preference, then the ambiguity rule. The final sentence restates a return value that an output schema already covers, but the rest is dense with useful content.

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

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

For a destructive single-target mutation this covers prerequisites, identifier sourcing, ambiguity resolution and post-call confirmation. The remaining gap is failure behavior (no matching name) and reversibility, which an output schema alone cannot convey.

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 already 100%, so a 3 is the baseline, but the description adds real decision semantics: prefer task_id, task_name must match exactly, and ties resolve to the first match. Only the vestigial `confirm` parameter is left unaddressed, though the schema itself already explains it.

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 ('Marks an OmniFocus task as complete') and names the OmniFocus family, which separates it from the sibling complete_reminder, todoist_complete_task and todo_complete_task without ambiguity.

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 the prerequisite (OmniFocus Pro), the preferred path (task_id from list_omnifocus_tasks or search_omnifocus_tasks) and the fallback condition with its exact-match rule. The agent knows both when to use it and how to choose between the two input modes.

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?

While annotations handle the safety profile (destructive/write), the description adds valuable behavioral context by explicitly stating the operation runs within 'Apple Reminders'. This clarifies the scope of the execution environment.

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

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

The two sentences are highly efficient; the first defines the function, and the second routes the alternative, leaving zero wasted language.

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

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

Given the specific, high-level nature of the operation, the description, combined with the platform focus and routing to MS To Do, provides all necessary context for an AI agent to correctly determine suitability and invoke the tool.

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

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

With 100% schema description coverage, the description does not need to elaborate on the parameters. It successfully uses the space to provide guidance on usage and scope, which is the appropriate function at this coverage level.

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 immediately identifies the specific action ('Marks a reminder complete') and the precise target application ('Apple Reminders (Reminders.app)'). It is distinct from other potential completion tasks.

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 provides explicit usage guidelines by telling the agent exactly when NOT to use it: if the reminder is in Microsoft To Do, it must use `todo_complete_task` instead, preventing incorrect tool selection.

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

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

Adds real behavioral context beyond the annotations: it enumerates the possible per-client outcomes (set up / already set up / can't be automated and why / not installed) and the follow-up step required (restart the app or open a new session). Given destructiveHint=true, it does not say whether existing config entries are merged, overwritten, or backed up — a meaningful omission for a config-mutating 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?

Front-loaded with the action and the target, and every sentence carries information about scope, targeting, or results. The long inline client catalog duplicates the schema enum (and is inconsistent with it, omitting opencode, goose, hermes, raycast, msty, cherry-studio), which is wasted length.

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

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

Output schema exists, so return values needn't be spelled out, yet the description still summarizes result states and next steps. For a destructive config mutation it should also cover merge/overwrite/backup behavior, 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%, so both parameters are already documented, including the valid client ids and that `confirm` is ignored. The description only restates 'Optionally pass a single `client` id' and lists a partial subset of clients, adding little beyond the schema baseline.

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

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

States a specific verb and resource ('Adds Local MCP to the config of the MCP-capable AI apps installed on this Mac') and names the catalog it draws from, so the agent knows exactly what is being modified. It is clearly distinguishable from siblings like list_missing_permissions and lmcp_install_upgrade.

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 concrete usage instructions: omit `client` to configure all installed apps, pass a single id to target one, and 'Pair with list_missing_permissions for fully agent-driven setup.' No explicit exclusions or when-not-to-use guidance, which keeps it below 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 flag destructiveHint=true and openWorldHint=true, but the description adds the substantive detail those hints cannot: recreate deletes the existing connector, an interactive ChatGPT window may open for sign-in, credentials are never handled or passed as an argument, Developer mode is enabled when possible, and the run returns run_id plus per-stage statuses. This is exactly the context that keeps an agent from misinterpreting a paused run as a failure.

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 action, then constraints, then the destructive flag, then the return shape — a sensible ordering. Nearly every sentence carries distinct operational value; it is dense but not padded, though the sign-in explanation runs slightly long for a tool with only three optional 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?

For a mutation tool with destructive and open-world hints, it covers the prerequisites (Developer mode), the auth handoff (user signs in themselves), the recovery path (recreate for token rotation), and the polling contract (run_id, wait_seconds, needs_user). An output schema exists, yet the brief return summary is still helpful and nothing an agent needs to call this 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 coverage is 100%, so baseline is 3; the description still adds meaning by explaining recreate as a destructive delete-and-rebuild for token rotation and by framing needs_user stages in the run output. That said, wait_seconds behavior is left entirely to the schema, so it is not a full superset of parameter guidance.

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 ("Connects this Mac to ChatGPT: creates (or repairs) the LMCP connector inside the user's ChatGPT account") and explains the resulting capability (ChatGPT can use this Mac's tools). That separates it cleanly from siblings like connect_m365_account, connect_servicenow, or lmcp_install_upgrade, which are per-service connectors rather than the ChatGPT-side connector.

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 conditions: run "on this Mac only", pass recreate:true for token rotation, and treat a stage with status needs_user as waiting-for-the-person rather than broken. It stops short of naming an explicit alternative (e.g. disconnect/reconnect paths or lmcp_doctor when setup is already broken), so it is strong context without full when/when-not routing.

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?

While annotations cover the destructive nature, the description adds crucial behavioral context: it states that `include_channel_messages` requires admin approval, and specifies the failure mode—the sign-in is refused and the account retains current access. This is vital process knowledge.

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

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

The description is highly efficient. It front-loads the core function, then immediately addresses the complex operational flow (external login), and finally details the permission constraints in a single, cohesive block of 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?

The description is highly complete. It covers the overall goal, the necessary external authentication sequence, and the specific behavioral rules around administrative permissions and potential sign-in failure.

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

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

The schema coverage is 100%, which is a strong baseline. The description elevates this by providing operational semantics—specifically explaining the consequence and prerequisite (admin approval) of the `include_channel_messages` boolean parameter.

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

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

The description provides a perfect functional overview: it defines the action (Connect/Add/Sign In) and the resource (Microsoft 365 account). It clearly distinguishes this tool from related list or delete functions by focusing on the connection setup process.

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 provides a critical procedural guideline by explicitly telling the agent that the tool call must be made after a specific external step (authentication at microsoft.com/devicelogin), which defines the necessary workflow.

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

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

The crucial non-obvious behavior is disclosed: credentials are entered by the user inside Local MCP and never transit the AI, so the agent knows it cannot programmatically authenticate. However, the annotations declare destructiveHint=true and readOnlyHint=false, and the description never reconciles that with what is otherwise an informational/instructional tool, leaving an agent unsure whether calling it mutates something.

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?

It is short and front-loads the security constraint, but the first sentence is pure repetition of the title and the nested UI path with its parenthetical fallback is dense and hard to parse. Roughly a third of the text is navigation detail rather than decision-relevant information for the agent.

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 an output schema present, return values need no explanation, and the description covers the security model and both use cases for a zero-required-parameter tool. The remaining gap is the unresolved signposted danger from destructiveHint and the lack of any note about what becomes available after connecting.

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?

There is a single optional parameter whose schema description already says it is 'Ignored; kept for older clients,' giving 100% coverage. The prose adds nothing about parameters, but the schema baseline of 3 applies since no clarification is needed.

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 opening sentence merely restates the name, but the closing sentence makes the actual function explicit: 'Call this to get these steps, or to check whether ServiceNow is already connected.' That distinguishes it from the operational servicenow_* siblings and from disconnect_servicenow, letting an agent recognize it as an onboarding/status tool rather than an API 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?

Two clear invocation triggers are given (retrieve the setup steps, or verify current connection state), which is enough context to select the tool. There is no explicit when-not guidance or routing to servicenow_list_my_incidents etc. once connected, which keeps it 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?

The description frames this as an informational call — retrieve steps or check status — and explicitly says the token is entered by the user in LMCP, "never passed through the AI." The annotations declare readOnlyHint=false and destructiveHint=true, which directly conflicts with that read-only framing, leaving an agent unable to know whether the call mutates anything.

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

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

The exact menu path is genuinely useful and the sentences are dense with actionable detail rather than filler. The second sentence is long and slightly run-on, but no clause 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?

An output schema exists, so return values needn't be described, and the setup path is fully specified. However, the description never resolves the mutation question raised by the annotations, nor what the manual path means for a user who cannot access the LMCP UI — gaps that matter for correct invocation.

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

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

Schema coverage is 100% and the single parameter is self-documenting ("Ignored; kept for older clients"), so the schema carries the load. The description adds no information about the parameter, which is acceptable at this coverage level but nothing more.

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 first sentence says only "Connect Todoist," while the body reveals the tool actually returns the manual connection steps or reports whether Todoist is already connected. The verb/resource is stated, but the real behavior is muddied by a name that implies the tool performs the connection. It does not clearly distinguish itself from siblings like disconnect_todoist or todoist_list_projects.

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?

"Call this to get these steps, or to check whether Todoist is already connected" gives an explicit trigger for invoking the tool. It does not name alternatives or state when not to call it (e.g. once connected, or when the user wants to disconnect), which keeps it below 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?

Adds real behavioral detail beyond the annotations: non-destructive to the source, and a failing target is refused with the list of mailboxes that were seen. However, annotations declare destructiveHint=true and the description never explains why — e.g. what happens if the message already exists in the target mailbox, whether it is overwritten or duplicated. That is the key risk an agent needs before calling a destructive-flagged 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 short sentences, front-loaded with what the tool does before the conditional cross-account rule and the failure behavior. Slightly dense parenthetical ('with account= the target is looked for in that account only') but every 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?

An output schema exists, so return values need not be explained, and the description covers the tricky bits: cross-account targeting and error reporting on a missing folder. Missing is any statement about collision/overwrite behavior in the target mailbox, which matters given destructiveHint=true.

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 earns above that by explaining the cross-account semantics of 'account' (omit it to target another account's mailbox; supply it to scope the lookup to that account), which the schema only says as 'pass it so the message is found in the right account'. It does not clarify the interaction between the required 'target_mailbox' and the optional 'mailbox'.

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 ('Copies an email'), the exact resource and destination ('another mailbox of the Mac's Apple Mail'), and clarifies the source is untouched ('the original stays where it is'), which implicitly separates it from move_email. It never names the sibling it is contrasted with, so the differentiation is inferred rather than explicit.

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 concrete when-to-do-what rule for the cross-account case: leave 'account' out and use a folder name unique to the target account, versus supplying 'account' to scope the search to that account. No guidance on when to prefer move_email or send_email instead, and no prerequisites (permissions, Mail.app state) are mentioned.

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

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

Annotations already disclose that this is a mutating, open-world, destructive operation, so the description does not need to repeat that safety profile. It adds useful behavioral context by identifying the Mac-specific target, the attendee-calendar limitation, and the M365 alternative, though it leaves the confirmation requirement for invitations 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?

The description is front-loaded with the core action and is only three sentences long. Every sentence carries useful selection or capability information, with no 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?

Given the 14-parameter schema, full schema description coverage, annotations, and an output schema, the description is complete enough to guide correct invocation. Minor omissions such as the confirm-gate nuance and calendar selection are already 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 the schema already documents all 14 parameters in detail. The description reinforces the three required fields and mentions attendees/recurrence, but adds little semantic 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 states a specific verb and resource: creating an event in the Mac Calendar app. It also distinguishes the tool from the Microsoft 365 sibling by naming m365_create_event as the alternative for M365.

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 frames when to use this tool (Mac Calendar events) and when to use the alternative (Microsoft 365). It also states the required fields and calls out that attendee invitations are limited to CalDAV/Exchange calendars.

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?

Goes well past the annotations: it discloses that reply drafts get a plain-text quote rather than Mail's styled quote, that html_body is downgraded to plain text in replies, and what quoted_original/threaded/unconfirmed mean, including the instruction to relay the non-threaded warning. It also explains the read-back-dependent mailbox fields and the multi-account placement rule — real behavioral context the hints do not carry.

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

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

The first clause is well front-loaded, but the body is a long semicolon-chained run-on that packs return-value semantics, quoting rules, threading caveats, and account selection into one block. Much of the tail (mailbox, draft_mailbox, threaded, quoted_original) restates what the output schema already documents, so several sentences do not earn their 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, zero-required, mutation-style tool, the description covers both operating modes, account targeting, attachment handling, and failure/degraded states. Nothing an agent needs in order to call it correctly or interpret a partial result 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 coverage is 100%, so 3 is the floor, and the description earns more by explaining the account/from placement mechanism, the reply_all and reply_to_message_id interaction, and the attachments format with a concrete example. A few parameters (cc, bcc, confirm) are still only described in the schema, so it stops short of full compensation.

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 precise verb+resource+destination ("Saves an email to the Mail.app Drafts folder") and immediately scopes it ("never sends"), which separates it from send_email and from the Outlook-flavored m365_create_draft sibling. It also splits the two operating modes (new draft vs. reply draft) explicitly.

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 when-to-use framing — 'the cautious user who wants AI-composed mail but insists on sending it themselves' — and explains the new-vs-reply branch conditions. It never names the concrete alternatives (send_email, m365_create_draft, reply_email), so an agent must infer the routing rather than being told it outright.

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?

Beyond the destructiveHint=false/readOnly=true annotations it discloses idempotency ('creates nothing and says so' if the name exists), a verification step ('reports created only after it sees the folder'), and the Exchange failure mode returning created=false with status server_unconfirmed.

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

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

The scaffolding constraint and account requirement are front-loaded, and every sentence carries information. It is dense with clauses (verification, Exchange fallback) but none are waste; slightly long-winded for a create 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?

Covers prerequisites (account disambiguation), duplicate handling, confirmation semantics, and the one platform-specific failure path, and even explains the returned status field despite an output schema existing. Nothing an agent needs to call this 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 coverage is 100%, so the baseline is 3; the description adds genuine meaning by explaining that `account` becomes required when multiple accounts exist and that omitting it is refused rather than defaulted. It does not explain `confirm` being a no-op, but the schema already labels it 'Ignored'.

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 (creates), resource (mailbox folder), and target platform (Mac's Apple Mail / one account). It explicitly distinguishes itself from m365_create_email_folder for Exchange mailboxes, so an agent can pick the right 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?

Gives explicit when-to-use rules: account is required when Mail has more than one account, the tool refuses to guess, and list_email_accounts supplies names. It also names the alternative tool and the condition (Exchange account) that routes to it.

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

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

The Markdown-to-native-formatting disclosure is genuinely useful behavioral context not present in the annotations. However, with destructiveHint=true set on a create operation, the agent gets no explanation of what that means (e.g. whether an existing note with a matching name is overwritten), nor any note about permissions or folder-creation side effects.

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, front-loaded with the action, and the second sentence carries real information. The Markdown clause duplicates the schema description, which is the only 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?

An output schema exists, so return values need no explanation, and all four parameters are documented in the schema. Still, the description never addresses the destructiveHint=false implication for name collisions or folder fallback behavior, leaving a create-with-overwrite ambiguity unresolved.

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 Markdown detail in the description largely restates the body parameter's schema description verbatim. The description adds nothing about the folder parameter's default or the ignored confirm flag, 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?

The description states a specific verb and resource ("Creates a new note in Apple Notes"), which cleanly separates it from read_note, update_note, list_notes, search_notes and delete_note. It stops short of naming any sibling explicitly, so it is clear but not maximally differentiating.

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

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

There is no guidance on when to use this versus update_note (append to an existing note) or obsidian_write_note / notion equivalents, and no prerequisites or caveats. The agent must infer that this is the creation path purely from the name.

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, openWorldHint=false, so the safety profile is covered; the description goes further by disclosing a hard failure mode (no fallback to inbox on a bad project name) and the Pro-tier requirement. Doesn't discuss whether the call is idempotent or what happens on duplicate names, which keeps it at 4.

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?

Four tight sentences, front-loaded with the verb and platform, then prerequisites, then the risky parameter behavior, then the return value. No sentence is filler and the failure warning sits right after the parameter that triggers it.

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?

An output schema exists so return values need little explanation, and the description still names the returned task id. For a 7-parameter creation tool it covers platform prerequisite, default routing, error behavior, and the required-name-only constraint — everything an agent needs to call it without a failed attempt.

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 earns above that by adding semantics the schema can't express — that `project` must match an existing project exactly and fails rather than defaulting. It says nothing extra about note, due_date, or the ignored `confirm` flag, which the schema already handles.

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 ("Creates a task in OmniFocus on this Mac") and scopes it to a concrete platform, which lets an agent separate it from todoist_create_task, todo_create_task, and create_reminder purely on the name-plus-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?

Gives explicit preconditions (OmniFocus Pro required; free tier blocks automation), the default behavior without `project` (inbox), and a named prerequisite tool to call first (`list_omnifocus_projects`) so the agent is routed away from a predictable failure.

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 destructiveHint=true and openWorldHint=true, so the description's clarification that nothing is sent externally meaningfully narrows what openWorld ties actually occur. It also discloses the return shape (one unique link per recipient) and the side effect (records are persisted for later attribution). It does not address the destructiveHint flag or whether repeat calls create duplicate invites, so it is strong but not complete.

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

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

The core action and return value are front-loaded in the first clause, and the non-sending caveat follows immediately where an agent needs it. The trailing `lang` sentence is somewhat redundant with the schema and could be dropped without loss.

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 an output schema present and annotations covering the safety profile, the description covers the essentials: what is persisted, that nothing is dispatched, and what comes back. The notable remaining gap is idempotency -- whether re-inviting the same person creates a second record or reissues the same link -- which matters for a write tool an agent may retry.

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 three parameters (including the vestigial 'confirm', marked as ignored) are already documented. The description's gloss on `lang` ('records the language the invite is written in') largely restates the schema, though it does tie the value to the actual invite text, adding mild interpretive value. 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 ('Records referral invites') plus the concrete payload ('a unique referral link per person') and the downstream purpose ('see who installed or activated LMCP'). An agent can distinguish this from list_referral_candidates purely on this text -- one lists candidates, this one records invites and mints links.

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 usefully clarifies what the tool does NOT do ('It does not send anything itself'), which steers the agent away from expecting delivery. But it never states when to call this versus list_referral_candidates, nor any prerequisite (e.g. recipients must first be picked from the candidate list). Usage is implied rather than specified.

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 it is not read-only and is destructive, so the mutation profile is already carried; the description adds a non-obvious behavioral trait — a date-only due_date silently produces no alarm/notification. It omits permission/authorization requirements (Reminders.app access) and what happens when list_name is omitted.

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 core action, then the two most failure-prone parameter interactions. No filler, though the delivery could be tightened into a bullet-like structure.

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 10 parameters, full schema coverage, an output schema, and annotations present, the description covers the risky interactions an agent would otherwise get wrong. It leaves minor gaps around default-list behavior and the recurrece_count/until precedence, but those are 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 coverage is 100%, so baseline is 3; the description earns extra by explaining the cross-parameter dependency between `recurrence` and `due_date`, and the time-vs-no-time semantics of `due_date` that the schema does not spell out.

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 ('Creates a reminder in Reminders.app'), which is unambiguous against siblings like update_reminder or create_reminder_list. It does not explicitly contrast itself with alternative creation tools (todoist_create_task, create_omnifocus_task), but the target app makes intent clear.

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 operational guidance on when to pass `recurrence` and when a `due_date` will or won't notify, which is genuinely useful. However, it offers no guidance on when to choose this tool over sibling creation tools or when not to use it.

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

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

Annotations already declare this is a non-read-only, destructive-flagged, closed-world write. The description adds real context beyond that: the account-placement rule, the case-insensitive duplicate-name failure mode, and the fact that the new list's id is returned. It stops short of describing permissions or what state exists after a failed call.

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?

Four tight sentences, front-loaded with the core action and account scope, then the failure condition, return value, and next step. No filler and nothing repeated from the schema.

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 two-parameter creation tool with an output schema, this covers the essentials: where the object lands, what breaks it, what comes back, and what to call next. Nothing an agent needs before invoking it 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 coverage is 100%, including the note that `confirm` is ignored, so the schema already carries parameter semantics. The description adds only indirect meaning by explaining there is no account parameter to choose. Baseline 3 applies 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 ("Creates a new list in Apple Reminders") and pins the scope ("in the same account as the default Reminders list"). It is clearly separable from create_reminder, which it explicitly names as the tool for adding items to the list.

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 advice: use create_reminder with this list name to populate it, and warns that a duplicate name (case-insensitive) causes failure. It does not point at get_reminder_folders/list_reminders as a pre-check to avoid that failure, so the when-not guidance is implied rather than complete.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the useful conditional that weather is only included 'when a location is provided' and that email is an unread summary, but it does not disclose the source services (which calendar/reminder provider, Mail vs. M365/Proton), behavior when accounts aren't connected or permissions are missing, or partial-failure handling — meaningful gaps for an aggregator spanning many siblings.

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: the content enumeration comes first, then the use-case framing. Only mild redundancy in restating the location condition already in the schema, and the em-dash aside is slightly dense but 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?

An output schema exists, so return-value detail is unnecessary, and the description covers the aggregate composition and the conditional weather component. What remains missing is guidance on multi-service dependency (connected accounts/permissions) for a tool that fans out across calendar, reminders, and mail.

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%, with both parameters fully documented in the schema (location format examples, include_emails default and Mail local-index nuance). The description only restates the conditional location behavior, adding essentially nothing 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+resource ('returns a single morning briefing') and enumerates exactly what is aggregated: calendar events, overdue/due-today reminders, unread email count + subjects, and conditional weather. This clearly distinguishes it from the many single-source siblings like list_calendar_events or list_reminders.

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 phrase 'Perfect for starting each day: one call gives you everything on your plate' implies the intended usage context, and by definition it is the alternative to making several separate list calls. However, it never explicitly says when to use this vs. calling list_calendar_events/list_reminders/list_emails directly, nor when not to use it (e.g. deep dives or filtering).

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, so the safety profile is covered. The description adds real behavioral detail the annotations cannot express: the confirm gate, the platform boundary, and the blast-radius distinction between deleting one occurrence versus an entire series. It stops short of stating irreversibility or what the deletion returns, which keeps it off 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 sentences, no filler, with the identification and confirm requirement front-loaded before the recurring-event nuance and the sibling pointer. Every clause carries operational weight.

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 destructive single-purpose delete with an output schema, full parameter coverage, and destructive annotations, the description covers platform, confirmation requirement, recurrence scope, and the correct alternative. Nothing an agent needs to invoke it safely 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 coverage is 100% and the span parameter's description already spells out 'this'/'future'/'all'/'series' semantics, so the description is largely restating structured data. It reinforces the default-single-occurrence behavior but adds no syntax or edge-case 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 and resource ("Deletes an event from the Mac's Calendar app (Calendar.app) by ID") and pins the platform, which immediately separates it from the many other delete/event tools. An agent can distinguish it from m365_delete_event and update_calendar_event without opening any 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 explicit preconditions ("Requires confirm=true"), the default behavior, the opt-in variant for recurring events, and an explicit alternative for the Microsoft 365 case ("use m365_delete_event instead"). When-to-use, when-to-use-something-else, and the safety gate are all stated.

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

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

Goes well beyond the annotations: discloses soft-delete semantics, the 30-day purge window, user recoverability, the specific refusal error code, and post-delete re-read verification with an 'unverified' outcome. This usefully qualifies the blunt destructiveHint=true. Minor gaps only: no mention that `confirm` is ignored, and no note on permissions/account selection.

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 and the two lookup modes, and each sentence adds real information about side effects or verification. Slight redundancy with the schema on the note_name tie-breaking rule and a dense final VERIFIED sentence keep it from a 5.

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

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

An output schema exists, so return shape needn't be explained, yet the description still covers the outcomes an agent must reason about (soft delete, refusal, unverified). For a destructive 3-parameter tool, nothing needed to call it safely 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 coverage is 100% and the schema already states the exact-title and first-match caveats, so most of the description's parameter content is repetition. The one added value is pointing to list_notes/search_notes as the source of note_id; the ignored `confirm` parameter is explained only in the schema, not the description. Baseline 3 fits.

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?

Specific verb + resource ("Deletes a note from Apple Notes") plus the two ways to identify the target (ID or exact title). It also names the sibling tools that supply the note_id, so an agent can distinguish it from update_note or read_note 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?

Gives explicit routing ("Find note_id with list_notes or search_notes"), a preference rule (prefer note_id when titles collide), and a clear when-not case: notes already in Recently Deleted are refused with note_already_deleted because a second delete would be permanent.

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

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

The annotations already declare destructiveHint=true and readOnlyHint=false, and the description reinforces this by saying the deletion is permanent. It also discloses the confirmation requirement, though it does not elaborate on failure behavior or the remember side effect beyond what the schema provides.

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?

It is two front-loaded sentences with no wasted text. The core action, ID source, and confirmation requirement are all stated efficiently.

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

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

For a destructive delete tool with rich annotations, full schema coverage, and an output schema, the description supplies the essential context: permanence, platform, ID source, and confirmation. It does not mention the remember parameter's persistent effect, but that is adequately 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 the schema already documents reminder_id, confirm, and remember in detail. The description adds the reminder_id source and confirm=true requirement, but these are largely already present in the schema descriptions.

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

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

The description states a specific verb and resource: permanently deletes a reminder in Apple Reminders by ID. It clearly distinguishes deletion from sibling actions such as complete_reminder, update_reminder, and delete_reminder_folder.

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 a clear precondition by telling the agent to get reminder_id from list_reminders and that confirm=true is required. It does not explicitly explain when to choose this over alternatives like complete_reminder, but the context is otherwise clear.

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

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

Annotations already flag destructiveHint=true, but the description adds what the hint cannot: the delete cascades to all contained reminders and is irreversible. It also surfaces the confirm=true gate — notable because the schema's required array is empty — which is exactly the behavioral context an agent needs before calling.

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, zero filler, with the destructive cascade and irreversibility front-loaded before the calling instructions. Nothing could be cut without losing operational meaning.

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 four-parameter destructive mutation with full schema coverage, annotations, and an output schema, the description covers everything an agent needs: scope of destruction, irreversibility, identifier options, and the confirmation gate.

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

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

Schema coverage is 100%, so baseline would be 3; the description earns more by restating that confirm is mandatory (the schema marks no required parameters) and by clarifying that name and list_id are interchangeable identifiers. The remember flag is left to the schema, which documents it well.

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

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

States a specific verb and resource (deletes an Apple Reminders list) plus a critical scope fact — every reminder inside it goes too. That cascading scope plus the resource name makes it unambiguously distinct from delete_reminder.

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 prerequisites («Requires confirm=true») and tells where to obtain list_id (get_reminder_folders), but never says when this tool should be chosen over siblings like delete_reminder or rename_reminder_folder. Usage is implied by the purpose rather than stated.

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

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

Adds substantial behavior beyond the destructiveHint annotation: stored sign-in is removed, default reassignment happens automatically to the oldest remaining account, the response reports the new default, and reconnecting requires the Microsoft sign-in flow again. These are exactly the consequences an agent needs before invoking a destructive disconnect.

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 the core action, then covers parameter requirements, default reassignment, and reconnection consequences in four compact sentences. Every sentence contributes useful information without repetition.

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 two-parameter destructive disconnect with full schema coverage and an output schema, the description covers the key operational facts: scope, account selection, default-account side effect, and reconnect requirement. No material information 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 coverage is 100%, so the schema already documents both parameters including accepted account identifiers and the confirm field being ignored. The description reinforces when account is required or optional but adds little beyond the schema, 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?

States a specific verb and resource (disconnects a Microsoft 365 account) and immediately scopes it to ONE account while noting that stored sign-in is removed. This clearly separates it from connect_m365_account and from broader account-management siblings.

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

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

Explains the key usage condition: account can be omitted only when one account is connected and must be provided when several are connected. It does not explicitly name alternatives such as list_m365_accounts for discovery, but the conditional guidance is clear and directly actionable.

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, so the safety profile is covered. The description adds the specific blast radius ('removes the credentials stored on this computer') and the consequence ('reconnecting requires the user to enter their credentials again'), which is real value beyond the annotation. It doesn't say whether other ServiceNow state survives, but the core destructive scope is disclosed.

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

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

The effect is front-loaded in the first clause, and the reconnect instructions that follow are directly actionable. The UI-path detail is slightly dense but earns its place as recovery guidance.

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

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

For a zero-required-param disconnect with annotations covering destructiveness and an output schema covering returns, the description supplies the essential missing context: what is deleted and how to undo it. A note on whether ServiceNow config or cached data survives would make it 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%, with 'account' documented as optional-unused and 'confirm' documented as ignored. The description adds nothing about either parameter, 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 and resource ('Disconnects ServiceNow: removes the credentials stored on this computer'), which unambiguously separates it from connect_servicenow and from the incident-reading siblings.

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

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

Usage is clear from the effect description, and the reconnect path (icon → My apps → Connect / Add apps…) tells the agent what follow-up the user needs. It never explicitly names connect_servicenow as the inverse or states when not to call it, so it falls 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 flag destructiveHint=true and readOnlyHint=false; the description adds real value by specifying the blast radius (only the token on this computer) and confirming reconnection needs a fresh token. It does not explicitly say whether remote Todoist data or tasks are untouched, which is the one lingering ambiguity for 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?

Front-loaded with the core action and effect in the first clause; the reconnect instructions are useful but the nested parenthetical UI path is slightly dense. No wasted framing.

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?

An output schema exists so return values need no explanation, and the description covers effect, reversibility, and recovery. Complete enough to call correctly, missing only an explicit note that Todoist tasks/data are unaffected.

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% - the schema already documents 'account' as optional (Todoist has one account) and 'confirm' as ignored. The description adds no parameter-level information, 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 (Disconnects) and resource (Todoist) plus the actual effect: removing the locally stored API token. That effect statement cleanly separates it from connect_todoist and from the many other disconnect_* siblings.

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

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

Implies the appropriate moment to call it (user wants to unlink Todoist) and goes further by spelling out the recovery path via LMCP's icon → My apps → Connect. No explicit 'do not use when...' or pointer to a sibling alternative, so it stops 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 only say readOnly=false and destructive=true; the description adds the crucial nuance that a call without confirm is effectively a dry run that changes nothing, and that confirm=true restores the app to My apps. It further discloses that for Calendar/Reminders/Contacts OS permission is separate, that the tool only reports whether macOS granted it, and that the consent dialog appears on the Mac running LMCP — possibly not the user's machine over Cloud Relay.

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?

Purpose and trigger are front-loaded in the first two sentences; the remainder is dense but each clause carries operational meaning (confirm semantics, permission dialog location). The final sentence is a long run-on that could be split for readability.

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 usefully covers the no-confirm return ('describes what comes back') and the side effects of confirm, plus the OS-permission caveat. It doesn't describe the shape of a successful enable response, a minor gap for a two-parameter mutation tool.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes beyond it by explaining the two distinct triggers for confirm (dismissed service, or any cloud-relay call) and tying service identity to the OS-permission caveat for calendar/reminders/contacts. It stops short of enumerating valid service ids, but the schema already provides examples.

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 ('Turns a service back ON in LMCP') and scopes it to the recovery case ('after the user turned it off'). It names the exact error markers (service_off, service_dismissed) that identify the situation, which no sibling tool describes.

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 says when to call it — when another tool reports service_off or service_dismissed — and explains the branch conditions: direct/AI-client calls proceed, cloud-relay or dismissed services need confirm. It also states when nothing changes (no confirm) versus when the app is restored to My apps.

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, so the description does not need to restate that it writes. The description adds substantial behavioral context beyond annotations: exact JSON-to-cell type coercion rules, preservation of numeric-looking strings as text, long-integer handling for identifiers, and the limitation that '=' strings are text rather than formulas. Overwrite/destructive specifics are left to the schema's overwrite parameter, so a 4 rather than 5 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?

The description front-loads the core action in the first sentence, then spends subsequent sentences on the non-obvious typing and formula behavior. Every sentence contributes useful information, and there is no redundant restatement of schema fields.

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 that an output schema exists and the overwrite behavior is fully described in the input schema, the description covers the critical non-obvious behavior: data typing, identifier preservation, and formula handling. No essential calling context 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%, so a baseline of 3 is warranted even without extra parameter prose. The description goes beyond the schema by explaining how row values are interpreted—numbers as numeric cells, strings as text even when numeric-looking, booleans as boolean cells—which materially helps an agent populate the rows parameter correctly.

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: creates a new Excel .xlsx file with headers and optional rows. It also distinguishes its behavior from excel_write_cell by explaining that strings beginning with '=' are text, not formulas, so an agent can tell when to use this tool versus the 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?

Clearly implies use for creating a new spreadsheet and explicitly redirects formula insertion to excel_write_cell. It does not enumerate when to avoid excel_create in favor of file_write or word_create/ppt_create, but for its primary scope the usage context is clear.

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

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

Annotations already establish readOnlyHint, destructiveHint=false, and openWorldHint=false. The description adds useful behavioral detail by explaining the returned headers/rows layout and the round-trip alignment with excel_create, which is meaningful beyond the structured annotations.

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

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

Two tightly written sentences with the core behavior front-loaded and zero redundant text. The round-trip note earns its place by adding practical context.

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

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

The description is complete for a read tool whose annotations cover safety and whose schema covers all parameters. Even though an output schema exists, the description helpfully summarizes the return shape without becoming verbose.

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 path, max_rows, sheet_name, and force_download thoroughly. The description does not add input-parameter semantics beyond noting the header/data-row output mapping, 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 and resource ('Reads data from an Excel spreadsheet') and distinguishes the operation from sibling spreadsheet tools like excel_create and excel_write_cell. It also clarifies the returned structure, so an agent knows exactly what this tool produces.

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 by explaining the read→create round-trip relationship with excel_create, which helps an agent understand the tool's role. It does not explicitly state when not to use it, but there is no competing Excel-read sibling, so the context is sufficient.

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?

Goes well beyond the readOnlyHint=false/destructiveHint=true annotations: it discloses numeric coercion rules, formula evaluation timing, an exhaustive list of refused dangerous formulas, and the key side-effect guarantee that "nothing is written" on refusal. It also clarifies that sheet_name never silently falls back to the first sheet.

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 the core action and the addressing rule, then layers in value-coercion rules. The long parenthetical enumeration of refused formula functions is dense but each item carries real refusal information; trimming it would lose behavioral specificity.

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 destructive single-cell write with an output schema, the description covers the risky behaviors and parameter addressing thoroughly. It leaves open edge cases like a missing file at `path` or whether a nonexistent sheet is created, but nothing essential to a correct call is absent.

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

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

With 100% schema coverage the baseline is 3, but the description adds real semantics: what `value` means for numbers, formulas, and apostrophe-prefixed text, plus the either/or relationship between `cell` and `row`+`column`. It does not touch `confirm` (documented in schema as ignored) or `path` requirements.

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 ("Writes a value to a specific cell in an Excel file"), which cleanly separates it from excel_read, excel_create, and non-Excel writers like word_append. The scope (single cell) is unambiguous.

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

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

Usage is implied by the write-a-cell scope and the two addressing modes, but the description never says when to prefer this over alternatives such as excel_create or when to read first with excel_read. No explicit when-not guidance is given.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the home-directory default, the returned attributes, and the sort order (directories first, then alphabetical), which tells the agent what output shape to expect.

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 with zero filler; the core action and default scope come first, then return fields, then ordering. Nothing is repeated or 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 two-parameter, read-only listing tool with a full output schema and clear annotations, everything an agent needs to call it correctly is present: default path, hidden-file behavior, and result ordering. The return-value sentence is slightly redundant against the output schema but harmless.

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 both parameters are already documented in the schema. The description restates the same defaults (home directory, hidden files excluded implied by show_hidden) without adding syntax, path-validation behavior, or examples, 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?

Opens with a specific verb+resource ('Lists files and folders in a local directory') and pins the scope with a default location. That clearly separates it from file_read or file_search, but it never distinguishes itself from the very similar sibling finder_list, leaving an agent to guess which local lister to pick.

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?

Usage is only implied by the tool's shape – enumerate a directory when you need its contents. There is no explicit when-to-use guidance, no exclusions, and no pointer to alternatives such as finder_list for Finder-specific listings or file_search for lookups by name.

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 and destructiveHint=false, so the safety profile is covered; the description goes well beyond that by naming the specific locations that are never read (keychains, ~/.ssh, ~/.aws, browser logins, other users' homes, Time Machine), disclosing encoding auto-detection with a Latin-1/Windows-1252 fallback, and noting that cloud-evicted files fail by default. These are behaviors an agent cannot infer from 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?

Front-loaded with the core verb+scope, then constraints, then alternatives — a sound structure. It is dense and long for a read tool (three packed clauses plus a long prohibition list), but nearly every clause carries unique routing or safety information, so little is expendable.

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?

All four parameters are documented in the schema, an output schema exists so return values need no prose, and annotations cover the safety profile. Given that, the description supplies everything remaining an agent needs: default status, format exclusions, cloud-store routing, security boundaries, and encoding behavior.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantics for the 'path' parameter by enumerating supported extensions (.txt, .md, .csv, .json, .xml, .log, .yaml, .toml, common code types) and describing how content is decoded, which the schema does not. Offset/max_bytes/force_download details are already in the schema and are not duplicated.

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 ('Reads a plain text file from the local filesystem by its absolute path') and immediately positions itself as the primary/default text-file reader. It explicitly names the document-format siblings (PDF, Word, Excel, PowerPoint) that require a different tool, so an agent can distinguish it without opening any 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 when-to-use ('use this unless the file is a PDF, Word, Excel, or PowerPoint document') plus per-source routing: OneDrive -> onedrive_read_file, Google Drive -> gdrive_read_file, PDFs -> pdf_read, Word -> word_read, Excel -> excel_read. This is exactly the when/when-not/alternatives triad.

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, openWorldHint=false, destructiveHint=false, so safety is covered. The description adds genuinely non-obvious behavior: the ~$ lock-file exclusion, the ~/Library exclusion unless root points inside it, and the most-recently-modified-first ordering. These are real behavioral facts not present in 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?

Three dense, front-loaded sentences with no filler; scope comes first, then defaults, then return shape and exclusions. Slightly overloaded by combining ordering and two exclusion rules into one sentence, 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?

An output schema exists so return values needn't be spelled out, yet the description still summarizes path/type/size. Exclusions, defaults and ordering are covered; it stops short of noting whether results can be truncated at max_results or how deep recursion goes, which are the remaining gaps for a filesystem search.

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 description's parameter facts (default home root, case-insensitive partial match) duplicate the schema's own root and query descriptions. Baseline 3 is appropriate; nothing meaningful is added about file_type or max_results semantics (e.g., truncation behavior).

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?

Specific verb+resource ('searches for files and folders by name') plus match semantics (case-insensitive, partial) and scope (root directory). It does not distinguish itself from the many sibling search tools (finder_search, file_list, gdrive_search_files, onedrive_search_files), so an agent cannot pick it over those from the description alone.

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?

Usage context is implied by 'starting from a root directory' and 'Defaults to the home directory', plus two negative rules (lock files, ~/Library). But there is no explicit guidance on when to choose this over finder_search or file_list, which is the main ambiguity for an agent with these siblings.

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

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

Annotations declare destructiveHint=true; the description goes beyond that by disclosing the safety carve-outs (no shell startup files, LaunchAgents, git hooks, AI-client configs, credential paths) and the recovery guarantee that overwrites keep a prior version and report its location via `previous_version`. That is exactly the context a destructive write tool needs, though rate limits or failure modes are unaddressed.

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 verb and resource, then the format routing, then the security exclusions and overwrite semantics. Dense but every sentence carries information; the format enumeration and the sibling parenthetical overlap slightly, which keeps it from a 5.

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

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

For a destructive, open-world=false write with a full output schema and complete parameter documentation, the description supplies everything missing: allowed scope, forbidden targets, append vs overwrite semantics, and backup behavior. Return-value detail is already covered by the output schema.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an increment by tying `append=true` to adding to the end and by explaining the consequence of the default overwrite path (prior version preserved, path returned as `previous_version`). It also implicitly reinforces that missing parent folders are auto-created rather than erroring.

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 ('Writes text to a local file') plus the three modes (create, overwrite, append) and the supported file classes. It explicitly routes document formats to siblings (word_create, excel_create, ppt_create), so an agent can distinguish it 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?

Names the alternatives and the condition that selects them: plain text/code files here, Word/Excel/PowerPoint via word_create/excel_create/ppt_create. It also declares the write-scope policy up front (two exception categories), so the agent knows when this tool is not permitted.

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 provide readOnlyHint=true and destructiveHint=false; the description adds valuable context beyond that: it refuses credential and identity locations and states it is Spotlight-free. This goes beyond what annotations alone declare.

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 core action, and no filler. Each sentence earns its place: core function, scope, and security exclusions all appear in compact form.

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

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

The output schema plus annotations carry return values and safety, and the description covers base function, scope, and sensitive-path behavior. It is complete for a simple list tool; finer details like hidden files or error behaviors are not critical for correct invocation.

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

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

Schema coverage is 100% and both parameters (path and limit) already have descriptions. The tool description does not add parameter-level meaning beyond the schema, so it meets the baseline for high schema coverage.

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

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

The description uses a specific verb ('Lists') and resource ('files and folders in a directory') and sharpens scope with 'any folder on this Mac' and 'Spotlight-free'. It clearly differentiates from search-like siblings, but it does not explicitly distinguish itself from the adjacent file_list 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?

No explicit guidance on when to prefer this tool over alternatives such as file_list or finder_search. The sensitive-path refusal gives clear negative boundaries, and 'Spotlight-free' implies a non-indexed file list, but the description leaves the when/when-not comparison mostly implicit.

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=false. The description adds useful behavioral context beyond that: it uses mdfind/Spotlight, searches globally unless path is supplied, and refuses credential/identity locations. It does not discuss performance or result limits, but the output schema covers return shape.

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 core action and scope, then the path-scoping modifier and safety boundary. There is no 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 read-only local file search with an output schema and clear annotations, the definition covers the essential operational context: search mechanism, scope, optional path narrowing, and refusal boundaries. The main omission is explicit routing versus sibling file-search tools.

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 three parameters are already documented. The description reinforces path scoping, but it describes the query as searching by name while the schema says 'Filename or content', and it does not add syntax or behavior for limit or query matching beyond the schema.

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

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

The description gives a specific verb and resource (searches for files), a clear scope (anywhere on this Mac), and implementation detail (mdfind/Spotlight). It does not explicitly distinguish this from close siblings such as file_search or finder_list, so it falls short of a 5.

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

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

The description implies local Mac file search and mentions that path= can scope results to one folder, plus it states that credential and identity locations are refused. However, it does not explicitly say when to use this instead of file_search, finder_list, or cloud search siblings.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the mutation risk is known. The description adds value beyond that by explaining the default (red), that 'none' clears rather than sets, and that the result is what Mail reads back after the change, which tells the agent the change is confirmed post-write rather than fire-and-forget.

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, front-loaded with the operation and scope, followed by parameter sourcing. The 'answer is what Mail reads back' sentence is slightly wasted given an output schema exists, but it is short and not harmful.

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?

Annotations cover safety and an output schema covers return values, so the description only needs to explain the operation and lookup strategy, which it does. Minor gap: no guidance on what happens if the message id or account is wrong (fallback scan behavior, error shape).

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 color enum values, the default, and the mailbox/account meanings are already documented. The description largely restates those and only adds the sourcing hint (ids come from list_emails/search_emails) and the scanning-avoidance rationale, which the schema already mentions for mailbox. 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 ('flags an email in the Mac's Apple Mail') and covers the inverse operation (clearing with color=none). The Mail.app scoping implicitly separates it from the m365/proton/thunderbird email siblings, but no sibling is named, so an agent must infer the platform distinction.

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 concrete invocation guidance: pass account=/mailbox= sourced from list_emails/search_emails so the message is found without scanning. It does not state when to prefer this over other email tools or what to do if the id is unknown, but the platform scoping plus the data-source hint covers the practical decision.

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?

Goes well beyond destructiveHint=true by explaining the mechanism: Google Drive for Desktop syncs the deletion to the cloud, the item lands in Drive's trash (so it is recoverable), and pointer files delete the underlying real document rather than the shortcut. It also discloses a safety guard (non-empty folders are never deleted) and notes that the confirm parameter is ignored — genuinely useful behavior an agent could not infer from annotations.

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

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

Two dense sentences, with the destructive scope and cloud-sync consequence front-loaded, followed by the pointer caveat and the folder guard. No filler, and each clause carries a distinct operational fact.

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 destructive file-removal tool this covers what is needed: what gets deleted, where it goes (trash), how pointers behave, and what is refused. An output schema exists, so 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%, so the path format and the 'ignored' status of confirm are already documented in structured fields. The description adds no parameter-level detail beyond that, so the baseline of 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 with explicit scope: deletes a file or empty folder within the synced Google Drive folder. It also distinguishes the special case of .gdoc/.gsheet/.gslides pointers, which no sibling tool covers, so an agent can separate it from onedrive_delete_file and recipe_delete.

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 establishes preconditions implicitly ('Never deletes a folder that still has contents', the path must be under a Drive mount), but it never states when to pick this over siblings such as onedrive_delete_file, nor does it route the agent to gdrive_file_info or gdrive_list_files to confirm a path before deleting. Usage is inferable but not spelled out.

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; the description adds real context beyond that: the effect is scoped to Local MCP tooling, the Google Drive sync app remains signed in, re-enabling requires a manual UI path (icon → My apps → app row → Read · Send · Write), and 'No tool turns it back on'. That last point is critical information an agent cannot get from any structured field.

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 effect, then the recovery path, then the parameter rule. It is a dense single block and the re-enable navigation path is verbose, but every clause carries information an agent would otherwise lack.

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 destructive, irreversible-from-tooling perspective action with an output schema available. The description covers effect, non-effect (no sign-out), parameter sourcing, and the absence of a reversal tool — nothing material is missing for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds semantics the schema alone does not: `account` must be the folder's name as returned by gdrive_root, and the conditional requirement is restated in prose. The `confirm` parameter's no-op status is already in the schema, so it is fairly left unmentioned.

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 with scope: 'Turns one Google Drive folder off in Local MCP', and immediately narrows what that means ('its tools stop reading it'). It also preempts confusion with the many other disconnect_* siblings by clarifying this is not a sign-out of Google Drive.

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

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

Explains when to supply `account` (omitted with one folder, required with several) and states the important exclusion that nothing is signed out because Local MCP holds no Google Drive credentials. It does not name a sibling alternative for account-level sign-out, but the 'this is not a sign-out' framing effectively routes the agent away from the wrong mental model.

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 adds the 'synced' context and a performance note, but does not detail return format or edge cases; output schema covers the return shape. This is minimal extra context, hence a 3.

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

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

The description is one succinct sentence that front-loads the purpose and includes a useful cost comparison. No redundant words or 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 simple tool with one parameter, an output schema, and clear annotations, the description is complete. It states what is returned, the target resource, and a key differentiator, which is enough for correct selection and invocation.

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

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

Schema coverage is 100%: the single required 'path' parameter has a clear description. The description adds only a minor contextual note about the synced Google Drive, not materially expanding on the schema. Baseline 3 is appropriate.

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

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

The description clearly identifies the tool as returning metadata (size, dates, type) for a file/folder in the synced Google Drive, and it distinguishes itself from sibling tools by noting it is cheaper than listing the whole directory. This gives a specific resource and a differentiator.

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 implies when to use this tool: when you need metadata for a specific file/folder and want a cheaper alternative to listing a directory. However, it doesn't explicitly name sibling alternatives or provide exclusionary guidance, so it stops 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?

Beyond the readOnlyHint and destructiveHint annotations, the description adds valuable context: it specifies the paths refer to the 'locally-synced folder' and that results are truncated to `limit` entries with a default of 1000. This gives the agent a more accurate behavioral model.

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

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

The description is three sentences long: the first states the core action, the second provides a prerequisite, and the third details the limit bound. Every sentence earns its place, and the text is front-loaded, making it easy for an agent to parse quickly.

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

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

For a list tool with an output schema and read-only annotations, the description covers all essential aspects: what it lists, where (locally-synced folder), how to get valid paths, and the result limit. It is sufficiently complete without needing to explain return values since an output schema exists.

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

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

The input schema fully describes both parameters (`path` and `limit`) with their types and limits. The description's mention of 'limit entries (default 1000)' simply restates schema information, adding no new semantic meaning. Since schema coverage is 100%, the baseline of 3 is appropriate.

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

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

The description clearly states the tool's action ('Lists files and folders') and resource ('in a Google Drive path'). This distinguishes it from sibling tools like gdrive_search_files and gdrive_file_info, which serve different purposes.

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

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

The description provides a clear prerequisite ('Use gdrive_root first for valid roots') and clarifies path structure ('My Drive' and 'Shared drives' are inside each mount). It does not explicitly mention alternatives, but the usage context is clear enough for an agent to decide when to invoke it.

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

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

Beyond the readOnlyHint annotation, the description adds useful behavioral context: it auto-detects UTF-8 with Latin-1/CP1252 fallback, and warns about .gdoc/.gsheet pointer files. It does not contradict any annotation and enhances the agent's understanding of edge cases.

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 main action, then important caveats, and closes with an alternative. Every sentence adds value with no waste.

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

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

Given the presence of an output schema, complete parameter documentation, and read-only annotations, the description covers all essential aspects: file types, encoding behavior, Google Drive specifics, and when to use a different tool. The tool is simple, and the description leaves no major questions.

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

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

Schema description coverage is 100%, so the schema fully documents all four parameters. The description's mention of auto-detected encoding aligns with the encoding parameter but adds no new syntax beyond the schema. This matches 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?

The description clearly states the tool 'Reads a text file from the synced Google Drive folder' with a specific verb, resource, and scope. It distinguishes itself from the sibling file_read by explicitly noting 'For files outside Google Drive, use file_read'.

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

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

Provides explicit when-to-use (text files in the synced Google Drive folder) and when-not-to-use (native Google Docs/Sheets/Slides, which sync as .gdoc/.gsheet pointers). It also names an alternative (file_read) for files outside Google Drive.

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 read-only/safe/non-open-world, yet the description adds substantial non-obvious context: it reads the locally synced Drive for Desktop folder, requires no Google API or OAuth, and explains what each output `permissions` key means and how a missing key or `read_only: true` should be interpreted. That is real behavioral disclosure beyond what the annotation set provides.

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

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

The core purpose and entry-point guidance are front-loaded in two clean sentences, but the second half is a dense, UI-path-heavy explanation ('LMCP's icon → My apps → open the app's row → the account's Read · Send · Write') that reads like configuration documentation and occupies more than half the 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?

With an output schema present and no parameters, the description covers purpose, sequencing relative to siblings, auth model, and output field semantics — nearly everything needed to call it. It omits edge cases such as what happens when Drive for Desktop isn't installed or no accounts are synced.

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

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

The tool takes zero parameters, so the baseline is 4 per the rubric; the description correctly adds no parameter detail because none exists. The output-field explanation belongs to output semantics rather than parameters, so it doesn't raise this score further.

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

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

States a specific verb and resource — 'Lists the Google Drive folders synced on this Mac' — and enumerates the scope (My Drive, Shared drives, per-account mounts). An agent can immediately distinguish it from gdrive_list_files or gdrive_search_files, which operate on contents rather than roots.

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?

'Start here to get valid paths for the other gdrive_* tools' explicitly routes the agent to this tool before the siblings that need paths. It gives clear positive guidance but no exclusions or when-not conditions (e.g. unlike onedrive_root for OneDrive, which is never mentioned).

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable behavioral details beyond the annotations: it is recursive, returns at most max_results (default 50), and searches by name. This provides meaningful context about the tool's behavior without contradicting the annotations.

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

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

The description is a single, front-loaded sentence that immediately states the tool's purpose and key constraints. Every phrase earns its place: 'synced Google Drive folder,' 'by name (recursive),' and 'max_results matches (default 50).' There is zero wasted wording.

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 that an output schema exists and annotations are present, the description does not need to explain return values or safety. It covers the essential action, scope, recursion, and result limiting. The only minor gap is that it does not clarify what 'the synced Google Drive folder' refers to (e.g., whether it searches all mounted Google Drives by default), but the root parameter and schema help fill that in.

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%, meaning all three parameters are already documented. The description adds no new parameter-level details beyond what the schema provides—it only reiterates the 'by name' and 'max_results' concepts. Since the schema carries the full load, a baseline score of 3 is appropriate.

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

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

The description states a specific verb ('Searches'), a specific resource ('the synced Google Drive folder'), and the scope ('by name (recursive)'). This clearly distinguishes it from sibling tools like gdrive_list_files or gdrive_read_file. The purpose is unambiguous and immediately understandable.

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

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

The description implies its usage context: searching for files by name in Google Drive. However, it does not explicitly mention alternatives or exclusions, such as 'use this instead of gdrive_list_files when you need to find a file by name.' The guidance is implied rather than explicit, so it earns a mid-range score.

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

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

Annotations already flag destructiveHint=true; the description goes further by explaining that uploads go through the official client automatically, that overwriting preserves the previous version in LMCP's own folder, and where that location is surfaced in the response — exactly the 'what gets destroyed and how it is recoverable' detail the hint cannot convey.

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

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

Two sentences, front-loaded with the action and scope, followed by the overwrite/backup behavior. No filler or restated title.

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?

An output schema exists so return-format explanation is unnecessary; the description still supplies the one behavioral fact an agent needs (overwrite is safe because the prior version is kept and reported), leaving no significant gap for a destructive write tool.

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

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

Schema description coverage is 100%, so the schema already documents path, content, and the ignored confirm flag; the description adds only the overwrite-vs-create distinction for path, which is marginal beyond the schema baseline.

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

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

States a specific verb and resource ('Writes or overwrites a text file') plus the exact scope ('synced Google Drive folder'), which separates it from file_write, onedrive_write_file, and the read/delete gdrive siblings without needing their 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?

Usage is implied by 'text file in the synced Google Drive folder', but there is no explicit guidance on when to pick this over onedrive_write_file or the generic file_write, and no stated exclusions or prerequisites (e.g. mount must be connected).

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 description doesn't need to restate safety. It adds genuinely new context beyond annotations: the per-entry field list and the important caveat that terminal command side effects are NOT captured, which prevents an agent from over-trusting the log as a full activity record.

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 core behavior, then the returned fields, then the scope caveat. No redundancy and the most decision-relevant caveat is placed last without burying the lead.

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?

Output schema exists so return values needn't be explained, annotations carry the safety profile, and the description covers purpose plus its key limitation. Only the filter/limit behavior is left entirely to the schema, which is a minor gap for a read-only log tool.

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

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

Schema description coverage is 100%, so ok/tool/limit are already fully documented in the schema; baseline 3 applies. The description adds nothing about filtering or default/max limits beyond what is already structured.

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 ('Returns recent LMCP tool call history from the local audit log') and enumerates the fields each entry contains, so the agent knows exactly what comes back. It doesn't explicitly point at neighboring diagnostics tools (run_diagnostics, lmcp_doctor, submit_diagnostics), so sibling differentiation is implied by subject matter rather than stated.

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?

'Useful for debugging and for reviewing what Local MCP's tools did' gives clear usage context, and the closing sentence defines the boundary condition (incomplete while run_terminal_command is enabled). There is no explicit when-not or named alternative tool, which keeps it below 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/destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond that: how secrets are masked, with every non-allowlisted key returned as `<key>_set: true/false` rather than a value. This tells the agent how to interpret the output, though it omits any note on failure modes.

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, front-loaded with what is returned, then the masking rule that governs how to read it. Every clause carries information an agent needs; no 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?

An output schema exists, so return values need not be re-explained, and the description still adds the secret-masking convention that shapes interpretation. The only gap is absence of disambiguation against sibling config/state tools.

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

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

The tool takes zero parameters, so there is nothing to document and the baseline is 4. The description correctly spends no space on parameter semantics.

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

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

States a specific verb (Returns) and resource (the current LMCP configuration) and enumerates the contents: connected integrations, feature flags, license status. This is clear, though it does not distinguish itself from close siblings like lmcp_state, lmcp_doctor, or permissions_status.

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

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

No explicit when-to-use or when-not-to-use guidance, and no alternatives named. With siblings such as lmcp_state and lmcp_doctor in the same domain, the agent is left to infer when config introspection is appropriate rather than being routed.

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