Idiolect AI

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds minimal behavioral context—only noting 'exact' profile targeting. It does not disclose whether samples are appended or replaced, or the meaning of 'approved' samples, which are non-obvious behaviors an agent would need to know.

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?

Single sentence, front-loads the verb and target. Every word earns its place—no waste or redundancy.

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

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

With low schema coverage, the description should clarify profileId optionality and admissible forms (id or name), and the semantics of adding to an existing profile vs replacing. It doesn't mention that profileId can be omitted, nor whether samples are appended or if there are deduplication rules. Important context for correct invocation is missing.

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

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

Schema covers profileId with a description, but samples has none (coverage 50%). The description doesn't elaborate on sample format or constraints beyond 'approved'. It adds little over the schema, and fails to compensate for the missing samples 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 description clearly states the action (add samples) and the target (Writing Profile), and mentions the profileId identifier. It doesn't explicitly distinguish from replace/remove siblings, but the verb 'add' is unambiguous and the resource is specific.

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

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

The description implies additive behavior (as opposed to replace or remove) but doesn't explicitly say when to use this over replace_samples_in_writing_profile or remove_sample_from_writing_profile. No exclusions or alternative routing are provided.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the mutation is expected and non-destructive. The description adds useful context that this creates a first profile from approved writing and is a compatibility action, but it does not disclose behavior such as what happens if a profile already exists or whether user confirmation is required. The description does not contradict the annotations.

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

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

Two tightly written sentences achieve the definition in the first sentence and provide sibling differentiation in the second. There is no redundancy, fluff, or repetition of schema details. The central distinguishing context is front-loaded.

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

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

The description is complete enough for callers: no required parameters, full schema descriptions, an output schema exists, and the alternative route to create_writing_profile is identified. The only small gap is what happens if the user already has a Voice Profile, since 'first' implies that condition but the behavior is not spelled out.

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

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

Schema description coverage is 100%, so the schema documents all three parameters clearly. The description adds only an overall contextual note about 'approved writing,' which relates to the samples parameter but does not go into individual parameter meaning. Baseline of 3 is appropriate because the schema carries the parameter explanation effort.

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 ('creating a first Voice Profile') and a specific source ('approved writing'), and clearly distinguishes this tool from create_writing_profile, which is for explicit multi-profile creation. An agent can tell this tool apart from its siblings without needing to inspect the schema.

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

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

The description names the alternative tool and the condition that selects it: use create_writing_profile for explicit multi-profile creation. It also implies the situational context for this tool: one-time compatibility setup of the first profile. This is explicit routing guidance rather than leaving usage 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 indicate idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds one useful behavioral detail—'This never changes an existing profile'—which clarifies it is non-destructive and solely creates new entities. However, it does not elaborate on idempotent behavior (e.g., duplicate name handling) or any side effects, so it provides only modest additional transparency beyond the annotations.

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

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

The description is two short sentences with no wasted words and conveys the core action and a key constraint upfront. It is appropriately sized for the tool's simplicity, though it could arguably be longer to compensate for missing parameter details, so it doesn't earn a 5.

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

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

Given the tool has three parameters (including nested 'answers' objects) and an output schema exists, the description is overly sparse. It doesn't explain what 'approved writing' means, what inputs are expected (name, answers, samples), or any prerequisites or expected outcomes beyond 'creates a new profile'. The description is insufficient for an agent to correctly construct a call without inspecting the schema or other context.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning, but it does not. The phrase 'from approved writing' vaguely implies samples or answers come from approved writing, but it never explains the purpose or constraints of 'name', 'answers', or 'samples'. With no parameter info in the description and zero schema coverage, the description fails to add any semantic value for 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 a specific action ('Create a new Writing Profile') and resource ('Writing Profile'), with the qualifier 'from approved writing' indicating source context. It also distinguishes itself from modification tools by stating 'This never changes an existing profile,' but it does not explicitly name a sibling tool like create_my_voice, so it falls just short of a 5.

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

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

The description implies usage when creating a new profile from approved writing, and the phrase 'never changes an existing profile' hints at when not to use it (i.e., for updates). However, it does not explicitly mention alternatives or conditions, such as when to use create_my_voice or set_current_writing_profile, so guidance is only implicit.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description is consistent. It goes beyond annotations by disclosing that deleting a current profile may require a replacement, which is a behavioral constraint not present in the schema or annotations. This adds valuable context about the operation's side effects without contradicting the efficient annotations.

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

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

