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

Annotations already declare this is a non-destructive write with readOnlyHint=false. The description adds that saved answers become public and that the tool does not mutate upstream systems or handle payment, which is useful context beyond the annotations. It does not disclose whether repeated calls overwrite prior answers (despite idempotentHint=false), whether partial answers are allowed, or what happens once answers are saved.

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 core action front-loaded and no filler. The second sentence earns its place by stating scope limits. For a tool with this much nested structure, the description is arguably too terse, but it is concise and well-structured.

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

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

The tool has four parameters, a large nested answers object, no schema descriptions, and no output schema. The description gives only a high-level intent and a scope boundary, omitting what each answer field represents, whether answers can be partial, and the role of the optional connection parameters. For this complexity, the description is materially incomplete.

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 answers object contains numerous fields with no inline descriptions. The description does not explain any of the parameters, including the required intake_id, the meaning of the many answer fields, or the optional github_connection and smithery_connection. It only refers generically to 'answers', leaving the agent to infer the entire nested structure from 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 states a specific verb and resource: saving explicit public answers to questions in an owned intake. It is distinguishable from siblings like get_launch_intake and check_launch_coverage because it is the write path for intake answers. However, it does not clarify what 'public' means or how this relates to the broader launch flow.

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 check_launch_coverage, get_launch_intake, or create_launch. The phrase 'owned intake' implies a prerequisite but does not state that the intake must be fetched first or that answers must be complete before creating a launch. The boundary 'No upstream mutation or payment' is a scope limit, not usage 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=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-redundant context: the record is a guarded grant with bounded meaning and 'Does not pay', which prevents an agent from treating success as publication. It does not disclose idempotency behavior (e.g. whether re-authorizing the same revision is rejected or duplicated), which matters given idempotentHint=false.

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 no filler, and the precondition is front-loaded ahead of the semantic caveats. The semicolon-chained clause is packed but every element (authority, revision, digest, action, attestations, truthfulness) carries distinct 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 non-idempotent mutation with six required parameters and no output schema, the description covers preconditions and non-effects well but leaves gaps: no indication of what a successful grant returns, whether authorization can be superseded or re-issued for the same revision, or what failure looks like. An agent could call it correctly but not predict the result or recovery path.

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 six required parameters, so the description carries the burden. It maps conceptually to revision, approved_digest, action and attestations, but adds no format, constraint or meaning beyond those nouns — notably it never explains that authorize_publisher must be true, nor what the attestation objects must contain. Partial compensation only.

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 effect — 'Records a guarded grant' — scoped to an exact task revision, digest and submit/publish action, which is more precise than the title alone. It also carves out what it is not (proof of submission, approval or publication), helping separate it from get_publisher_task and create_publisher_task. It never names a sibling explicitly, so differentiation is inferential 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?

'Only use within existing explicit owner authority covering this exact task revision, digest, submit/publish action and truthful attestations; obtain missing authority first' gives a clear precondition and a required prior step. What is missing is routing guidance: no alternative is named for the case where authority does not yet exist, leaving the agent to guess which sibling establishes 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 say readOnlyHint=false and destructiveHint=false but convey nothing about side effects; the description usefully adds that provider calls are read-only, there is no charge or upstream write, and it saves the exact final report while removing blocked destinations. Gaps remain around permissions, reversibility of the removals, and where the report lands.

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 with the main action front-loaded, which is good. But the cryptic trailing clause 'Six direct submissions minimum' reads as an unexplained rule and the phrase 'preserve prerequisites' is opaque, so not every sentence cleanly 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 one-parameter, no-output-schema tool the description covers side effects and constraints reasonably, but it omits the only parameter's meaning and leaves the saved report's location and format unspecified. An agent could call it but would not fully predict the outcome.

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 single required parameter intake_id has 0% schema description coverage and is never mentioned in the description, so the agent gets no indication of what the intake ID is or where to obtain it. With only one parameter the description had an easy opportunity to explain it and did not.

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 gives a specific verb and resource (check destinations for a launch, remove blocked ones, preserve prerequisites, save the report), which tells an agent what the tool does. However, terms like 'implemented destinations' and 'preserve prerequisites' are domain jargon, and nothing distinguishes it from siblings such as run_preflight or get_preflight.

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 call this versus run_preflight or get_preflight, no mention that it needs an existing launch intake, and no explanation of what 'Six direct submissions minimum' means or when that constraint applies. The agent is left to infer the workflow position entirely.

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 provides valuable operational context beyond the structured data, specifically that the diagnostic is 'Anonymous' and 'free.' This provides the agent with critical usage constraints (e.g., no authentication needed) that are not covered by 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 definition is highly concise and effective. It front-loads the key value proposition ('Anonymous free diagnostic') and the key limitation, ensuring maximum information density in minimal 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?

Given the complexity of distinguishing between multiple preflight siblings, the description is highly complete by defining the scope (public GitHub) and the product tier (free vs. paid). It leaves no ambiguity regarding the tool's operational boundaries.

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

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

