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

Annotations already declare readOnly=false, idempotent=true and destructive=true, so the safety profile is partially covered. The description adds real value by clarifying that approval has no external effect, but it never explains why the call is flagged destructive, what state becomes immutable after approval, or whether it can be undone — the most consequential unknowns for a destructive, idempotent mutation.

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

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

Two tight sentences with no filler. The operation and the key scope constraint lead; the non-effect clarification follows immediately.

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 fairly excused, and the human-confirmation gate is stated. But for a destructive, idempotent approval step the description leaves the actual state transition, error conditions (stale version, unconfirmed draft), and consequence of the destructiveHint unexplained — more is warranted given the mutation risk.

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 0%, so the description must carry the burden and it only partly does: 'one exact persisted draft version' maps loosely to draftId plus version, and 'explicit human confirmation' names the third parameter's intent. It adds no detail on the UUID format, the version>0 constraint, or what string the confirmation field expects (e.g., an echo of the version).

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 (Approve), a precise resource (one exact persisted draft version), and a scope qualifier ('exact persisted version') that separates it from save_daily_draft/update_daily_draft. The closing clause 'does not publish externally' pins down what the tool is NOT, distinguishing it from publish_to_notion and publish_to_calendar in the sibling 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 a clear precondition ('after explicit human confirmation') and an explicit exclusion ('does not publish externally'), which effectively routes the agent away from the publication siblings. It stops short of naming the specific alternative to use when the intent is to publish, or saying when approval should be withheld.

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 openWorldHint=true, so the safety profile is covered. The description adds that it reads local Apple Calendar state and conditionally verifies the event, but it does not explain failure behavior when Calendar access is unavailable or what verification entails.

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 a single front-loaded sentence with no filler. The phrase 'verify the event when Calendar access is available' slightly muddles the structure by combining status reading with an undefined verification action.

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 described, but the definition still leaves key gaps. With two required undocumented parameters and many sibling publication tools, the agent lacks enough information to confidently route and invoke this 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 0%, and both required parameters, draftId and version, are undocumented in the description. The description gives no meaning for either parameter, including what 'version' refers to in the publication workflow.

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, 'Read,' and a specific resource, 'local Apple Calendar publication state,' which distinguishes it from the Notion publication status sibling. The added 'verify the event' phrase is somewhat vague, but the core purpose is 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?

It gives only a conditional availability note, 'when Calendar access is available,' which is not a usage guideline. It does not explain when to use this instead of get_notion_publication_status, preview_calendar_publication, or publish_to_calendar.

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, so safety is covered. The description goes beyond that with a genuinely useful caveat: results are attempts, not proof that pushes succeeded, which prevents the agent from treating counts as success metrics. It does not mention pagination, volume limits, or timezone behavior of the returned data.

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 purpose and immediately followed by the semantic caveat. Nothing is redundant 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?

No output schema exists, so the description carries the burden of return-value semantics, and it does address that in one line (attempts, not successes). For a one-parameter read tool this is nearly sufficient; the missing piece is the accepted date string format and whether results include per-push detail or only aggregates.

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 0% and the single parameter is documented only as type string. The description adds real meaning by specifying 'local calendar date' (i.e., not UTC, not a range), but gives no expected format or example value, so an agent still has to guess the accepted representation.

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

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

Names a specific verb ('Read') and resource ('Git pre-push attempts') with scope ('for a local calendar date'). It is unmistakably distinct from the draft/Notion/calendar publication siblings, which all concern publishing workflows rather than local Git activity.

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 statement of when to prefer this tool over a sibling, no prerequisites, and no exclusions. The purpose sentence implies the usage context, but no alternative or condition is ever named.

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. The description adds useful context that revisions are immutable and all are returned, but it does not disclose error behavior, lookup failure cases, or authorization requirements.

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

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

A single focused sentence with the core purpose front-loaded. Every word contributes to stating what is read and what is returned.

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 exists, so return values need not be explained. Still, for a one-parameter tool with zero schema description coverage, the description should clarify what draftId refers to and what happens if it is invalid or 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 0%, so the description carries full responsibility for explaining the single draftId parameter. It never mentions draftId, its UUID format, or how it is used, leaving the schema name as the only clue.

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 ('Read') and resource ('daily draft') and adds that all immutable revisions are included, which helps distinguish it from list_daily_drafts. However, it does not explicitly contrast with sibling retrieval tools like get_daily_activity.

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

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

