Notipo

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

Discloses important side effects beyond annotations: it creates a Notion page, triggers sync to WordPress, and supports draft vs immediate publication. This adds real behavioral context that readOnlyHint/destructiveHint cannot capture.

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?

Short, direct sentences with the core action and key behavioral facts front-loaded. No filler or redundancy.

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

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

The description covers the core workflow, side effects, and draft/publish behavior, while the output schema and fully documented input schema supply the remaining details. Nothing critical 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. The description reiterates the markdown body and publish semantics already present in the schema without adding new parameter-level detail.

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 action ('Create a new blog post') with concrete side effects (creates a Notion page and triggers sync to WordPress). The word 'new' and the draft/publish distinction separate it from update_post, publish_post, and direct_publish.

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

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

Gives clear context for using publish=true vs false, but does not explicitly state when to prefer sibling tools like direct_publish or publish_post. The creation-focused wording implies usage, but alternatives are not named or excluded.

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 indicate a destructive operation, but the description adds meaningful context beyond that: it specifically names the systems affected (Notipo, WordPress, Notion) and warns irreversibly with 'This cannot be undone.' This gives the agent a clear picture of side effects 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 only two sentences with zero redundancy. The primary action is front-loaded, and the critical warning about irreversibility is placed immediately after, making it efficient and easy to parse.

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

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

For a destructive one-parameter operation, the description covers the key context: what is deleted, where, and that it cannot be undone. An output schema exists and the annotations cover the destructive nature, so the description does not need to explain return values or safety posture. Minor details like failure atomicity or required permissions are not mentioned, but that is a small 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?

The input schema already fully describes the single parameter postId with 100% coverage. The description adds no additional semantic detail about the parameter, so it correctly receives the baseline score 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 states a specific verb and resource ('Delete a post') and precisely identifies the scope: deleting from Notipo, WordPress, and resetting the Notion page status. This clearly distinguishes the tool from the sibling tools, none of which perform deletion.

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 the tool is used when a post needs to be deleted, and it is the only deletion-oriented sibling. However, it does not explicitly discuss when to use this tool versus alternatives, nor does it mention exclusions or prerequisites such as requiring an existing post.

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 establish mutating non-destructive write semantics, and the description adds meaningful behavioral context beyond them: the processing pipeline (image uploads, Gutenberg conversion, featured image generation, SEO metadata), the markdown input constraint, and the live-vs-draft semantics of publish. No contradiction with annotations. Not a 5 because it doesn't disclose overwrite or failure behavior.

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

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

Four sentences, each earning its place: purpose, pipeline capabilities, input constraint plus flag semantics, and sibling routing. Front-loaded with the core purpose and zero filler for a tool of this complexity.

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

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

The output schema covers return values, annotations cover the safety profile, and the schema covers all 9 params at 100%, so the description's burden is limited. It adequately covers the pipeline behavior and routing. The remaining gap is the direct_publish vs publish_post boundary and consequences for existing slugs/drafts, which is minor given the strong structured coverage.

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 9 parameters and the baseline is 3. The description adds a light pipeline frame that connects params to behaviors (featured image generation to imageTitle, SEO metadata to seoKeyword/seoDescription), but it repeats rather than extends the schema's markdown and publish-flag 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 and resource ('Publish a blog post directly to WordPress'), adds the scoping differentiator 'without Notion', and explicitly names the sibling it replaces ('Use this instead of create_post'). An agent can distinguish it from create_post and publish_post without opening schemas.

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

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

Gives explicit routing guidance: 'Use this instead of create_post when you don't need Notion,' which names the alternative and the condition. However, it does not address the sibling publish_post (e.g., when a draft already exists), leaving one boundary ambiguous.

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 and destructiveHint annotations already establish safety, and the description adds useful behavioral detail by naming the possible statuses (PENDING, RUNNING, COMPLETED, FAILED) and mentioning progress steps and error reporting. This goes beyond the annotation-only view without contradicting it.

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 that front-loads the tool's core purpose and then lists the valuable return fields. There is no redundant or filler 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 simple single-parameter read-only status endpoint, the description is complete: it states what the tool checks, what it returns, and the schema plus annotations cover the remaining invocation requirements.

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

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

Schema description coverage is 100%, and the jobId parameter is already well described as being returned by create_post, update_post, or publish_post. The main description adds no additional parameter semantics, 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?

The description uses a specific verb ('Check') and resource ('status of a sync or publish job') and enumerates the exact return data (status, progress steps, error message). This clearly distinguishes get_job from sibling list_jobs, which would be for browsing jobs rather than checking a specific one.

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

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