While the description confirms the required input type is a URL and suggests an optional manifest, it does not add significant meaning or semantic detail beyond what is loosely implied by the input schema structure. Since schema coverage is moderate (50%), 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 clearly defines the tool's purpose as an 'Anonymous free diagnostic' for a specific resource type: a public GitHub repository. It achieves good clarity by specifying both the nature of the check (diagnostic) and the target (public GitHub).

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?

This tool excels at usage guidance by explicitly stating what it is NOT ('This is not the per-destination purchase preflight'). This tells the AI precisely when to use this free version versus more expensive or comprehensive sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely new behavioral context: that the retrieval path is a direct HTTPS upload and that secrets must never transit chat or tool arguments — a security constraint an agent could not infer from annotations alone. It stops short of describing what the returned instructions contain.

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

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

Two short sentences, the purpose is front-loaded, and the second sentence is the operationally critical safety warning. Nothing is wasted and nothing could be removed 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?

For a zero-parameter, annotation-covered, no-output-schema tool, this is nearly complete: the agent knows it is a read, that it yields upload instructions, and that secrets must not be passed in arguments. The one gap is not telling the agent what the instructions look like or what the follow-up step is after reading them.

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 and the baseline applies. The description correctly implies no input is needed to fetch the instructions.

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

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

States a specific resource and behavior: read-only instructions for direct HTTPS credential upload. An agent can tell this returns guidance rather than performing an action. It does not explicitly differentiate itself from the sibling 'payment_instructions' or from connection-management tools like list_connections / replace_launch_connection, but the 'credential upload' framing is distinctive enough.

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: the agent should read this when it needs to get owner credentials uploaded. The second sentence gives a hard constraint ('never put third-party secrets in chat or MCP tool arguments'), which is a useful usage rule. However, it never says when to call this versus list_connections or replace_launch_connection, or what to do with the result.

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=false, and openWorldHint=false; the description adds genuinely non-derivable behavior: the API key is returned only once and must be stored, and email cannot be used for access or recovery. That directly shapes post-call handling. It does not explain why the operation is flagged destructive or whether calling it repeatedly creates junk accounts, which is consistent with, but not explanatory of, idempotentHint=false.

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, both load-bearing: the first covers the action and the one-time key return, the second covers storage and the email caveat. Nothing is padded and the most consequential fact leads.

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 mutating two-parameter tool with no output schema, the description does well on the return value (API key, once). It leaves gaps on what 'name' means, whether a duplicate signup creates an extra account, and what the destructiveHint implies, so an agent could still call it incorrectly or not know how to handle the result.

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 parameter meaning. It addresses 'email' only indirectly (not an access or recovery credential), leaving its actual role unspecified, and says nothing about 'name' despite it being the sole required field.

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 and outcome: an anonymous signup that returns a new account API key exactly once. That clearly separates it from read-oriented siblings like get_account or list_connections. It never names a sibling or explicitly says 'create', but the effect 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?

There is no explicit when-to-use guidance, no prerequisites, and no named alternative (e.g., use get_account if you already have credentials). The word 'Anonymous' implies the no-credentials case, but that inference is left to the agent.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered; the description adds genuinely new behavior: payment is human-mediated, only verified paid settlement queues jobs, and the $99 fee is immutable. That is context an agent could not get from structured fields. Minor tension: 'stable purchase key' hints at retry idempotency while idempotentHint=false, though the key-reuse wording originates in the schema rather than the description.

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 no filler, but they are front-loaded with preconditions rather than purpose, and jargon like 'saved immutable service fee' and 'stable purchase key' costs the reader more than it conveys.

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

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

There is no output schema, and the description says nothing about what is returned from a checkout (a URL, an order, a task reference) or what the agent should do next. For a payment-adjacent mutation in a 30+ tool surface, that leaves a real gap, though annotations and the schema cover safety and inputs adequately.

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 50%: idempotency_key is documented in-schema, launch_id is not. The description only restates that a launch ID is required and labels the key as 'stable purchase key' without explaining format, scope, or what a launch ID identifies — partial compensation, so 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 never plainly states what the tool produces — it opens with required inputs and then describes the tool obliquely as a 'human payment fallback for the saved immutable service fee.' The verb+resource must be inferred from the name/title rather than read in the description, and no sibling (e.g. payment_instructions, get_order) is named to differentiate it.

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?

'Human payment fallback' and 'does not autonomously pay' imply the situation loosely, but there is no explicit when-to-use rule, no exclusion against alternatives like payment_instructions, and no stated follow-up step after a checkout is created. The agent must guess its place in the launch flow.

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, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered structurally. The description adds real behavioral context beyond that: it requires an API key and explicit owner approval of displayed preflight plans, and it explains the two-step sequence where verified payment later triggers the authorized submissions. It does not describe what is returned or how failures and retries interact with the idempotency key.

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 no filler. The no-payment clarification is front-loaded alongside the authorization precondition, which is the highest-risk misunderstanding for an agent. Only minor redundancy between the title and the first clause.

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, four-required-parameter mutation with no output schema, the definition covers preconditions and the payment sequence but leaves the return value entirely unspecified. An agent does not learn whether a draft launch ID or status is returned, nor how this call relates to create_checkout or payment_instructions in the wider flow. Adequate but incomplete for the operation's complexity.

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 50%: idempotency_key and authorized_amount carry their own descriptions, while preflight_id and authorize_submissions do not. The description compensates partially by saying the draft is bound to a 'ready owned preflight' and that authorization must be explicit over 'displayed preflight plans,' which maps to those two undocumented parameters. Baseline 3 is appropriate given the schema does half the work.

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: it 'creates an unpaid draft bound to a ready owned preflight,' and explicitly negates payment ('this call does not pay'). This distinguishes it from create_checkout and run_preflight by scope. The opening clause about API key and owner authorization is a precondition rather than purpose, so the actual purpose arrives second, but it is still 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?

