VoiceMoat

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

Annotations already declare this as a safe, read-only, closed-world operation, so the safety burden is lifted. The description adds useful behavioral context by naming the returned metrics and the top post, but it does not disclose auth requirements, rate limits, or output formatting details.

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

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

Two tight sentences with no filler. The core operation and return contents are front-loaded, and the second sentence efficiently supplies usage triggers.

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

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

For a simple read-only analytics tool with fully documented parameters and a clear annotation profile, the description adequately covers what is returned and when to invoke it. It stops short of detailing output structure or aggregation behavior, but no output schema exists to carry that burden.

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

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

Schema description coverage is 100%, so both the window and platform parameters are already fully documented in the input schema. The description only refers generically to a time window and adds no syntax, default, or enum context beyond what the schema provides, making baseline 3 appropriate.

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

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

The description states a specific verb and resource: it retrieves engagement totals for named metrics plus the top post within a time window. It is clearly an analytics/performance tool, distinct from siblings like get_post or get_voice_insights, but it does not explicitly differentiate itself from 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?

It gives concrete user-intent examples such as asking how posts performed, how yesterday went, or how they're trending. This provides clear usage context, though it does not state when to use an alternative tool or any exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and closed-world scope, so safety is covered. The description adds a genuinely non-obvious behavioral trait beyond the annotations: this call is a prerequisite whose result other tools resolve against. It stops short of describing the returned payload, but adds real value over the structured fields.

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

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

Two short sentences, no filler, with the identity statement front-loaded ahead of the usage directive. 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 zero-param read tool with annotations covering safety, the description is nearly sufficient. The only gap is that no output schema exists and the description does not say what the account object contains, though 'everything else resolves against what it returns' implies an identity/ID is returned.

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 no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter-related gaps exist.

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 ('Identify the signed-in VoiceMoat account'), which is enough to distinguish it from siblings like get_voice_profile and list_profiles without opening a schema. It is clear but does not explicitly contrast itself against the closest sibling, so it falls just short of 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?

'Call this first: everything else resolves against what it returns' gives explicit, actionable sequencing guidance that most sibling tools lack. It does not name any alternative or a when-not condition, but for a zero-param identity tool the context is clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description usefully discloses the payload (full text plus engagement numbers), but says nothing about behavior for a missing/invalid id or auth requirements. Adequate but with a clear 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, zero filler, with the what (fetch full text + engagement) front-loaded ahead of the when. 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?

With no output schema, the description does the work of stating what comes back, and it does so concisely for a simple one-parameter read tool. Minor residual gaps around error/not-found behavior keep it from 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?

The single post_id parameter is 100% documented in the schema (UUID or slug), so the schema carries the burden. "by id" in the description is consistent but adds no syntax or format detail beyond it, matching the baseline for high schema coverage.

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

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

States a specific verb (Fetch), resource (post), scope (one specific post), and return content (full text + engagement numbers) identified by id. An agent can distinguish this from list_posts, search_inspiration, and get_analytics without opening any schema.

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

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

"Use when the user references a specific post and you want exact numbers" gives clear positive selection criteria — a single-post lookup rather than a list or search. It doesn't name an alternative tool or a when-not condition, but the trigger context is unambiguous.

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

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

Annotations declare destructiveHint=false but readOnlyHint=false, so the agent knows it is a non-destructive operation that is not a pure read. The description adds genuinely useful output-shape context — 'Each idea is a short seed, not a full draft' — which is not available anywhere else since there is no output schema. It does not disclose cost, latency, or why the tool is not flagged read-only.

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, zero filler, with purpose front-loaded before the usage trigger and the output caveat. Every sentence earns its place.

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

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

With no output schema, the description usefully characterizes the return shape as short seeds rather than drafts, and it covers the triggering context. Minor gaps remain around how platform or count affect the results, but nothing needed to call the tool correctly is missing.

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

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

Schema description coverage is 100%, so all three parameters (topic, count, platform) are already documented, including the count default and the platform omission behavior. The phrase 'N distinct' loosely implies the count parameter, but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource with scope: generate N distinct post ideas on a given topic. This is clearly distinguishable from siblings like improve_post and suggest_hooks, though it never names an alternative explicitly.

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

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

Gives an explicit trigger ('Use when the user asks for ideas, angles, or different takes on the same subject'), which is more than implied usage. It lacks any when-not guidance or routing to close siblings such as suggest_hooks.

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

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