The description is exactly two sentences, each earning its place. The core action is front-loaded in the first sentence, and the second sentence adds a key conditional detail. There is zero redundancy or filler, making it optimal for agent scanning.

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 delete operation with an output schema present, the description covers the essential information: what is deleted, how to identify it, and the condition for the optional parameter. It doesn't address error cases or permissions, but annotations cover the destructive nature and the output schema handles return values. Given the tool's simplicity, the description is complete enough.

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

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

Schema description coverage is 100%, providing baseline 3. The description adds meaning beyond the schema by explaining when replacementProfileId is needed ('A current profile may require...'). This directly clarifies the relationship between profileId and replacementProfileId, exceeding the schema's generic 'id or exact name' 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 description uses a specific verb ('Delete'), identifies the exact resource ('Writing Profile'), and specifies the identifier ('profileId'). It clearly distinguishes from sibling tools like 'create_writing_profile' or 'list_writing_profiles' by naming the destructive action. The phrase 'exact Writing Profile' reinforces precision and uniqueness.

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 implicit usage guidance by stating 'A current profile may require a replacementProfileId,' which tells the agent when the optional parameter is needed. It doesn't explicitly name alternatives, but no alternative delete tool exists among siblings, so the guidance is adequate for the context. The condition for using replacementProfileId is a clear when-to-use hint.

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

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

Annotations only give coarse hints (readOnlyHint=false, destructiveHint=false), so the description carries the transparency burden. It adds unique behavioral context: the tool returns measurement details and conditionally withholds absolute Voice Match pending independent evidence and target register. It does not fully describe side effects (whether the draft is persisted), so I deduct one point.

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: the first states the core action and required input, and the second discloses the important measurement caveat. The content is front-loaded and every clause earns its place.

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

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

For a two-parameter tool with an output schema present, the description covers purpose, input source, and a key output condition. It could be more explicit about how the 'selected voice' is determined and how this relates to sibling tools, but these are minor gaps given the rich schema.

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

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

Schema coverage is 100% and both brief and format already have meaningful descriptions in the schema. The prose description reinforces that brief is the source content but does not add details beyond the schema's 'What to write: audience, goal, constraints, and source facts.' This matches the baseline of 3 for full schema coverage.

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

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

States a specific verb and object: 'Draft new prose in the selected voice from a supplied brief.' This clearly marks it as a generative tool for new content and distinguishes it from sibling rewrite_in_voice by emphasizing 'new prose' rather than rewriting existing text.

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

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

The description implies use when the agent has a brief and wants new prose in the chosen voice, but it never states when to prefer this over rewrite_in_voice, score_voice, or any other sibling. There are no explicit when-not or alternative-routing conditions.

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

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

The description discloses that the tool loads a voice profile for writing, but it does not clarify whether 'loads' has side effects or merely retrieves context. Annotations are all false, so they provide no safety signal. The description partially carries the burden but leaves the mutation/read-only ambiguity unresolved.

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 sentences, with the trigger condition front-loaded and no filler. Every part adds value.

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 tool with an output schema, the description covers the essential 'what' and 'when.' It could further clarify whether it changes the active writing profile or requires an existing voice, but nothing critical is missing for selection and invocation.

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

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

The tool has zero parameters and the input schema is trivially complete with 100% coverage. The baseline for zero-parameter tools is 4; no parameter semantics are needed in 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 description uses a specific verb-resource pair ('Loads the user's Idiolect AI voice') and immediately clarifies intent ('so you write as them'). It also gives concrete usage contexts (emails, posts, messages, commit messages, PR descriptions, docs), which distinguishes it from drafting/rewriting sibling tools.

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 explicitly states when to use the tool: 'when you are about to write anything on the user's behalf.' It provides clear examples but does not explicitly name sibling alternatives or exclusion cases, such as when to use draft_in_voice/rewrite_in_voice 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 and idempotentHint=true, covering safety and idempotency. The description adds the specific scope (authenticated user's profiles) and the unique behavior of identifying the current profile, which is useful beyond the annotations. It does not mention pagination or return format, but the output schema exists to cover that.

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 concise sentence that states the operation and the key behavioral nuance (identify current profile). No filler, no repetition of the tool name, and the important detail is front-loaded.

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

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