The description implies usage after starting a job, and the jobId schema description reinforces that the ID comes from create_post, update_post, or publish_post. However, there is no explicit guidance about when to prefer get_job over list_jobs or how it relates to polling workflows.

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, covering the safety profile. The description adds that the response includes status, WordPress URL, and category, but it does not disclose additional behavioral traits such as error conditions or authorization requirements. 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, front-loaded sentence states the operation, the target, and the key returned fields with no filler or redundant 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?

This is a simple one-parameter read-only lookup with an output schema and safety annotations. The description is sufficient for an agent to select and invoke the tool correctly without missing information.

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

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

The schema provides 100% coverage: postId is described as 'The post ID'. The description's 'by ID' matches the parameter but adds no meaningful semantic detail beyond what the schema already states.

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 action ('Get'), the resource ('specific post'), and the retrieval key ('by ID'). It also names the meaningful return fields, which distinguishes it from listing tools like list_posts.

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 'specific post by ID' provides a clear usage context: use this when you need one known post's details rather than a list. It does not explicitly name alternatives or exclusion conditions, but the context is unambiguous.

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

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

Annotations already mark this as readOnly and non-destructive. The description adds useful behavioral context by specifying what configuration data is returned, including service connections and trigger statuses, which goes beyond the annotation's simple safety hint.

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, well-structured sentence that front-loads the verb and resource before listing the specific configuration items. It contains no filler or redundancy.

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

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

Given that the tool takes no parameters and has an output schema available, the description sufficiently covers the tool's purpose and the nature of its result. It does not omit any critical usage information.

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

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

The tool has zero parameters and the schema shows no required inputs, so there are no parameter semantics to clarify. The description focuses on the output, which is appropriate for a parameterless read operation; the baseline for 0 params is 4.

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

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

The description uses the specific verb 'Get' with the resource 'Notipo account configuration' and enumerates the returned content (connected services, plan, feature settings, trigger statuses). This clearly distinguishes it from sibling tools focused on posts, jobs, and publishing.

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 makes the tool's purpose obvious by listing its contents, so an agent can infer it should be used when the user asks about account configuration or connected services. It does not explicitly name alternatives or exclusions, but the sibling context makes the usage clear enough.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that categories are 'synced to Notipo' and includes 'all' categories, which gives useful scope context but does not disclose additional behavioral details like ordering or whether empty categories are included. That is acceptable for a simple read-only list.

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 no filler. The core resource and action are front-loaded, and the usage note earns its place by linking to a downstream workflow.

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-parameter read-only list tool with an output schema and annotations covering safety, the description is complete. It explains what is returned, where the data comes from, and how the result should be used.

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 has zero parameters, so the baseline is 4. The description adds contextual value by explaining that the returned names should be used when creating posts, which helps the agent understand how the output connects to another tool. There are no parameter semantics to clarify.

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 action ('List all WordPress categories synced to Notipo') and clearly identifies the resource. It distinguishes categories from sibling tools like list_tags, so an agent can select it without opening schemas.

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

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

The description provides clear context for when the output should be used ('Use these names when creating posts'), which connects directly to the create_post sibling. It does not explicitly state when not to use it versus list_tags, but the category-specific wording makes the intended context obvious.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful scope context ('recent sync and publish jobs'), but does not disclose additional behavioral details such as sorting or time-window semantics. This is adequate but not rich beyond 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?

Two short sentences, front-loaded with the core purpose and followed by a relevant usage hint. There is no redundant or filler 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 simple read-only list tool with fully documented parameters, safety annotations, and an output schema, the description provides sufficient context. The agent can select and invoke the tool correctly without missing critical information.

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

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

Schema description coverage is 100%, so limit and status are already fully documented in the schema. The description does not add parameter-specific meaning beyond what the schema provides, so the baseline score 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?

The description uses a specific verb and resource ('List recent sync and publish jobs') and clearly scopes the operation to job-listing, distinguishing it from singular get_job and from other list_* siblings. It is immediately obvious what this tool does.

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 'Useful for monitoring pipeline activity' gives a clear context for when to use the tool. It does not explicitly mention alternatives or exclusionary conditions, but the intended use case is evident from the description.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so no contradiction exists. The description adds value by specifying the scoped behavior (“all posts for your Notipo account”) and the exact return fields (title, status, WordPress URL, category, timestamps). It could disclose pagination or ordering, but for a simple read-only list with no parameters, the provided transparency is solid.

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

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

Two short sentences with zero waste. The first sentence front-loads the action and resource; the second lists the return fields. Every word earns its place, and the description is ideal for quick scanning by an 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?

For a zero-parameter read-only list tool, the description is complete: it states the scope, the resource, and the return fields. An output schema exists, so detailed return structures are already handled. The sibling list includes related tools, but no additional context (like authentication or pagination) is necessary for this simple operation.

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

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

