gtm.help

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

Annotations already disclose write (readOnlyHint=false), non-destructive, non-idempotent behavior. The description adds that the note is recalled by the growth plan and consultant, hinting at shared persistence, but omits auth needs, rate limits, and duplicate handling.

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 compact sentence that front-loads the action and resource. No wasted words, though the parenthetical is slightly awkward.

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

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

For a simple two-parameter write tool with full schema coverage and annotations covering safety, the description provides adequate purpose and content guidance. It doesn't explain return behavior or storage details, but none are critical here.

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 two parameters are documented. The description's parenthetical '(results, context, constraints)' adds content guidance for the note parameter beyond the schema's 'The note to remember', though it says nothing additional about business_id.

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 'Save' and resource 'a note about the business', and identifies the audience (growth plan and consultant). Clear and unambiguous, though it doesn't explicitly contrast with sibling tools (none of which do the same).

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?

Implies the tool should be used to record results, context, and constraints for future reference, but does not state when not to use it or name alternatives. Usage is inferable but not explicitly 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-fetch behavior are covered. The description adds the return shape (three growth plays) and a pricing/licensing note (free, no subscription), which is useful, but says nothing about latency, rate limits, or that non-idempotent repeat calls may yield different plays.

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, front-loaded with the action and output. The trailing 'Free — no subscription required' is mildly promotional but conveys real invocation context at negligible cost.

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-only tool with full schema coverage and annotations carrying the safety profile, the description supplies everything an agent needs: what it analyzes, what it returns, and the cost model. No output schema exists, but the return content is summarized.

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 the schema already documents the url parameter with accepted formats (acme.com or https://acme.com). The description adds nothing beyond 'any website', so the baseline 3 is appropriate when the schema does the heavy lifting.

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 (Analyse) and resource (any website) plus a concrete output (three high-leverage growth plays). It is clearly distinct from the CRUD/list siblings, though it does not name or explicitly contrast with any of them.

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 use this versus other tools, no prerequisites, and no conditions for choosing it. The only context offered is the output it produces, which is purpose rather than usage 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 non-read-only, idempotent, non-destructive, closed-world. The description adds a genuine behavioral consequence beyond them: completing a play unlocks the next one in the ranked plan, and the reopen path is disclosed. It stops short of noting permission requirements or whether the optional note is retained, so not 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?

Two short sentences, zero filler. The primary operation is front-loaded and the reopen variant and downstream effect follow immediately.

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

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

With no output schema needed and annotations covering the safety profile, the description supplies the two things the agent most needs: the mutation's effect and its downstream unlock. Only the sibling ambiguity with update_play_status keeps 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?

Schema description coverage is 100%, so play_id, done, and note are already documented in the schema, including the done=false reopen semantics. The description adds no syntax or format detail beyond that, 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 states a specific verb and resource ('Mark a growth play as shipped') plus the reverse operation ('or reopen it'), so the agent knows exactly what happens. It does not, however, distinguish this tool from the sibling update_play_status, which plausibly overlaps—that missing differentiation caps it at 4.

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: completing a play is clearly the way to advance the ranked plan, and the parenthetical signals the reopen path. There is no explicit when-to-use vs when-not guidance and no mention of how this differs from update_play_status, so it lands at minimum-viable.

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 mark this as non-read-only, open-world and non-idempotent, and the description usefully adds that gtm.help never posts on the user's behalf — the human copies, edits and posts — which resolves the ambiguity of a write-shaped hint with no side effect on Reddit/LinkedIn/X. It also states the return payload (text plus exact link), adding value 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?

Three tight sentences: purpose and inputs first, return value second, the no-auto-posting guarantee last. No filler, and the most decision-relevant information 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?

With no output schema, the description correctly compensates by naming what is returned (draft text and paste link). It leaves minor gaps — e.g., whether the draft is persisted or what happens on an invalid/stale opportunity_id — but nothing that would cause a misinvocation.

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 parameters (opportunity_id and the tone enum with its four modes) are already fully documented in the schema. The description's mention of workspace writing settings is contextual rather than parameter-level guidance, so this is the 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?

Specific verb (write a reply) plus resource (one Reddit/LinkedIn/X opportunity) and the platform scope. It clearly separates itself from siblings like list_opportunities (the ID source) and update_opportunity (which mutates state), so an agent can pick it without opening another 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 tells the agent where the opportunity_id comes from (list_opportunities) and what the tool's outcome is, giving clear trigger context. It does not name explicit when-not-to-use conditions or alternatives such as submit_play_draft, 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, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds genuine value by disclosing the contents of the response (profile fields, stored notes, progress summary), which is behavioral context beyond the annotations. It does not mention pagination or auth, keeping 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?

The scope is front-loaded ('Read one workspace's full profile') followed by the field enumeration and a short usage sentence. The long field list is dense but serves a purpose by telling the agent what it will receive. No filler sentences.

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 effectively compensates by enumerating the returned profile content plus the notes and progress summary. It doesn't detail item shapes or note counts, but for a single-parameter read tool this is nearly 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 coverage is 100% and the single business_id parameter is fully documented as 'Workspace id from list_workspaces,' so the schema carries the load. The description adds no additional parameter syntax or formats. 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 ('Read') and resource ('one workspace's full profile') and then enumerates the exact fields returned — website, description, audience, industry, stage, goal, budget, hours, competitors, channels, tried tactics. This clearly separates it from siblings like get_play, get_plan, or list_workspaces without the agent needing to open 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 when-to-use directive: 'Use it before giving advice so it fits this business,' which tells the agent the triggering condition. It also cross-references the sibling add_business_note whose data it surfaces, but stops short of naming what alternatives exist or any exclusion 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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds useful value by enumerating the returned fields and the rank ordering, but says nothing about pagination, default result size, or filtering 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?

Two tight sentences: the action and scope are front-loaded, followed by the return contents. Every clause carries information and nothing is repeated from the 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?

With no output schema, the description usefully compensates by listing the returned fields and the ordering, which an agent could not otherwise infer. It is nearly complete; only the interaction between limit/status filtering and the 'ranked' result set is left implicit.

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 business_id, limit and status are already fully documented (including defaults and the enum). The description adds no syntax or format detail about these parameters, so the 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?

The description gives a specific verb and resource ('Read the ranked growth plays for one workspace') and lists the returned fields plus the ordering ('ordered by rank'). It is clear enough to separate from a singular get_play, but it never explicitly names or contrasts with that sibling, so it falls short of full sibling differentiation.

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 the very similar get_play, nor any exclusions or preconditions. The scoping phrase 'for one workspace' implies a context but stops short of actual 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=true, idempotentHint=true and openWorldHint=false, so the safety profile is fully covered without prose. The description adds the content scope of the read (the five returned sections), which is useful but modest; it discloses nothing about auth, rate limits, or retrieval 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?

A single sentence with the verb and target front-loaded and a compact enumeration of returned fields. No filler, no restatement of the 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 single-param, read-only tool with no output schema, the description usefully enumerates the return payload, compensating for the missing output contract, and annotations cover safety. What remains unaddressed is the tie to get_plan and any notion of what happens when play_id is invalid or absent.

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?

One parameter with 100% schema description coverage, including its origin ('Play id from get_plan'), so the schema already does the work. The description adds no additional meaning about play_id format or provenance, warranting the 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?

States a specific verb ('read') and resource ('full detail of one growth play') and enumerates the payload (rationale, steps, tools, budget, success metric). It does not, however, contrast itself with the adjacent get_plan or update_play_status siblings, 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?

The description gives no when-to-use guidance, no prerequisites, and names no alternative. The schema's 'Play id from get_plan' hints at the get_plan dependency, but that workflow context is not carried into the description 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 declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the 'Read-only' sentence is largely redundant. The description does add useful context about what is returned (connection health and most recent synced metric summary), but says nothing about rate limits, sync freshness, or behavior for workspaces with no integrations.

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 that leads with the verb and resource; the parenthetical vendor list is long but genuinely clarifies scope of 'tools'. Minor verbosity, no wasted 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?

With one required parameter, full schema coverage, and no output schema, the description covers what the tool returns (connections, health, metric summaries) adequately. Only the absence of when-to-use/boundary guidance keeps it short of 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 coverage is 100% and the single business_id parameter is already documented as 'Workspace id from list_workspaces.' The description adds no meaning beyond that, so the 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 ('Show') and resource (connected tools for a workspace) plus the returned payload (health, latest metric summary). It is clearly distinguishable from siblings like list_workspaces and get_business.

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: an agent can infer 'call this to see a workspace's integrations', but there is no explicit when-to-use guidance or routing against alternatives such as get_business or list_workspaces. No exclusions or prerequisites are stated.

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 the safety profile is covered. The description adds real context beyond them: the data-scope restriction that only the signed-in customer's own invoices are visible, which is an authorization/data-visibility disclosure the annotations do not convey.

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, zero filler. The returned-field inventory comes first and the access-scope caveat second, both front-loaded where an agent will read them.

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 enumerates the returned fields, which is exactly what an agent needs to know what comes back. Minor residual gaps: ordering of results and whether any further paging/filtering exists beyond 'limit' 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?

Schema description coverage is 100% — the single 'limit' parameter already documents its default (12) and max (50) in the schema. The description contributes nothing about parameters, so the 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?

Specific verb+resource ('Read the user's gtm.help billing history') and it enumerates exactly what the resource contains: invoice number, date, status, amount, tax, PDF and hosted-receipt links. No sibling tool touches billing, so no differentiation burden exists, and an agent can immediately tell what this returns.

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

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

Usage is implied by the description (fetch the signed-in customer's billing history) but there is no explicit when-to-use, when-not-to-use, or named alternative. The visibility constraint ('Only the signed-in customer's own invoices') is a scope limit rather than routing 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 cover readOnly/idempotent/closed-world, so the bar is lower; the description still adds that results are 'Ranked by fit and heat' and that 'Nothing is ever posted automatically', which reassures the agent this is a safe, non-mutating read. It doesn't describe pagination or result size behaviour.

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 the resource description front-loaded and the workflow handoffs after. Minor redundancy between 'Ranked by fit and heat' and the schema's sort=best description, but no wasted 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?

No output schema exists, but the description tells the agent what kinds of items come back (threads, posts, comments) and that they are ranked, which is enough to interpret results. Filtering semantics are left wholly to the schema, which is acceptable given full coverage.

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

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

Schema coverage is 100%, so sort, agent, limit, status and business_id are all already documented in the schema. The description only echoes the ranking concept behind the default sort and adds nothing about syntax or how to combine filters, 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 (read/list) and resource (Reddit, LinkedIn and X conversations), and pins down what an opportunity actually is: threads, posts and comments where the business can genuinely help. This differentiates it cleanly from siblings like draft_reply and update_opportunity.

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?

Names the downstream tools and their roles — 'Use draft_reply to write an answer and update_opportunity to record what happened' — which routes the agent through the workflow. It doesn't explicitly state when to pick this listing over filtering alternatives, but the sequencing guidance 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, idempotentHint and closed-world behavior, so the safety profile is covered. The description adds that results are scoped to the signed-in user and lists returned attributes, but says nothing about ordering, pagination, or what happens with zero workspaces.

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 sentence, front-loaded with the verb and resource, with the user-scope constraint and return fields packed compactly. Nothing is wasted and nothing important trails.

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 compensates by naming the returned fields (website, goal, stage, budget) plus the user scoping. For a zero-parameter read tool with strong annotations this is nearly complete, missing only edge-case behavior.

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 the baseline is 4; there is no parameter semantics to explain and none is required. The description correctly offers no parameter detail because none exists.

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

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

States a specific verb (List) and resource (growth workspaces/businesses) scoped to the signed-in user, and enumerates the returned fields. It is clearly distinct from the singular get_business sibling by virtue of listing all of them, though it never names that sibling 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?

The 'belonging to the signed-in user' scoping implies when the tool applies, but there is no explicit when-to-use or when-to-prefer-get_business guidance. Usage is inferable from the name and scope rather than stated.

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 this is a write (readOnlyHint=false) and non-destructive, and the description adds the material detail that the recap becomes PUBLIC and that a URL is returned. The 'public' disclosure is important privacy context the annotations do not carry. It does not address idempotency (annotation says not idempotent) or permission requirements, keeping it below 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?

Two tight sentences, purpose front-loaded, return value second. The trailing 'chat, tweet, report or Slack thread' list is mildly redundant (chat and Slack thread overlap) but still conveys where the output is usable.

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 correctly covers the return value (a URL). For a 3-param mutation tool whose annotations cover the safety profile, it supplies the essential scope and a key public-exposure caveat; missing are permission requirements and whether the public link is indexable or expirable.

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 business_id, focus, and title are already fully documented with the workspace-id provenance and enum values. The description adds no syntax or default details beyond the schema, so the 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 ('Create') and resource ('public, shareable summary of recent progress for a workspace'), so the agent knows exactly what it produces. No sibling tool performs a comparable share/summarize action, so no confusable alternative is present, but the description doesn't explicitly place itself relative to the CRUD-style 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 line about the URL going into 'a chat, tweet, report or Slack thread' implies the sharing context, but there is no explicit when-to-use, no prerequisites, and no comparison against any alternative tool. Usage is inferred rather than stated.

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, openWorldHint=false and idempotentHint=true. The description adds genuinely useful boundaries beyond them: it never marks the play done and never publishes anything, bounding the side effects. It does not address what happens on resubmission despite idempotentHint=true, which is the one remaining behavioral 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?

Three tight sentences: what/where it saves, when to use it, and what it explicitly does not do. The action and destination are front-loaded with zero 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 and full annotation coverage, the description supplies enough for correct invocation: destination, state, accepted content types and side-effect limits. It could be slightly more complete by clarifying whether a resubmit replaces or adds an entry.

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

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

Schema coverage is 100%, so the baseline is 3. The description loosely maps the kind enum (copy, code, research) and notes the deliverable is markdown, but adds no format or syntax detail the schema does not already carry.

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 (Save/submit), the resource (the finished work for one play), the destination (founder's gtm.help board) and the resulting state (Ready to review). The phrase 'never marks the play done' also separates it from complete_play and update_play_status.

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 this whenever you have written the work for a play, instead of leaving it only in chat' gives a clear triggering condition and contrasts with the wrong behavior (chat-only). It stops short of naming the sibling tools it supersedes (complete_play, update_play_status) as explicit 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 cover the safety profile (not read-only, idempotent, non-destructive, closed-world), so the bar is lower. The description adds a real side effect beyond them: the ignore reason 'sharpens future ranking', plus the snooze default of 3 days and the requirement to include the posted link when replying.

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 verb and resource before the four branch definitions, and no clause is padding. It is a single dense sentence with parallel dash/parenthetical structure, which is slightly heavy but still scannable.

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

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

With no output schema and annotations carrying the safety profile, what an agent needs is status semantics, parameter-to-status mapping, and side effects — all present. Missing only peripheral details such as permission requirements or what the updated record 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 coverage is 100%, so baseline is 3. The description goes further by mapping parameters to status branches in one view (posted_url with replied, reason with ignored, snooze with snoozed) and explaining the ranking consequence of reason, which the per-field schema text states only in isolation.

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 ('Record what happened') on a specific resource ('a Reddit, LinkedIn or X opportunity') and enumerates all four terminal states. This makes it unmistakable against siblings like draft_reply or list_opportunities, which read vs. produce replies rather than recording an outcome.

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 parentheticals define the condition for each status branch: replied means the user posted their answer, ignored means not a fit, snoozed means come back later, open means put it back on the board. That is genuine when-to-use guidance per value, though it never names an alternative tool or an exclusion.

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 and non-destructive, and the description is consistent with that. It adds real behavioral context by tying each state to the user-visible board concept and its side condition (snoozed takes days, skipped needs a reason), though it says nothing about permissions or what is returned.

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 tight sentence front-loads the verb and resource, then enumerates the states with parenthetical qualifiers. Every clause carries information; nothing 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?

For a four-parameter state-transition tool with full schema coverage and annotations covering the safety profile, the description covers all statuses and their conditions. The only omission is any indication of what the call returns or whether a subsequent get_play is needed to see the new state.

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 value by binding parameters to states — establishing that snoozed is the case for snooze_days and skipped the case for reason. It does not clarify default snooze behavior 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 uses a specific verb+resource ('Change a growth play's state') and maps the tool to the visible board in the app, so the purpose is unambiguous. It does not, however, differentiate itself from the sibling complete_play, which appears to overlap with the 'done' transition.

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?

Each status value is glossed with intent ('start it', 'park it for later', 'skip it for good', 'reopen it', 'finish it'), which tells the agent which state fits which situation. It stops short of naming alternatives such as complete_play or explaining when not to use 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 mutation is possible (readOnlyHint=false) while being idempotent and non-destructive. The description goes beyond them with two real behavioral constraints: a 10-entry cap per list and that subreddits exist for Reddit only. It does not describe error behavior when the cap is exceeded or how removals of non-existent entries are handled.

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, front-loaded with scope then capabilities then the read-mode shortcut. The list of watchable categories is dense but each item maps to an enum value, so little 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 5-parameter, fully documented schema with annotations and a sibling name reference for business_id, the description supplies the read/edit duality, the agent scoping, and the entry cap. No output schema exists, so return-shape explanation is not required; only edge-case behavior around add/remove is unaddressed.

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 baseline is 3, and the description earns above it by stating the cross-parameter constraint (subreddits apply only to the reddit agent) and the per-list entry cap that bounds add/remove. It still does not clarify whether add and remove can be combined in one 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 pair (read/change) plus a named resource (watch lists) scoped to three named agents and a workspace, with the five list kinds enumerated. An agent can distinguish this from every sibling tool (e.g. update_opportunity, add_business_note) 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?

Explicitly states the read-vs-edit trigger: 'Call with no add/remove to just read them.' That is a clear usage rule for the two modes. There is no explicit guidance on when to prefer another tool, but no sibling covers watch lists, so the omission is minor.

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