Usage is implied rather than stated: the tool applies to a 'ready owned preflight,' and the agent is told verified payment later queues submissions. There is no explicit when-not-to-use or named alternative (e.g., create_checkout for paying, run_preflight for producing the preflight). The prerequisites are useful but the sibling routing is left to inference.

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

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

Annotations already declare the tool as a non-read-only, open-world, destructive, non-idempotent write. The description adds critical context beyond those: explicit owner approval of a digest is required, the tool never merges or publishes, and on uncertain writes it only reconciles matching PRs rather than retrying blindly. This directly complements the non-idempotent hint and clarifies scope.

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 efficient sentences with no wasted words. The front-loading is slightly off because it opens with a prerequisite rather than the core action, but the action follows immediately and the overall structure is clear and compact.

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

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

Given the tool is a destructive, open-world, non-idempotent write with annotations covering the safety profile, the description adds the key approval requirement, the no-merge/no-publish scope, and the reconciliation behavior. The main gap is the lack of explanation for preparation_id and no output schema, but overall it provides enough context for an agent to decide and invoke.

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 parameter meaning. It explains approved_digest (must be the exact displayed patch digest) and authorize_pull_request (explicit owner approval), but leaves preparation_id unexplained and provides no format hints. This partial coverage is adequate but not complete.

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 (creates) and resources (branch and PR) in the source repository, making the action clear. It does not explicitly name sibling tools or explain how this differs from prepare_repository or create_launch, but the core purpose 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?

It implies usage by specifying prerequisites (owner approval of the exact patch digest) and constraints (never merges or publishes; reconcile only on uncertain writes). However, it does not explicitly state when to use this tool versus alternatives like prepare_repository or get_repository_preparation.

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 non-destructive, idempotent, closed-world write semantics, so the bar is lower; the description still adds real value by clarifying the operation only stages a packet and does not submit, prove delivery, or purchase coverage, plus a 'no secrets or credential uploads' constraint. It stops short of saying what is returned or whether the saved task is editable afterward.

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 compact sentences with the core action front-loaded and every clause carrying information — scope, staging-only behavior, and the credential prohibition. 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?

For a mutation tool with a nested 12-property object, no output schema, and 5 parameters, the description leaves the answers payload completely unexplained and never says what the caller gets back (task id? status?). The safety framing is good, but an agent cannot construct a valid call from this plus the schema alone.

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 only 20% — just idempotency_key — and the nested 'answers' object has twelve undocumented sub-fields (usecases, privacy_url, material_ids, etc.). The description's mention of 'field packet' and 'eligible package' vaguely gestures at answers and material_ids but explains none of the field meanings or which are required per channel.

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 and object ('Saves a field packet and eligible package') and scopes it to 'Claude/OpenAI owner review' preparation. 'Never submits, proves delivery or adds paid coverage' implicitly separates it from authorize_publisher_task, though that sibling is not named.

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 'Free preparation for Claude/OpenAI owner review' implies the phase in which to call it, and 'never submits' implies a later authorize step exists. But no alternative tool is named and no explicit when-not guidance is given beyond the negation of submission.

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 (which already mark this as destructive and non-idempotent), the description adds that an API key is required and that Smithery currently needs a public unauthenticated Streamable HTTP endpoint plus an owned namespace/server name. This is meaningful operational context, though it does not describe what gets destroyed or what the save response looks like.

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

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

The description is two tight sentences with the API-key requirement front-loaded. Every sentence carries some information, though the middle sentence is slightly awkward and the overall brevity is under-informative for a 24-parameter tool.

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

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

For a destructive, non-idempotent tool with 24 parameters, nested objects, and no output schema, the description is far too sparse. It does not explain what 'save' actually does, what side effects occur, how most fields are used, or what an agent should expect after 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 description coverage is only 8% across 24 parameters. The description adds constraints for a few fields (endpoint must be public/unauthenticated/Streamable HTTP, namespace/server name must be owned), but it leaves the vast majority of parameters—name, version, category, auth_type, directory_categories, install_instructions, etc.—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?

The description says 'Save accurate public profile fields,' which gives a verb and resource, but 'save' is ambiguous between create and update and 'public profile fields' is vague. It does not distinguish this tool from sibling creation tools like create_launch or import_repository.

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 'before checking all selected destination prerequisites' gives a sequencing hint, implying this should be called prior to prerequisite checks. However, it names no alternatives or exclusions and leaves the broader workflow context 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?