Annotations already declare readOnlyHint/destructiveHint, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it discloses the empty-stub edge case when Voice Lab has not been run and prescribes a fallback action. It stops short of describing rate limits or the shape of a populated response.

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

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

Front-loads what the tool returns, then when to use it, then the edge-case fallback, all in three tight sentences. Minor verbosity in the enumerated voice dimensions, but nothing 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?

With no output schema, the description does the work of explaining return content (dominant patterns, hook styles, rhythm, vocabulary, drift) and the empty-stub case. Adequate for the agent to call and interpret it, though the unexplained platform parameter is a residual gap.

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

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

The single 'platform' parameter has 0% schema description coverage, so the schema does not explain it, and the description never mentions it either. The enum values (twitter/linkedin) are somewhat self-explanatory, but the description adds no meaning about how platform scopes the returned insights, leaving a real 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?

Uses a specific verb and names both resources precisely ('latest Voice Lab analysis' with enumerated contents plus 'Voice Guard drift read'). An agent can distinguish this from siblings like get_voice_profile or score_voice_match without opening any schema.

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

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

Gives clear trigger phrases ('what's my voice like', 'how am I drifting') and the intent (grounding creative replies in concrete numbers), which is strong context. It does not, however, name when to prefer a sibling such as get_voice_profile or score_voice_match, so the alternative space is left implicit.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds value beyond that by enumerating what the profile contains (persona, tone markers, traits, never-say phrases), which is genuinely useful since there is no output schema.

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

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

Two compact sentences, front-loaded with the returned content and followed by the usage cue. No filler, though the closing 'adjust tone' clause is slightly imprecise and dilutes the read-only framing.

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

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

For a zero-required-param read tool with annotations carrying the safety profile and no output schema, the description adequately conveys what comes back. It is incomplete on the one structured field that exists (platform) and on how this differs from get_voice_insights, so it is minimum-viable rather than complete.

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

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

There is one parameter, 'platform', with an enum but zero schema description coverage. The description never mentions platform at all, so an agent gets no guidance on whether the profile is global or per-platform, or what omitting it returns. With coverage this low, the description should 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?

It names the resource (the user's voice profile / voice DNA) and enumerates the contents: writing persona, tone markers, personality traits, never-say phrases. That is concrete and specific, though it never distinguishes itself from close siblings such as get_voice_insights or score_voice_match.

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

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

It gives a usage cue ('when the user asks about their own voice settings or wants to adjust tone'), which is implied context rather than explicit routing. It names no alternatives and no exclusions, and 'wants to adjust tone' is loose usage guidance for a read-only fetch when a separate mutation path presumably exists.

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

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

Goes well beyond the annotations: it discloses credit costs (quick 3, full 5), the processing pipeline, the return payload ('improved post plus what it changed and why'), and clarifies that nothing the user owns is modified. Although destructiveHint=false already implies safety, the credit cost and output shape are non-obvious context the description supplies.

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

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

Front-loaded with the core purpose and mode routing before the cost caveat. It is somewhat long and dense but nearly every sentence carries actionable detail; minor tightening is possible.

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 no output schema, it covers what an agent needs: mode selection, cost, non-destructiveness, the returned explanation, and the downstream follow-up tool. Nothing material is missing.

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

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

Schema coverage is 100% and both enums (mode, platform) are documented in the schema itself, so the schema carries the parameter burden. The description restates mode semantics without adding syntax or format detail beyond what the schema provides; baseline 3 is appropriate.

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

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

States a specific verb and resource ('Run the user's draft through audenAI's real improve engine') and explicitly distinguishes the two modes' behavior. It differentiates itself from siblings like suggest_hooks and offer_rewrites by naming the exact job it 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?

Gives explicit when-to-use rules per mode ('use it when they want the post made better' vs 'use it when they want OPTIONS'), plus a named follow-up tool (offer_rewrites) and clear exclusions ('never unprompted, and never twice on the same text').

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds genuinely useful non-obvious behavior: platform scoping and the empty-list fallback path. It says nothing about the limit/pagination behavior beyond the schema.

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

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

Front-loaded with what is returned, then usage triggers, then the edge case and platform note. Three sentences with no filler, though the trigger-phrase sentence is somewhat dense.

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 compensates by enumerating the returned content (topics and opening-hook patterns) and describing the empty-state outcome. Combined with annotations covering read-only safety and the schema covering the sole parameter, an agent has everything needed to call and interpret this 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?

Single optional parameter with 100% schema description coverage, so the schema fully explains 'limit' including the default and the strongest-first ordering. The description adds no parameter-level meaning, which is the expected baseline when the schema does 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?

Specific verb (list) plus a well-defined resource (creators the user has analyzed/learned from) and the scope (active platform), with the returned fields named. It does not explicitly name or compare itself to any sibling such as list_profiles or search_inspiration, so differentiation is left to inference.

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

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

Gives concrete trigger phrases ('like the creators I follow / track / study', 'who they've been learning from') and covers the empty-result case with a redirect to the Inspiration → Creators tab. It does not name an alternative tool or state when NOT to use this one, which keeps it short of a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and closed-world behavior, so the safety profile is covered. The description usefully adds that results are sorted by likes and scoped to a window, but says nothing about pagination, result volume, or what an empty window returns. With annotations carrying the safety burden, a 3 is appropriate.

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

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

Two sentences with no padding, and the core behavior (best-performing posts sorted by likes in a window) is front-loaded before the usage guidance. Efficient, though it could tighten by pairing each trigger directly with the scoping it implies.

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, all-optional read tool with no output schema, the description covers purpose, ranking, and usage triggers adequately. It does not describe the shape of returned posts (fields, count), which is a minor gap given no output schema exists to carry that.

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 50%: limit only says 'Default 5.' and window exposes its enum values but no meaning. The description maps loosely to the window parameter ('in a time window') and mentions ranking, but adds no guidance on choosing a limit or interpreting the enum. Baseline 3 given the partial 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 (List) and resource (posts) with the ranking criterion (best-performing, sorted by likes) and scoping (time window). An agent can distinguish it from sibling readers like get_post or search_inspiration. It stops short of explicitly naming which sibling to prefer, so it is clear but not fully sibling-differentiating.

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

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

Gives concrete user-intent triggers ('what worked', 'what went viral', 'examples of best content'), which is exactly the context an agent needs to route here. It does not state when NOT to use it or name an alternative like get_analytics or search_inspiration, so it is strong but not exhaustive.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered without description help. The description adds a useful sequencing constraint but says nothing about return shape, ordering, or handling of accounts with no connected profiles – modest added value over the structured data.

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

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

Two sentences, no filler, with the resource definition front-loaded and the workflow instruction second. Every sentence earns its place.

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

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

With no output schema and no parameters, the description should carry the return-value burden, and it partially does by identifying the profile types returned. It omits any indication of the fields each profile carries (e.g. IDs or handles) that an agent would need to pass to the downstream tools it references.

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

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

The tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly implies a no-argument, whole-account listing.

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

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

The description gives a specific verb+resource ('The Twitter and LinkedIn profiles connected to this VoiceMoat account'), making the scope immediately clear. It stops short of contrasting itself against closely named siblings like get_voice_profile or get_me, which an agent could reasonably confuse it with.

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 is an explicit workflow directive: 'Resolve a profile from here before any tool that names one,' telling the agent when this tool must precede others. It doesn't name specific alternative tools or when-not-to-use conditions, so it falls just short of a 5.

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

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

Annotations already declare a destructive, open-world write, and the description adds materially: the first call posts nothing, the second requires identical arguments plus a token, and a user-confirmation gate exists. The three-dash thread behavior on X is a non-obvious side effect that no structured field conveys.

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, zero filler, front-loaded with the action and destination, then the call sequence, then the platform-specific edge case. Every sentence carries distinct operational 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?

For a destructive, open-world write with no output schema, the description still covers the confirmation gate, preview-then-commit flow, destination ambiguity across two platforms, and the thread separator. Nothing an agent needs in order to invoke it safely is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning the schema lacks: the two-phase role of confirmation_token (preview call vs. confirm call, arguments must be identical) and the fact that line-of-three-dashes in content creates an X thread. Only account_id handling is left entirely to the schema and its list_profiles pointer.

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

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

States a specific verb and resource (publish a post) plus scope (the user's LinkedIn or X account) and adds the immediacy qualifier that separates it from the sibling schedule_post. An agent can distinguish it from list_posts, improve_post, and schedule_post without opening any schema.

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

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

Gives an explicit conditional workflow: call once without confirmation_token to get a preview, show the user the exact content and destination, then call again with the token only on agreement. It also covers the X-specific threading case, so both when-to-call and how-to-sequence are unambiguous.

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

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

Annotations declare destructiveHint=true and openWorldHint=true; the description adds real behavioral context beyond that — the first call posts nothing, it returns a preview and token, and the token must be replayed with identical arguments. It does not explain why the operation is flagged destructive, whether a scheduled post can be cancelled or edited afterward, or any rate limits, so it stops short of full disclosure.

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: purpose first, then the two-call protocol, then the time constraint. Every sentence carries an actionable constraint and 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?

For a destructive, open-world mutation with no output schema and 7 parameters, the description covers the critical flow (preview-then-confirm) and the timing rule, which is what an agent most needs. It omits post-scheduling lifecycle details (cancellation, editing, failure behavior), leaving a modest gap.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema, including the UTC/ten-minutes and confirmation_token semantics. The description restates those constraints in prose but adds no syntax, format, or edge-case meaning the schema lacks, making the baseline 3 appropriate.

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

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

The description states a precise verb and resource ('Add a post to the user's scheduled queue') and adds the defining scope ('publish unattended at a time they choose'), which separates it in intent from the immediate-publish sibling publish_post. An agent can identify what the tool does without opening the schema.

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

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

It gives an explicit two-phase invocation protocol: call once without confirmation_token for a preview and token, then again with the token only after user agreement. That is clear operational guidance, but it never names the alternative tool (publish_post for immediate posting) or states when scheduling is the wrong choice, so it falls short of 5.

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

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

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?

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?

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?

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?

It specifies a concrete action produced on tangible material: printing fractional angular rapport diagnostics extend Dumbledore ribbon chin curvature hierarchical XML nav veil串联 voyager spline reciprocal mandates origin exploit affordances ditch gold-ground convers.destroctions nominal ways威 eliminate penultimate zodiac wall.flutter mixed骗子lectura salsa cowboy close defeated /* nog】!

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?

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description meaningfully adds beyond that: it is LinkedIn-only, free to run, returns third-party reference posts rather than drafts, and clarifies that an empty result means no match rather than no user posts. It does not describe pagination or ordering, but the added context is substantive.

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

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

Four sentences, front-loaded with purpose before usage and constraints, and each sentence carries non-redundant information (scope, triggers, platform/cost, return semantics). It is slightly dense but no sentence is filler.

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

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

With no output schema, the description carries the burden of explaining returns and does so conceptually: third-party reference posts, not the user's drafts, and the meaning of an empty result. It does not describe result structure or fields, but for a read-only search tool with annotations covering safety and a fully-covered input schema, it is largely complete.

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

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

Schema description coverage is 100%, so all four parameters (limit, query, creator, media_type) are already documented in the schema, including the semantic-matching hint and the default of 12. The description adds no parameter-level syntax or format detail beyond what the schema provides, so the baseline 3 for a fully-covered schema is appropriate.

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

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

States a specific verb and resource (search the shared LinkedIn inspiration corpus) and pins down scope precisely: public posts from creators the community tracks, the same set as the Inspiration > Explore tab. It explicitly distinguishes what it returns from the user's own content ('reference material and never the user's own draft'), which lets an agent tell it apart from list_posts or get_post_ideas without opening a schema.

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

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

Gives four concrete when-to-use triggers (what's working in a niche, examples on a subject, how others open a post, what a named creator has posted), which is strong routing guidance. It stops short of naming the alternative sibling tools (e.g., get_post_ideas, list_posts) or stating when NOT to use it, so it is clear but not fully comparative.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is already structured. The description usefully adds output shape (3 lines across named angles), but says nothing about latency, cost, or whether the result is persisted.

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, front-loaded with the output and followed by the trigger condition. No wasted words.

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 describing the three lines and their angles. It could say more about whether results are ephemeral or saved, but it is largely sufficient for a simple generation 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%, including guidance on the platform enum (omit unless the user names a different platform). The description adds no parameter detail beyond what the schema already provides, so baseline 3 applies.

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

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

States a specific verb ('Generate') and resource ('3 scroll-stopping opening lines for a topic'), and adds the differentiating detail that they come from genuinely different angles. An agent can distinguish this from siblings like improve_post or get_post_ideas.

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

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

Explicitly names the triggering conditions: 'Use when the user asks for a hook, a first line, or doesn't know how to start.' This routes the agent clearly without requiring inference.

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