The description gives no guidance on when to use this tool versus list_daily_drafts, get_daily_activity, or save_daily_draft. Usage is only implied by the verb 'Read' and the noun 'daily draft'.

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 readOnlyHint annotation already establishes that this is a safe read operation. The description adds that the status is 'local' and includes 'retry status,' which is useful context beyond annotations, but it does not explain whether the local status may be stale or what retry semantics mean.

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 with no wasted words. Every phrase contributes to identifying the resource and scope.

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

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

Although an output schema exists, the 0% parameter schema coverage leaves the meaning of draftId and version ambiguous. The description also does not clarify how this local status relates to the publish/preview tools, so an agent has gaps to resolve before calling it confidently.

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 0%, so the description must explain the parameters. It only vaguely refers to 'one draft version' and does not clarify whether 'version' means a draft version number or a publication retry attempt, nor does it explain the draftId format or constraints.

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 ('Read') and a specific resource ('local per-item Notion publication and retry status') scoped to one draft version. It implicitly distinguishes itself from publish_to_notion and preview_notion_publication, though it does not name sibling tools 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?

There is no explicit guidance on when to use this tool versus alternatives such as preview_notion_publication or get_calendar_publication_status. The phrase 'for one draft version' gives minimal context but does not clarify prerequisites or exclusions.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description's burden is lower. It adds a useful scope word ('current' versions) but says nothing about result ordering, volume, or pagination behavior for what is implicitly a list endpoint.

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?

One front-loaded sentence with the resource first and the optional filters after; nothing is wasted. Its brevity is close to under-specification rather than over-verbosity, so it isn't penalized heavily here.

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. But with 0% parameter description coverage and no annotations beyond readOnlyHint, the definition should still specify date/timezone formats or default listing scope for an agent to call it confidently.

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 0%, so the description carries the burden, and it does name all three filters (date, timezone, status) mapping to workDate, timezone, and status. It stops short of giving the expected format for workDate or timezone strings, so the agent must guess syntax despite knowing each filter's meaning.

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

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

States a specific verb (List) and resource (current daily draft versions), and the plural 'versions' implies a collection rather than a single record, which distinguishes it from the sibling get_daily_draft. No sibling is named explicitly, so the differentiation is inferred 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?

The phrase 'optionally filtered by' signals all filters are optional and that this is a browsing tool, which implies usage. However, it never says when to use this versus get_daily_draft for a single draft, nor any prerequisite such as needing a configured daily-draft source.

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?

readOnlyHint=true already tells the agent this is a safe, side-effect-free operation, so the description carries a lighter burden. It adds nothing beyond that — no mention of latency, failure semantics, or what a failed check implies — but nothing contradicts 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?

A single three-word phrase with zero waste, front-loading the verb and target. Nothing could be trimmed without losing 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?

With an output schema present, return values needn't be explained, and a zero-param health check is a simple tool. Still, the description leaves open what a 'check' verifies and how it differs from the sibling connection validators, which an agent would need in order to choose correctly.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter-level context is needed or missing.

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?

"Check MCP connectivity" names a specific verb (check) and resource (MCP connectivity), and the word "MCP" implicitly scopes it away from the Notion/Calendar connection validators in the sibling list. It is clear but does not explicitly state that it exercises the MCP server itself rather than an upstream integration.

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 call this versus validate_notion_connection or validate_calendar_connection, nor any note about when a health check is appropriate (start of session, after errors, etc.). The only signal is the word "connectivity," which the agent must infer usage from.

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 openWorldHint=true, so the no-write behavior is known. The description reinforces no Calendar write and adds scope details ('one all-day Apple Calendar event', 'exact approved draft version'), but does not add auth, rate-limit, or other operational context beyond annotations.

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

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

Two short sentences, front-loaded with the core purpose and followed by the key safety constraint. There is no wasted text.

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

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

For a simple two-parameter preview tool with an output schema and read-only annotations, the description covers the essential purpose and approved-draft requirement. Parameter meaning remains thin, but return values and safety are handled by structured fields.

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 0%, so the description must compensate but only vaguely ties the parameters to 'exact approved draft version'. It does not explain that draftId is a UUID or that version must be a positive integer.

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 ('Preview'), resource ('one all-day Apple Calendar event'), and scope ('exact approved draft version'). It clearly distinguishes this from write-oriented siblings such as publish_to_calendar.

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

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

Provides clear context for use: previewing a specific approved draft version without performing a Calendar write. It does not explicitly name alternatives like publish_to_calendar or preview_notion_publication, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true; 'This performs no Notion writes' restates the read-only guarantee rather than adding new context. Nothing is said about idempotency, size/rate limits on the selection, or what the preview returns, though the existing output schema carries the 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 short sentences with the operation and its scope front-loaded and the safety caveat last; every clause carries information and there is no padding.

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

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