The provided annotations already cover safety (readOnlyHint: true, destructiveHint: false). The description adds valuable operational behavioral context by stating 'Requires API key,' which is a necessary operational requirement for successful execution.

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 definition is highly efficient, using three short sentences to cover operational requirements (API key), function (read account/availability), and limitations (credit status). The information is front-loaded and highly relevant.

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 low complexity (no parameters, fully annotated), the definition is robust and complete. It clearly communicates the boundaries of the tool's functionality, which is sufficient for a safe and 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?

Since the input schema has 0 parameters, parameter semantics add zero specific meaning. The baseline score of 3 is appropriate as the description simply confirms the read operation without needing to elaborate on non-existent parameters.

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 primary function: reading account status, billing, and execution availability. While it uses the general term 'account,' the context provided by the title and siblings clarifies the resource, avoiding 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?

The description provides a specific constraint ('Generic launch credits are not sold'), which guides the agent on the scope of useful information. However, it does not provide explicit 'when' scenarios to differentiate this tool from other similar retrieval functions among its many 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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds a real piece of behavioral context — the API key requirement — plus interpretation rules for submission/listing status, though it says nothing about error behavior when the ID is unknown or about the returned 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?

Three short sentences with the auth requirement front-loaded, so it is compact. However, the middle sentence is a dense, comma-spliced noun pile that is hard to parse, trading clarity for brevity.

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

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

For a one-parameter getter with no output schema, the description should convey what comes back and for which entity. It gestures at return content (evidence, waits, operator-attention states) but never ties the call to a launch ID or covers not-found behavior, leaving gaps an agent must guess at.

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 the sole parameter `launch_id` is never mentioned in the description. The text talks around the data ('owned jobs') but does not tell the agent it must supply a specific launch UUID to scope the read, so the description fails to compensate for the 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?

The description never states plainly that this retrieves a single launch by ID; instead it lists data categories ('Read owned jobs, real provider IDs, evidence, ingestion waits and operator-attention states'), which reads closer to a listing tool. With a sibling `list_launches` present and no differentiation, an agent could easily confuse the two.

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?

'Submitted is not approved; listed requires matching provider evidence' is domain guidance about launch status semantics, not about when to call this tool versus `get_launch_intake`, `get_preflight`, or `list_launches`. There are no conditions, prerequisites, or exclusions given for selecting this tool.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds that the response includes missing questions and next action, useful context, but says nothing about errors when intake_id is unknown or the shape/size of 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?

A single front-loaded sentence with no filler. It could be marginally improved by naming the alternative tool, 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?

Without an output schema, the description does well to enumerate return contents, but it omits how to obtain intake_id and offers no sense of response shape. For a simple single-param read it is mostly sufficient but has clear gaps.

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

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

Only one parameter, intake_id, with a UUID format in the schema but 0% description coverage. The name is largely self-explanatory, but the description does not say where the id comes from (e.g., create_launch) or how it keys the profile. Adequate but thin given the 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 what is returned: persisted profile, evidence, missing questions, and next action. This clearly identifies it as the intake-state read tool, though it does not explicitly contrast with get_launch or answer_launch_questions.

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

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

No guidance on when to call this versus siblings like get_launch, list_launches, or answer_launch_questions. The purpose implies a resume/introspection use case, but the agent must infer the conditions itself.

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 read-only, idempotent, non-destructive, closed-world behavior. The description adds useful context beyond annotations: API-key requirement, the post-payment/timeout timing, and a retry caution while the outcome is unknown.

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 auth requirement and then the core behavior and caution. There is no wasted text, and the retry warning is placed where an agent will see 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?

For a simple one-parameter read tool with rich annotations and no output schema, the description covers auth, return content, timing, and a retry caution. The main gap is that it does not explain the order_id parameter, but the schema supplies its UUID type and pattern.

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 the description never explains the sole parameter, order_id. "Your owned order" only loosely implies that order_id identifies the order, but it adds no format, ownership, or lookup semantics beyond the schema's UUID type.

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, "Returns," and names the resources: "your owned order and bound launch." The title "Reconcile a purchase" reinforces the purpose, though it does not explicitly distinguish this from siblings like get_launch or list_launches.

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 timing context ("after payment or timeout") and a clear caution ("Do not purchase again while outcome is unknown"), which implies when to call it. However, it does not name alternatives or explain when to use get_launch or list_launches instead.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context beyond that: an API key is required, and the read is framed as an owner review gate preceding a paid action. It stops short of describing error behavior or how stale a preflight may be.

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 with no filler, and the auth requirement is front-loaded. But the second sentence is a dense run-on that buries the core operation, so the structure prioritizes the review ritual over stating what the tool actually does.

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 partially compensates by naming the returned content (targets, blockers, proposed public payload). But for a single-parameter tool it omits the parameter's meaning and the relationship to `run_preflight`, which an agent needs to call it correctly.

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

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

Schema description coverage is 0% for the single required `preflight_id` parameter, so the description must carry the burden — and it never mentions the parameter, its UUID format, or where the ID originates (presumably from `run_preflight`). The self-evident name is the only guide, leaving a real gap in how to invoke the 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 sentence 'Review every target, blocker and proposed public payload' communicates the content being inspected but never states the actual operation — retrieving a stored preflight record by its ID. It also fails to differentiate from the sibling `run_preflight`, which the agent could easily confuse with this read tool. Purpose is implied 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?