The input schema has zero parameters, so the baseline is 4; there is nothing for the description to explain. Schema description coverage is 100% vacuously. The description does not claim or hint at any parameters, which is consistent and complete for this tool.

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 and resource combination: “List all posts for your Notipo account,” which clearly identifies the operation and its scope. It distinguishes itself from siblings like get_post (single post), list_categories, and mutation tools by the resource and list verb. The mention of returned fields further reinforces the exact purpose.

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

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

The description provides clear context: use it to retrieve all posts for the account. It does not explicitly mention alternatives or exclusions, but the resource-centric wording makes the intended use obvious. It stops short of a 5 because it never names when to prefer get_post, list_tags, or another sibling.

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. The description adds useful context by clarifying the data source ('WordPress tags synced to Notipo'), which gives agents a better sense of the returned data's scope and provenance.

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, no filler, with the main action front-loaded and a practical usage note included. Every word earns its place.

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

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

For a read-only, zero-parameter tool with an output schema, the description is complete. It states what is returned, provides usage guidance, and annotations cover the safety profile.

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 has zero parameters, so parameter semantics are trivially satisfied. The description does not need to explain inputs, and the schema confirms no arguments are required.

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'), a specific resource ('WordPress tags synced to Notipo'), and a clear scope that distinguishes it from sibling tools like list_categories and list_posts. An agent can immediately know what this tool returns.

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 says to use these names when creating posts, which gives a concrete usage context. It does not explicitly list when not to use it or name alternatives, but the context is clear enough for correct 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 already indicate this is not read-only and not destructive. The description adds the key behavioral detail that the post transitions from draft to live, which is useful. It does not mention prerequisites, failure conditions, or side effects, but for this simple operation the added context is adequate.

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 states the action and outcome with no filler. Every word earns its place.

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

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

With one fully documented parameter, annotations, and an output schema present, the description is sufficient for an agent to select and invoke this tool correctly. No critical contextual 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 description coverage is 100% and the sole parameter, postId, is already documented as 'The post ID to publish'. The description adds the draft-to-live context but does not meaningfully extend the 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?

The description clearly identifies the action ('Publish'), the resource ('a draft post to WordPress'), and the effect ('make it live'). It distinguishes the tool from create_post and update_post, though it does not explicitly differentiate it from the sibling direct_publish.

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 instead of alternatives. In particular, the presence of direct_publish as a sibling makes this a meaningful gap, since an agent cannot tell which publishing workflow to choose.

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 discloses meaningful behavioral details beyond annotations: it checks trigger statuses, queues sync jobs, requires a Pro plan, and enforces a 15-second cooldown. The readOnlyHint=false and destructiveHint=false annotations are not contradicted; the description enriches them with real operational context.

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

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

Three short, purposeful sentences cover the action, the internal process, and the constraints. Every sentence adds value and the description is front-loaded with the core purpose before details.

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 parameters and an output schema present, the description does not need to explain return values. It fully covers what the tool does, how it behaves, and the operational limits, making it complete for an agent to select and invoke 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?

This tool takes zero parameters, so there is nothing for the description to add beyond what the schema already shows. The baseline of 4 applies because no parameter documentation burden exists.

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

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

The description opens with 'Trigger an immediate sync from Notion,' which clearly states the verb, resource, and action. It further explains the internal behavior ('checks for posts with trigger statuses and queues sync jobs'), making it easily distinguishable from sibling tools like publish_post or update_post.

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 clear context for when to use the tool: when an immediate sync from Notion is desired. It also adds operational constraints ('Pro plan only', '15-second cooldown'), though it does not explicitly name alternatives or when-not scenarios. The uniqueness of the action makes exclusions less necessary.

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 annotations (readOnlyHint=false, destructiveHint=false), the description adds non-obvious behavior: updates happen in Notion and then re-sync to WordPress. The partial-update rule ('Only provided fields are updated') is also useful and not otherwise stated.

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 focused sentence with no filler. It front-loads the action and includes the most important behavioral constraint without becoming verbose.

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

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

Given the full schema, output schema, and annotations, the description covers the core behavior, the cross-system sync side effect, and the partial-update rule. It could have more explicitly addressed when to use the publish parameter versus publish_post/direct_publish, but the essentials are present.

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 value by clarifying partial-update semantics, which is not necessarily inferable from optional schema properties alone. It correctly avoids repeating individual parameter descriptions.

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

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

The description uses a specific verb ('Update') and clearly identifies the resource: an existing post's content or properties in Notion, followed by re-sync to WordPress. It distinguishes itself from siblings like create_post and delete_post by emphasizing 'existing post'.

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 clearly conveys that this tool is for modifying an existing post and that only provided fields are updated. It does not explicitly mention alternatives like publish_post or direct_publish, so the guidance is clear but not exhaustive.

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