An output schema exists, so return values need not be described, and the read-only nature is covered by annotations. However, with three required parameters at 0% schema coverage, the description is too thin to let an agent correctly construct selectedNextActionIndexes or understand the approved-draft prerequisite.

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 0%, so the description must carry all parameter meaning, and it only loosely maps 'one approved draft version' to draftId/version and 'explicitly selected Tasks' to selectedNextActionIndexes. It never clarifies what the indexes index into, whether they are 0-based, or the 100-item cap, and the wording 'Tasks' versus the parameter name 'NextActionIndexes' leaves an ambiguity.

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 (preview) and scoped resource (Work Logs plus explicitly selected Tasks for one approved draft version), and the closing clause implicitly contrasts it with a publishing operation. It does not name the sibling publish_to_notion outright, so the differentiation is inferential 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?

The phrase 'one approved draft version' implies a prerequisite (the draft must be approved) and the word 'Preview' implies a pre-publication check, but no alternative tool is named and there is no explicit guidance on when to choose this over publish_to_notion or get_notion_publication_status.

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 this as non-read-only, open-world, idempotent, and destructive. The description adds useful context about explicit user confirmation and publishing an exact approved version, but it does not explain what destructive effect may occur, whether re-publishing overwrites or duplicates calendar entries, or how confirmation is verified.

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 a single front-loaded sentence with no wasted text. Every phrase contributes to scoping or prerequisites.

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

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

The description covers the core workflow gate (previewed, approved, explicitly confirmed) and the tool has explicit annotations plus an output schema. However, for a destructive external publication tool with 0% parameter description coverage, it leaves important operational details undocumented, especially how to obtain the previewFingerprint and what confirmation should contain.

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 0%, so the description must compensate for four undocumented parameters. It loosely implies version, preview fingerprint, and confirmation through phrases like 'exact version', 'previously previewed', and 'explicit user confirmation', but it gives no concrete semantics for draftId, version, previewFingerprint, or confirmation.

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 (publish), resource (Apple Calendar), and scope (exact, previously previewed, approved draft version). It implicitly distinguishes this from publish_to_notion and from the preview/status siblings, so an agent can identify the operation without opening the schema.

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

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

It clearly states the prerequisite workflow: the draft must have been previously previewed and approved, and publishing requires explicit user confirmation. It does not explicitly name preview_calendar_publication or state when-not-to-use alternatives, but the conditions for use are 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 declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful preconditions (prior preview, approval, explicit confirmation) beyond annotations, but says nothing about what happens on a fingerprint mismatch, what gets overwritten, or the external side effect on Notion despite openWorld=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?

A single dense sentence with zero waste; the key constraint (exact, previously previewed, approved, confirmed) is front-loaded and scannable.

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 publish with 5 undocumented parameters and no schema descriptions, the description is far too thin — an agent cannot construct the arguments or anticipate mismatch/failure behavior. The output schema being present helps with return values, but not with the invocation-critical gaps.

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

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

Schema description coverage is 0% across 5 parameters, so the description carries the full burden and largely fails: 'previously previewed' hints at previewFingerprint, but draftId, version, selectedNextActionIndexes, and confirmation are entirely undefined. Nothing explains that version pins an exact draft revision or what the fingerprint is validated against.

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 (publish) and resource (a previously previewed, approved draft version) plus the notable scope constraint that it must be exact and previously previewed. It implicitly distinguishes itself from preview_notion_publication by requiring a prior preview, but never names the siblings it contrasts with (preview_*, publish_to_calendar).

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?

Clear preconditions — the draft must already be previewed and approved, and explicit user confirmation is required — which effectively routes the agent away from calling this before preview/approve. It stops short of naming the specific prerequisite sibling tools (preview_notion_publication, approve_daily_draft) or stating what to do if those steps were skipped.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful scoping by clarifying no approval or publication occurs, but says nothing about whether an existing draft for the same workDate is overwritten, how sourceFingerprint affects conflict handling, or what permissions are required.

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

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