There is an implicit sequencing cue: review 'before authorizing a paid launch', which tells the agent where this sits relative to authorization. However, it never says when to use `get_preflight` versus `run_preflight`, nor any prerequisite such as 'call run_preflight first to obtain the preflight_id'.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely extra context: the download link is authenticated and optional, and no raw binaries or credentials are ever returned through MCP — a useful security boundary. It does not cover error behavior or what 'owned' enforcement means.

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 payload description front-loaded and no filler. The null-return caveat is correctly placed last, though the vocabulary is compressed enough to be opaque to a first-time caller.

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 carries the return-value burden and does so by listing the response components and the negative guarantee about binaries/credentials. Missing only the prerequisite chain (how to get task_id) and failure modes, which keeps it short of a 5.

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

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

Only task_id exists and the schema fully constrains it (UUID format plus a strict pattern), so structural semantics are already handled. The description adds that the task must be 'owned' and refers to an 'exact revision', which hints at access control and revision semantics, but does not say how to obtain the id or how to pin a revision.

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 read operation ('Read the exact owned task revision') and enumerates what comes back: revision, digest, missing owner/provider actions, and a ZIP download link. It is clearly the single-task counterpart to list_publisher_tasks/create_publisher_task, though the jargon ('owned task revision', 'digest') is not defined.

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

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

There is no statement of when to use this versus list_publisher_tasks or authorize_publisher_task, and no guidance on where the task_id comes from. The agent must infer that this is the follow-up read after a task is created or listed.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's value-add is naming the payload contents (patch, warnings, digest) and the decision the read supports (owner authority vs. missing approval). It does not cover freshness, scoping, or what happens on an unknown/inaccessible preparation_id, but it meaningfully exceeds 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?

One front-loaded sentence with the verb first and zero filler; every clause carries workflow information. It is dense to the point of being cryptic, but nothing is redundant.

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 single-parameter read tool with full annotations and no output schema, the description names the returned artifacts and the decision context, which is adequate. It still leaves open how to source preparation_id and what 'digest' contains, which matters since there is no output schema to fall back on.

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 the description never mentions the single required preparation_id, where to obtain it, or what a 'preparation' represents. The schema's uuid format/pattern conveys type only; an agent gets no semantic guidance on the identifier that gates the entire call.

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 ('Read') plus a concrete resource set ('owned pinned patch, warnings and digest'), which tells an agent this is the review/inspection step rather than the creation step performed by prepare_repository or create_preparation_pull_request. The jargon ('owned pinned patch', 'digest') is opaque but the operation is still distinguishable from 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?

The phrase 'before authorizing a PR within existing owner authority or requesting missing approval' places the call in a workflow, implying it is a prerequisite to authorize_publisher_task/create_preparation_pull_request. However, no sibling is named and no when-not-to-use or precondition (e.g. what to do if the preparation is stale) 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 declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds real value beyond that by disclosing access scoping ('owned') and the shape of the returned content ('operator updates and resolution evidence'), but says nothing about what happens when the case is not owned or does not exist.

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 short sentence with the operation front-loaded and no filler. It is not padded, though the compression contributes to the noun ambiguity noted above.

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 required param, no output schema and full annotation coverage, the definition is minimally viable. It hints at the return payload but leaves ownership semantics and failure modes unstated, which matters for an access-scoped read.

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 the description adds no information about case_id. The parameter is a UUID with a format and pattern, so the type is self-evident from the schema, but nothing explains where the ID comes from (presumably list_service_cases) or that it identifies a service case rather than the 'review' the description names.

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, and adds scope ('owned') plus what the payload contains ('operator updates and resolution evidence'). The only weakness is a terminology drift: the tool is named get_service_case and siblings say 'service_case', but the description calls it a 'review', which forces the agent to reconcile two nouns.

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 when-to-use guidance and no mention of the obvious alternatives in the sibling list (list_service_cases, reply_to_service_case). The agent must infer that this fetches a single case by ID rather than enumerating or responding to one.

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 non-read-only, idempotent, open-world, non-destructive. The description adds real context beyond them: it saves an "owned" intake, only touches public repo data, performs no upstream writes or payment, and fills gaps by inference. It still does not say what the intake looks like or what happens on an unresolvable repo.

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 action and result, then scope limits. Nothing is repeated from the title or schema, and 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?

With no output schema, the description should say what the saved intake yields and how inference vs. missing facts are surfaced, which it only gestures at. The two undocumented connection parameters and the relationship to the downstream launch flow remain unexplained.

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 50%: repository_url and idempotency_key are well documented in the schema, but github_connection and smithery_connection have no description anywhere. The description does not compensate by explaining when those connection UUIDs matter, so half the parameters remain opaque.

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 concrete verb pair ("Inspect a public repository and save an owned launch intake"), so the agent knows both the read step and the write result. It does not differentiate itself from closely named siblings such as check_repository or prepare_repository, leaving the agent to infer the 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?