For a parameterless read-only list operation with an output schema, the description fully conveys what the tool does and the context (authenticated user) needed to interpret it. Nothing is missing for correct invocation.

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

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

The tool has no parameters, so the description does not need to explain any parameter behavior. Baseline is 4 for zero-parameter tools.

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 a specific verb ('List') and a specific resource ('the authenticated user's Writing Profiles'), adding the additional behavior of identifying the current profile. This distinguishes it from sibling tools like create_writing_profile or delete_writing_profile without ambiguity.

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

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

The description gives clear context: it operates on the authenticated user's profiles and also identifies the current profile, which implies when to use it (to view profiles and know the active one). It does not explicitly exclude alternatives or mention when not to use it, but for a read-only list tool the usage is self-evident from the context.

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

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

Beyond annotations, the description discloses a key side-effect: feedback is kept only with permissionToLearn. It also sets an important data-integrity rule for correctionText (complete final text, never an excerpt/diff). This adds meaningful behavioral context beyond the readOnly/destructive hints.

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, all information-dense and front-loaded with the core action. Every sentence adds a distinct requirement or constraint; there is no filler or repetition.

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

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

The description covers the prerequisite (succeeded output), conditional parameters, and retention behavior. Given that an output schema is indicated and the optionality of critique/correctionText is already in the input schema, nothing critical is missing for invoking the tool 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?

With only 20% schema description coverage, the description carries most parameter meaning: outputId is the output receipt, status values are enumerated in context, critique is required on rejection/correction, correctionText must be the full final text, and permissionToLearn controls retention. The schema additionally documents correctionText, so the description compensates well for the coverage 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 names a specific action ('Record'), a specific resource ('feedback for a succeeded Idiolect AI output'), and the exact statuses involved. It clearly differentiates this from the voice/writing-profile siblings, none of which record feedback.

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 clear context: use after a succeeded output and when the user has provided accepted/corrected/rejected feedback. Conditional instructions are explicit (pass critique on rejection/correction; send full correctionText for corrections), though it does not explicitly name alternatives or state when not to use it.

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

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

Even though destructiveHint=true is already present in annotations, the description adds crucial nuance: 'The sample stops being used; it is revoked, not erased.' This clarifies that the underlying sample data is not destroyed, only its association with the profile, which is valuable beyond the annotation. It also emphasizes 'exact' to signal precise matching behavior.

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

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

The description is two concise sentences with no wasted words. The core action is front-loaded in the first sentence, and the second sentence provides an important clarifying nuance about revocation versus erasure.

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

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

For a two-parameter tool with an output schema and annotations providing the destructive hint, the description covers the essential behavior, parameter roles, and the revocation semantics. Nothing critical needed for correct invocation appears to be 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 50%, and the main description compensates by clarifying that sampleId identifies an exact writing sample and profileId identifies the Writing Profile. It adds meaning to sampleId, which lacks a schema description, by specifying exactness, though it does not elaborate on profileId beyond what the schema already states.

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

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

The description clearly states the specific action ('Remove the exact writing sample identified by sampleId from the Writing Profile identified by profileId'), naming both the resource and the parameters. It is semantically distinct from siblings like add_samples_to_writing_profile, replace_samples_in_writing_profile, and delete_writing_profile, emphasizing 'exact' and 'from the Writing Profile'.

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

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

The description implies the tool is for revoking a specific sample from a profile, but it does not explicitly state when to prefer it over alternatives such as replace_samples_in_writing_profile or delete_writing_profile. The 'revoked, not erased' phrasing gives some contextual signal, but there is no direct when-to-use or when-not-to-use 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?

Beyond the destructiveHint annotation, it reveals that displaced samples are revoked but not deleted, and that the tool refuses when it cannot list existing writing. These are meaningful side-effect and failure disclosures not present in the schema or 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?

Three sentences, all informative, with the main action first and side-effect plus limitation following. No filler or redundancy.

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

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

For a destructive replacement operation with an output schema and annotations, the description covers the target, the action, the side effects, and an important refusal condition. Nothing essential appears 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?

The schema already explains profileId (id or exact name), and the description confirms it identifies the profile. The 'samples' parameter is described only as the 'writing sample set'; the description does not materially elaborate on item format beyond the schema's type/length constraints. With 50% schema coverage, this is adequate but not strong.

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, 'Replace', the resource, 'the writing sample set', and the target, 'the exact Writing Profile identified by profileId'. This clearly differentiates it from sibling tools like add_samples_to_writing_profile or remove_sample_from_writing_profile.

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 is clear the tool is for full-set replacement rather than incremental addition or removal, and the refusal condition signals a key prerequisite. However, it does not explicitly mention alternative sibling tools or state when not to use it.

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

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

The annotations only mark readOnlyHint=false, openWorldHint=false, destructiveHint=false, which convey little. The description compensates by disclosing the return components, the conditional withholding of Voice Match, and the fallback behavior when the candidate regresses. This is rich, decision-relevant behavioral context.

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

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

Two sentences, front-loaded with the core function, then concise high-value behavioral details. Every clause earns its place and there is no padding or redundancy.

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

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

The schema covers all parameters, an output schema exists, and the description adds the conditional behaviors that matter for correct use. Nothing critical is missing for an agent to decide whether and how to invoke this tool.

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

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

Schema description coverage is 100%, and every parameter has a meaningful description. The tool description adds no parameter-level semantics beyond the schema, so the baseline of 3 applies.

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

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

The description opens with a specific verb ('Rewrite') and resource ('supplied prose') plus a clear target ('selected voice'). This clearly distinguishes the tool from sibling tools like draft_in_voice (generation) and score_voice (evaluation), so an agent can tell them apart without inspecting schemas.

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

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

The phrase 'Rewrite supplied prose' implies when to use it—on existing prose, not drafting new content—but the description never explicitly names alternatives or states when not to use it. Usage is implied rather than directly guided.

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 adds behavioral detail beyond annotations by explaining conditional returns: 'Returns Voice Match only when the saved corpus and candidate are eligible; otherwise returns an unmeasured reason and safe evidence provenance.' However, it doesn't clarify the meaning of 'safe evidence provenance' or address whether the tool has side effects despite readOnlyHint=false, leaving some ambiguity.

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 concise: two sentences that front-load the purpose and then provide key usage and behavior context. Every word earns its place, with no repetition of schema details.

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

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

For a simple one-parameter tool with an output schema, the description covers purpose, usage condition, and conditional behavior. The term 'safe evidence provenance' is vague but not critical; overall it is sufficient for an agent to invoke correctly.

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

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

Schema coverage is 100% for the single 'text' parameter, with its description 'Text to score against the user's voice.' The tool description's 'candidate prose' adds no new semantic meaning beyond the schema, so the schema carries the full burden.

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

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

The description clearly states the tool's function: 'Check how close candidate prose is to the selected voice.' The verb 'check' and specific object 'voice match' distinguish it from sibling tools like rewrite_in_voice or draft_in_voice, which perform different actions.

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

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

The description gives an explicit usage condition: 'Invoke only when the user explicitly asks to measure or check Voice Match.' This provides clear guidance on when to use the tool and implicitly when not to, though it doesn't name alternatives.

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 (mutation), idempotentHint=true, and destructiveHint=false. The description adds the behavioral detail that the effect applies to 'future writing,' which clarifies the persistent impact. It doesn't contradict annotations and provides useful context beyond 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?

The description is a single, tightly worded sentence that front-loads the action and resource. Every word earns its place—no filler, no repetition. It is perfectly sized for a one-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 tool with one well-documented parameter, comprehensive annotations, and an output schema, the description fully covers what the agent needs to know to use it correctly. It explains the effect and the target. Nothing critical is missing.

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

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

Schema description coverage is 100% for the single parameter, clearly stating that profileId can be an id or exact name. The description simply references 'profileId' without adding any new semantic details, so it stays at the baseline of 3 for high coverage. No additional guidance on validation or error cases is provided.

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 action ('Make') and the specific resource ('the exact Writing Profile identified by profileId current'), and the purpose ('for future writing') is unambiguous. It distinguishes itself from siblings by focusing on setting the current/default profile, which no other sibling does.

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

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

The description implies the use case: when you want to change which writing profile is used for future writing. It doesn't explicitly list alternatives, but the context of sibling tools (create, delete, list) makes it obvious this is the tool for switching the active profile. Lacks explicit 'when not to use' guidance, but that's minor for such a focused tool.

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