Two tight sentences with the scope-boundary claim front-loaded and no filler. Efficient, though the brevity comes at the cost of the parameter explanation noted elsewhere rather than being an independent flaw.

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 7-required-parameter write tool with 0% schema coverage, the description leaves too much for the agent to infer: draft identity key, overwrite behavior, fingerprint purpose. The presence of an output schema excuses it from explaining return values, but not from explaining inputs.

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 0% across 7 required parameters, so the description must carry the meaning and it carries none. Semantically loaded fields like timezone, workDate format, sourceFingerprint (presumably a conflict/staleness token) and the sourceEventIds provenance link are left entirely unexplained.

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 (persist) and resource (daily draft), plus the qualifying detail that the draft is AI-proposed. Together with the explicit 'does not approve or publish' clause, it separates itself from approve_daily_draft and the publish tools, though the relationship to save vs. update_daily_draft is left unaddressed.

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 excludes two adjacent operations (approval, publication), which is real guidance. But it never says when to use this versus update_daily_draft or get_daily_draft, and the save/update boundary is the most likely selection error among siblings.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the write produces an immutable revision (history is preserved) and is gated on the current version. It does not say what happens on a version mismatch (error vs. retry), nor whether the prior revision is superseded.

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

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

Two tight sentences with the core action front-loaded and zero filler. The compression slightly costs clarity — 'checking the current version' is a vague way to describe optimistic-concurrency enforcement — but nothing is wasted.

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

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

For an 8-required-parameter mutation with 0% schema coverage and a conflict-sensitive version parameter, the description is far too thin: no conflict/failure behavior, no explanation of the provenance fields, no routing against the five sibling draft tools. The output schema being present removes the need to describe returns, but the input and behavioral gaps dominate.

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 0% across 8 required parameters, and the description compensates for only one: the status enum, where it explains REJECTED vs. PENDING semantics. draftId, expectedVersion, sourceEventIds, sourceFingerprint, summary, workItems, and nextActions carry no meaning in the description; provenance fields like sourceFingerprint are left entirely unexplained by both schema and text.

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 concrete action (create a new immutable revision) and explains the version-check precondition, which clarifies that this is an append-only revision of a draft rather than an in-place edit. It never names a sibling, so the agent cannot tell from the description alone how this differs from save_daily_draft or approve_daily_draft.

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?

'After checking the current version' hints at a read-then-write flow, but there is no explicit when-to-use guidance and no exclusion relative to save_daily_draft, approve_daily_draft, or list/get_daily_draft. The only guidance given ('Use REJECTED to reject and PENDING to edit or reopen') is about the status value, not about 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?

Annotations declare readOnlyHint=false, which looks surprising for an 'Inspect' tool until the description explains that setting requestPermission raises the macOS full-access prompt — a genuine system-level side effect an agent could not infer. It stops short of saying what happens on denial or non-interactive contexts.

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, the action front-loaded and the conditional parameter guidance second. Nothing is redundant with the schema or annotations.

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 one parameter is covered. The remaining gap is that 'configured target' is never defined — an agent does not know what target is being validated or what a failing result means.

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 0%, so the description must carry the single parameter, and it does: requestPermission is tied to the macOS full-access prompt and implicitly gated ('only when the user wants'). The default of false comes from the schema rather than the text, and the exact prompt behavior is not spelled out 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 (Inspect) and resource (Apple Calendar permission and configured target), which clearly separates it from validate_notion_connection. It does not explicitly name siblings or say when to prefer it over publish_to_calendar, but the scope 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?

The second sentence gives a conditional rule for one parameter ('only when the user wants the macOS full-access prompt'), which is strong guidance. However, there is no statement of when to call this tool at all versus the publication siblings, and no note about running it before publish_to_calendar.

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 openWorldHint=true, so the safety profile is covered structurally; 'without modifying Notion' largely restates readOnlyHint. The description adds no information about authentication failure modes, error reporting, or rate limits — relevant for a tool whose job is validating an external connection.

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

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

A single, front-loaded sentence with no filler. It is efficient, though the four-item resource list is slightly dense and the read-only qualifier could have been folded into a clearer purpose statement.

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 zero parameters, full annotation coverage, and an output schema that presumably carries the returned schema/auth details, the description is close to sufficient. It is only missing the failure/validation semantics that the tool name promises.

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 for the description to disambiguate. Baseline 4 applies; the description does not need to compensate for any schema gap.

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 (Read) and enumerates the exact resources: authentication, Database, Data Source, and property schemas. An agent can distinguish it from publish_to_notion or get_notion_publication_status, though the description never explicitly says it 'validates the connection' as the name implies — the link between reading schemas and validation is left implicit.

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 explicit 'use this when...' clause and no sibling is named as an alternative. Usage is only implied by the trailing 'without modifying Notion', which suggests a pre-flight/read-only check, and by the parallel validate_calendar_connection sibling. An agent must infer the context.

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