There is no statement of when to choose this over check_repository, prepare_repository, or get_launch_intake. The only boundary offered, "No upstream writes or payment", describes what the tool will not do rather than 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond that: the API-key auth requirement and, importantly, the data-handling guarantee that plaintext and ciphertext are never returned. It does not state ordering or whether the result is complete versus paginated, which keeps it from a 5.

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

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

Three tight sentences with no filler. The auth prerequisite leads ahead of the purpose statement, which is a slightly odd ordering for an agent scanning for what the tool does, but everything present 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?

No output schema exists, so the description must carry the return shape, and it does: IDs, providers, expiry and revocation metadata, plus an explicit negative guarantee. Complete enough to call correctly; only result ordering and completeness (full list vs. paged) are unstated.

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

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

Zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly does not waste words on a parameter list.

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 (connections) and even names the fields returned: owned connection IDs, providers, expiry and revocation metadata. It is distinguishable from revoke_connection and replace_launch_connection by verb alone, though it never explicitly contrasts with those 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?

There is no explicit when-to-use or when-not-to-use guidance, no mention of the connection_instructions or revoke_connection alternatives. Usage is only implied by the verb 'list' and the word 'owned', which is minimum-viable but leaves the agent to infer the 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?

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds two things annotations can't: that the catalog is anonymous (no auth needed) and that its results are non-authoritative for eligibility — a meaningful caveat that changes how an agent should treat the output.

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 eligibility caveat placed where it will be read. The opening sentence is a bare noun phrase rather than an action statement, which slightly weakens front-loading but costs little in 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?

For a parameterless, non-destructive read with an empty schema and no output schema, the agent needs to know what it gets (an anonymous catalog) and how far to trust it (not eligibility). Both are stated; the remaining gaps, such as result shape, are minor for a tool this simple.

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 clarify; baseline 4 applies. The description does not waste space restating an empty 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 calls itself an "Anonymous catalog with source references and requirements," which implies a listing operation but never states a verb+resource openly (e.g., "lists directories"). Combined with the title "Discover destinations" and the name list_directories, an agent can infer the purpose, but nothing in the text distinguishes it from siblings like list_servers or list_connections.

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 sets a clear boundary: discovery does not establish purchase eligibility, and a full authenticated preflight (matched to the run_preflight/get_preflight siblings) is the alternative. It tells the agent when this tool is insufficient, though it never positively states the browsing/exploration scenario where it should be used.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description does add one genuinely non-redundant fact — the API-key requirement — but says nothing about what "launch" data is returned or how large the result can get, and no output schema exists to fill that gap.

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 prerequisite front-loaded and no padding. The second sentence is vague, but the problem is the content's informativeness rather than bloat, so length is appropriate.

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 and rich annotations, the structural burden is low, but the description still fails to say what a launch record contains or what an agent should expect back, and there is no output schema to compensate. The auth note helps, but the core return semantics remain unexplained.

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; the baseline for a parameterless schema applies. No misleading parameter guidance is present.

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 never actually states that this lists launches; "Read durable execution and provider result states" is jargon that restates neither a clear verb+resource pair nor maps onto the tool name. The only hint of scope comes from the title, which is a separate field, so on its own the sentence is close to tautological.

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?

"Requires API key" is an auth prerequisite, not usage guidance. There is no statement of when to call this vs. siblings like get_launch or list_directories, and no conditions or exclusions are given, so the agent must infer selection from the tool name alone.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is fully covered. The description adds two genuinely behavioral facts — results are scoped to tasks you own, and 'pending provider work is not fulfillment' clarifies what the returned status means — but the second clause is opaque enough that an agent may not reliably interpret 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?

It is a single short sentence, which is appropriate, and the action is front-loaded. However, the trailing clause about provider work and fulfillment is compressed to the point of ambiguity rather than earning its place through clarity.

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

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

For a zero-parameter read tool with full annotation coverage and no parameters, the bar is low, but there is no output schema and the description never indicates what a returned task or journal status looks like. Combined with the unclear 'fulfillment' caveat, an agent can invoke it but cannot confidently interpret or route on the results.

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 burden falls on the description.

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 verb 'Read' and the resource 'owned preparation tasks and operator journal status' give a rough idea, but the phrasing is jargon-heavy and never says plainly that this is a list operation returning multiple tasks. It also fails to distinguish itself from the sibling get_publisher_task, which presumably reads a single task.

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 use this versus get_publisher_task, list_launches, or the preparation-related siblings. The word 'owned' hints at a personal scope but no exclusions or preconditions are 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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral facts — an API key is required and results are scoped to the caller's own saved profiles — but says nothing about ordering, volume, or what an empty result means.

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 clause of about ten words, with the auth prerequisite front-loaded and no filler. It is efficient, though so terse that it borders on under-specification rather than true conciseness.

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

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

With no output schema and no parameters, the description carries the burden of explaining what comes back, yet it only says 'your saved profiles' without describing fields, count limits, or ordering. The auth requirement is covered, but an agent still cannot predict the response 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The added note that no filtering is possible ('only your saved profiles') is a small bonus that clarifies the absent-parameter 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?

The title ('List your MCP profiles') and the phrase 'returns only your saved profiles' together convey that this enumerates saved profiles, but the description itself never states a verb+resource pairing like 'Lists your servers/profiles'. It also does nothing to distinguish this from sibling list tools such as list_directories or list_connections.

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?

'Returns only your saved profiles' implies a scope boundary (no other users' profiles, no filtering options), but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative sibling tool. The agent must infer that this is the discovery call before create_server or get_account.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety is covered. The description adds the useful constraint that only 'owned' reviews are returned, but it says nothing about ordering, default page size, or what a fulfillment summary contains — gaps that matter for a paginated listing 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?

It is a single compact sentence, which is good, but it front-loads a field enumeration instead of the core action and subject. The terseness comes at the cost of clarity rather than being an efficiency win.

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 paginated read tool with no output schema and 0% parameter documentation, an agent still lacks page size defaults, result ordering, and how the returned fields map to the response. Key invocation details are 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% and the description mentions neither 'limit' nor 'offset', their bounds (1–25, 0–1000000), nor default pagination behavior. With two undocumented, non-obvious parameters the description needed to compensate and does not.

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 verb 'Read' plus the field list ('delivery reviews, assigned operator, due date, fulfillment summary') hints at a listing of service cases, but the description never uses the tool's own vocabulary ('service cases' / 'list'), instead calling them 'delivery reviews'. An agent must infer that this returns a collection of service cases, and the description gives no clue how it differs from the sibling get_service_case.

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 use this tool versus get_service_case, reply_to_service_case, or the publisher-task listers. The word 'owned' implicitly narrows scope but no explicit inclusion/exclusion guidance or prerequisite 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 declare readOnly/idempotent/non-destructive, and the description reinforces this with 'No payment is made by this tool,' which resolves the misleading title. It adds genuinely useful context beyond the annotations — owner authorization requirement and a concrete price point ($99 new-launch offer) — though 'payment starts automatic submissions' is vague about what actually triggers side effects and where.

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

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

Two tight sentences with the read-only constraint front-loaded immediately after the resource, so the most decision-relevant fact arrives early. The trailing clause about automatic submissions is compressed to the point of ambiguity, which costs a point.

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

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

With one parameter, no output schema, and read-only annotations, the core needs are covered. However, since no output schema exists, the description should hint at what the returned 'protocol instructions' contain (e.g. an HTTP 402 challenge or payment target), and it does not.

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 schema documents only the UUID format, not the meaning of launch_id. The description adds one qualifier — the launch must be 'approved' — but conveys nothing about where the launch_id comes from or what state it must be in beyond that.

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 — it returns read-only protocol instructions for a given launch_id — and explicitly counters the title's implication that it pays. It does not differentiate itself from sibling tools such as create_checkout or get_order, so an agent must still infer which of the payment-adjacent tools is the right entry point.

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

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

It states a prerequisite (owner authorization for the saved launch amount) and a downstream consequence (payment starts automatic submissions), which implies the usage context. It never says when to choose this over create_checkout or what happens if the launch is not yet approved, leaving the routing decision 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?

It adds real value beyond the annotations by disclosing the return payload (diffs, preservation warnings, approval digest), the pinned-revision guarantee, and the fact that it is free and owner-authenticated. But 'No external writes' sits in tension with destructiveHint=true and readOnlyHint=false, and the description neither reconciles that nor explains state it may leave behind; the idempotency story is also muddled, since the description is silent while the schema's idempotency_key implies retry safety that idempotentHint=false denies.

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, no filler, and the most decision-relevant fact (no external writes) is placed last as a clean safety signal while the return contents are front-loaded. Phrasing like 'Free owner-authenticated inspection' is slightly compressed but still readable.

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 does well to enumerate the return contents, but for a non-read-only, open-world, destructive-hinted tool the agent still lacks the missing pieces: what the approval digest is used for, what happens to the preparation afterwards, and which sibling to call next. The two undocumented required UUID parameters remain an unaddressed 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 only 33% — server_id and github_connection carry no description, only UUID format/pattern — and the description contributes nothing about any of the three parameters. It doesn't explain what server_id scopes, what a github_connection represents, or how the approval digest relates to inputs, so the coverage gap is left unpatched.

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

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

The description is specific about what comes back: 'exact proposed file diffs, preservation warnings and approval digest' at a 'pinned GitHub revision', which tells an agent this is a dry-run patch preparation rather than an apply. However, it never names the action verb directly ('inspection' stands in for 'prepares a patch') and gives no signal to distinguish it from close siblings like get_repository_preparation or create_preparation_pull_request.

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 when-to-use, when-not-to-use, or alternative naming, despite a crowded sibling set (check_repository, get_repository_preparation, create_preparation_pull_request) where the boundaries matter. The only implicit guidance is 'no external writes', from which an agent must infer that this is the pre-approval step before creating a PR.

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=false, and openWorldHint=true, so the safety bar is partly covered. The description adds genuinely non-obvious behavior: an ownership verification step, the requirement that a fresh connection be uploaded by the owner first, and the explicit warning that uncertain writes cannot be retried and submission plans cannot change. That is meaningful context beyond the annotations, though it omits what state is destroyed on the old 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?

Two dense sentences with no filler, and the prerequisite is front-loaded before the constraints. The mid-sentence clause 'replace the same already-authorized provider' is awkwardly packed but still earns its place by encoding the provider-matching constraint.

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, non-idempotent mutation with no output schema, the description does cover the key hazard (no retry on uncertain writes) and the precondition. It falls short on parameter meaning and on what the caller gets back or how to detect the 'uncertain write' state it warns about.

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 the full burden for three parameters. It only implicitly constrains provider ('same already-authorized provider') and hints connection_id refers to the fresh upload; launch_id is never explained, and the enum values (github/registry/smithery) go unmentioned. The mapping from parameter to meaning is largely left to inference.

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 core action is identifiable: verify ownership and swap the connection for a launch on an existing provider. However, the phrasing 'replace the same already-authorized provider for a paid launch' is convoluted, and the key qualifier (expired connection, per the title) never appears in the body, so the agent must infer the tool applies only to expired connections. It is recognizable but not crisp against siblings like revoke_connection or list_connections.

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 prerequisite is stated ('After the owner securely uploads a fresh connection') and one boundary is given ('cannot retry uncertain writes or change submission plans'). But it never names the alternative path (e.g., revoke_connection + authorize, or create_launch) or states what to do when the connection is not expired, leaving the choose-vs-alternative decision implied.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false, so the write/irreversible profile is covered structurally. The description adds a genuine safety constraint about excluding credentials and private payloads, but never says the reply is customer-facing, whether it is final, or what happens with an invalid case_id.

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 cautionary clause is not padding. 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 a non-idempotent, destructive mutation with no output schema and 0% parameter documentation, the description leaves too much unsaid: no prerequisites, no side effects, no confirmation of what is returned or what a failure looks like.

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 parameter meaning, and it largely does not. Mentioning 'reply or acknowledgement' gestures at the kind enum, but case_id and message (including the 2000-character limit) are left entirely to the raw schema 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?

States a specific verb and resource: add a customer reply or acknowledgement. That is unambiguous and matches the name and title. It does not differentiate itself from siblings like get_service_case or list_service_cases, though the verb makes its role as the write counterpart fairly obvious.

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 get_service_case, or on prerequisites such as obtaining a case_id first. The only usage constraint given is the safety note about credentials and private payloads. An agent must infer the workflow entirely.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds real information on top: it names the concrete blast radius ('jobs using it from completing') and the owner-authorization requirement. It stops short of saying whether the revoke is reversible and how, or what happens to in-flight jobs, but it meaningfully supplements the structured flags.

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, each carrying distinct information (authorization requirement, then operational consequence). The impact statement is front-loaded after the access gate, though leading with the verb would have been stronger.

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, non-idempotent mutation with no output schema, the description covers authorization and consequences but omits the parameters entirely and says nothing about recovery or the expected response. It is adequate to understand the risk but not complete enough to call confidently without reading 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 0% and the description never mentions connection_id or confirm_revoke, so the two required parameters get no semantic help at all. The schema's format/const constraints are self-evident, but the description does nothing to compensate for the coverage gap on a destructive operation requiring an explicit confirmation flag.

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 sentence 'Revoking a connection prevents jobs using it from completing until reconnected' conveys the operation and its effect, but the tool's core action is only implied by a gerund clause rather than stated as a leading verb+resource. It also never distinguishes itself from the nearby replace_launch_connection or list_connections siblings, leaving the agent to infer whether revoke means delete or just disable the link.

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

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

The only guidance is 'Requires explicit owner authorization,' which is a prerequisite rather than a when-to-use rule. There is no statement of when to revoke versus when to use replace_launch_connection, and no exclusion or prerequisite beyond the authorization note.

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 supplies real behavioral context (API key needed, report is immutable and valid 30 minutes, no external submission or charge), but it directly conflicts with the annotations: it frames the work as 'Read-only provider checks' where nothing is submitted while annotations declare readOnlyHint=false and destructiveHint=true, and idempotentHint=false is never mentioned. An agent reading only the prose would conclude this call is harmless and repeatable, which the annotations do not support.

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 with the prerequisite front-loaded and no filler; the compressed phrases 'exact public payloads, blockers and remedies' are terse but still parseable. Slightly telegraphic, 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?

There is no output schema and no explanation of the parameters, so for a tool with a nested required object the description should explain what connection_refs entries are and how report contents map to blockers. It hints at report contents but leaves the caller unable to construct a correct invocation from prose alone.

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 three required parameters, including a nested connection_refs object with github/registry/smithery keys that the description never explains. Only vague echoes exist ('selected destinations' for directory_slugs, 'provider checks' for connections), leaving server_id and the ref structure completely undocumented.

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 and artifact: provider checks that produce an immutable 30-minute report of payloads, blockers and remedies, which matches the tool name run_preflight. It does not name or distinguish itself from the close siblings get_preflight (retrieve a report) or check_launch_coverage, so the run-vs-fetch distinction must be inferred from the title.

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: 'Requires API key' is a prerequisite and 'Unsupported/paused destinations cannot be bought' implies preflight precedes a purchase, but the description never says when to call this rather than get_preflight, check_launch_coverage or check_repository. No exclusions or alternative routing are stated.

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