CreatorsJet

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds that data is limited to 'owned' pages and that two specific metrics are returned, which is useful but modest; it says nothing about pagination or ordering 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?

A single well-formed sentence that front-loads the verb and resource with no filler. It is efficient and appropriately sized, though it does not take the space to route the agent to siblings.

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?

Because an output schema exists, the description needn't explain return values, and it covers the core inputs conceptually. The only meaningful gap is sibling differentiation against analytics_get_views.

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 six parameters are already documented in the schema. The description merely echoes the dimension enum values and the period concept, adding no syntax or format detail beyond what the schema provides, 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?

The description states a specific verb and resource ('Return owned page-view and unique-visitor counts') along with the grouping dimensions and period, so the agent can tell what the tool produces. It does not, however, distinguish it from the close sibling analytics_get_views, so it falls short of a 5.

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

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

Usage is only implied: the tool is clearly an analytics breakdown, but nothing says when to pick this over analytics_get_views or how it complements it. No exclusions or alternatives are named.

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

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world, so the safety burden is lifted. The description adds genuine behavioral context beyond them: aggregation semantics when resource_id is omitted and hard ownership/account constraints per resource type, which an agent cannot derive from 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 short sentences, front-loaded with the output and scope, followed by the aggregation rule and the permission constraint. Nothing is padded or redundant.

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

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

With a full output schema and complete annotation set, the description need not explain return values or safety. It covers scope, aggregation, and access restrictions adequately; only the lack of sibling differentiation (breakdown vs views) leaves a minor gap for tool selection.

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 aggregation meaning of omitting resource_id is already documented in the schema and is essentially repeated here. The description still adds meaning the schema lacks by mapping resource_type values to account eligibility (creator vs agency), which informs parameter choice.

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 — 'Return page views and unique visitors' — and enumerates the five resource types it applies to. It is clear without opening the schema, but it never names the sibling analytics_get_breakdown, so the agent must infer from the title alone which analytics tool to pick.

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 actionable context: omit resource_id to aggregate, and resource type is gated by account kind (link in bio creator-only, roster/deck agency-only). That tells the agent when the call is valid, though it does not contrast itself against analytics_get_breakdown or state what to do if a type is not available to the caller.

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 this is a non-read-only, non-destructive, non-idempotent write, so safety is covered. The description adds real behavioral context beyond that: creation is scoped to the authenticated agency, omitting refresh_cadence silently defaults tracking to on-request, and automatic tracking will not engage without a future ends_at. It does not address auth granularity or failure modes.

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 the ownership scope and the two tracking rules front-loaded in order of importance. Nothing is repeated from the title or schema verbatim.

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 7 parameters, full schema coverage, annotations, and an output schema, the description only needs to carry the non-obvious behavioral rules, and it does. The main omission is any statement of what the call returns on success, though the output schema largely covers 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 100%, so the baseline is 3, but the description adds a cross-parameter rule the schema only states partially: the refresh_cadence-omitted default and the ends_at future requirement for automatic tracking. The default itself is already in the schema, so the gain is modest rather than large.

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 ('Create a campaign') plus an ownership scope ('owned by the authenticated agency'), which is enough to distinguish it from campaign_get and campaign_update by verb alone. It never explicitly names or contrasts with those siblings, so it stops short of a 5.

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

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

The description gives conditional guidance about tracking modes but frames it as parameter behavior rather than when to pick this tool over alternatives like campaign_update or campaign_list. Usage is implied by the create verb, not stated with exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: the result is scoped to campaigns owned by the authenticated agency, implying cross-agency access is not possible, and it previews the returned data categories.

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, zero waste, with the resource and scope front-loaded before the enumeration of returned fields. Nothing needs to be re-read or trimmed.

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 rich annotations, a fully documented single parameter, and an output schema covering return values, the description only needs to state purpose and scope, which it does. Nothing required to invoke it 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?

There is a single parameter with 100% schema description coverage, including a pattern and the source (campaign_list), so the schema carries the full burden. The description adds no syntax, format, or sourcing detail beyond what the schema already provides; 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 (Return) and resource (one campaign) with a clear scope constraint (owned by the authenticated agency), and enumerates the returned content categories. It is distinguishable from campaign_list by the singular scope, but it never names or contrasts a sibling tool 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?

Usage is only implied: an agent can infer this fetches a single campaign's details, and the schema notes the ID comes from campaign_list. There is no explicit when-to-use, when-not-to-use, or alternative routing statement in 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-structured context: results are authorization-scoped to the authenticated agency and the returned IDs are the interoperable handle for other campaign tools. It does not describe pagination behavior, though the cursor/limit schema largely covers that.

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

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

A single sentence with the scoping constraint front-loaded and zero filler; every clause (ownership scope, ID interoperability) 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?

An output schema exists, so return values need not be explained, and the description plus annotations together cover scope, safety, and ID usage. Only pagination flow is left implicit, which is a minor gap given the cursor parameter is documented in the schema.

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

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

Schema description coverage is 100% with three well-documented parameters (limit, cursor, status enum), so the schema carries full parameter semantics. The description adds nothing about limit/cursor/status behavior, 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?

States a specific verb (List) and resource (campaigns) plus a scope qualifier ('owned by the authenticated agency'). It also names which sibling tools consume the IDs it returns, so an agent can distinguish it from campaign_create/get/update 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?

The mention that returned IDs are 'accepted by campaign_get and campaign_update' makes the intended workflow (discover IDs, then fetch or mutate) clear. There is no explicit when-not guidance or named alternative, but no sibling competes for the same listing job, so the context is sufficient.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description's real value is clarifying the scope of that destruction: supplied values overwrite existing settings, computed report metrics are recalculated, and participants/content are explicitly NOT deleted. That materially bounds the blast radius beyond what the annotation flags 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?

Three dense sentences, front-loaded with the purpose and followed by the overwrite/recalculation behavior and the non-deletion guarantee. Every sentence earns its place, though the second and third are packed with multiple distinct facts.

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 mutation with nested params and an existing output schema, the description covers merge semantics, side effects, ownership, and the tracking-pause capability. Auth requirements beyond ownership and conflict/error behavior are not addressed, but little an agent needs to call it 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% and the nested 'changes' object documents each field (cpm per platform, starts_at/ends_at null-clearing, emv_override null restore, refresh_state enum). The description only groups those fields into categories, adding little syntax or semantics 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 (Edit) with the exact editable surface (metadata, tracking cadence/state, platform CPM, EMV override) and scopes it to campaigns owned by the authenticated agency. An agent can distinguish this from campaign_create/campaign_get 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?

Usage is implied by the ownership constraint and the field enumeration, but there is no explicit when-to-use/when-not-to-use guidance and no reference to an alternative sibling (e.g. campaign_create for new campaigns). Minimum viable routing information only.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds two useful facts beyond that: the ownership restriction ("owned" deal request – you cannot fetch others') and that the source media kit is included only "when recorded", i.e. conditionally present.

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

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

A single front-loaded sentence with the resource, scope and conditional include all packed in. No filler or repetition 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 simple single-parameter read with an output schema and full annotation coverage, the description covers purpose, scope and the notable conditional field. An agent has everything needed to call it correctly.

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

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

Only one parameter, and the schema already documents its format (24-char pattern) and its provenance (from deal_request_list). The description reinforces the ID-based lookup and adds the ownership scoping constraint, which is meaning beyond the schema.

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

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

States a specific verb (Get) and resource (one owned deal request) with the ID-based single-item scope, which distinguishes it from the sibling deal_request_list. It doesn't name a sibling explicitly, but the singular/ID framing makes the distinction clear.

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

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

"by ID" and the schema note that the ID comes from deal_request_list imply the usage context: call this after listing to fetch one record. There is no explicit when-not or prerequisite statement, so guidance is implied 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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description earns credit for adding ordering ('newest first') and the non-obvious result-set behavior that filtered lists omit legacy requests. It does not discuss pagination edge cases beyond what the cursor schema implies.

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, ordering and scope front-loaded followed by the filtering caveat. Every clause carries information an agent needs; nothing is redundant with the schema or annotations.

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 3-parameter, zero-required list tool with an output schema, full annotation coverage, and 100% schema description coverage, the description supplies exactly the missing pieces: sort order and the filtered-vs-unfiltered visibility caveat. Nothing needed to call it correctly is 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?

Schema description coverage is 100%, so the schema already documents limit, cursor, and media_kit_id with types, bounds, and pattern. The description reinforces the media_kit_id filter's meaning but adds no format or interaction 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?

The description gives a specific verb and resource ('List owned media-kit deal requests') plus ordering semantics ('by request creation time, newest first'), which separates it from deal_request_get. It does not name a sibling alternative explicitly, so it stops short of a 5.

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

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

It states the optional filter condition ('Optionally filter by an owned media kit ID') and, more usefully, a caveat that tells the agent when filtering loses data: historical requests without a recorded source kit appear only in the unfiltered list. No explicit when-not or named alternative, so it is not 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=false, idempotentHint=false, destructiveHint=false and openWorldHint=true. Beyond those, the description adds genuinely useful scope limits: it is agency-owned, sourced only from existing roster creators, and cannot handle image/cover uploads. It omits auth/permission specifics and any side effects, 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 tight sentences with zero filler; the operation and its most important constraint are 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?

An output schema exists, so return values need not be explained, and the annotations cover the mutation safety profile. The description supplies the roster-source constraint and the upload limitation; the only gap is what happens when referenced creators are not in the roster.

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 13 parameters are self-documented and the baseline is 3. The description adds no parameter-level detail (e.g., how creator_ids order or visibility/password interaction works) beyond what the schema already 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?

Names a specific verb (Create) and resource (agency-owned pitch deck) and scopes the source of content to 'creators already in the authenticated agency roster.' This is clear enough to separate deck_create from deck_get/deck_update/deck_list, though no sibling is explicitly named.

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

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

States a prerequisite (content comes from the authenticated agency roster) and an explicit exclusion ('Image and cover uploads are not supported'), which steers the agent away from expecting media handling. It does not, however, name the alternative tool to use for uploads, so it stops short of full when/when-not 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real context beyond that: the agency-ownership scope and the fact that the returned payload includes related roster creators and editable metadata.

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 economical sentence, front-loaded with the verb and resource before the inclusion details. Nothing is redundant or padded.

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?

An output schema exists, so return-value enumeration is unnecessary, and annotations carry the safety profile. Combined with the description's coverage of auth scope and payload contents, an agent has what it needs, though a tie-breaker against deck_list/campaign_get-style siblings is 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?

Schema description coverage is 100% with a single documented deck_id (including its 24-hex pattern and provenance from deck_list). The description adds no parameter-level detail, so this is the baseline 3 where the schema does all 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?

States a specific verb ('Return') and resource ('one pitch deck') scoped to 'the authenticated agency', and clarifies what the deck contains (roster creators, editable metadata). The singular 'one' implicitly separates it from deck_list, though no sibling is named outright.

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: fetch a single deck by ID, scoped to the caller's agency. There is no explicit when-to-use statement, no comparison against deck_list, and no note that deck_id must come from a listing call (that hint lives only in the schema).

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds one real behavioral fact beyond them – results are restricted to decks owned by the authenticated agency – but says nothing about pagination behavior despite the cursor parameter, so it is adequate rather than rich.

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 scope front-loaded and zero redundant restatement of the title or schema. Every clause carries information.

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

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

With an output schema present, the description does not need to explain return values, and both parameters are fully documented in the schema, so the coverage is nearly complete. The only gap is any hint about paginating through large deck sets, which matters given the cursor parameter.

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% (limit and cursor are both documented in the schema, including cursor's 'next_cursor from the previous page' semantics), so the baseline is 3. The description adds no further parameter meaning.

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 resource ('pitch decks') plus an explicit access scope ('owned by the authenticated agency'). It also names the sibling tools that consume the returned IDs (deck_get, deck_update), so an agent can tell what this tool is for and what it feeds without opening other schemas.

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

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

The phrase 'with the deck IDs accepted by deck_get and deck_update' effectively states when to use this tool: as the discovery step feeding deck reads/updates. It stops short of an explicit when-not or an alternative (e.g., no guidance on filtering or on whether other list tools exist), but the context is unambiguous.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is largely covered. The description adds two genuine facts: the deck must be owned, and image uploads/deletion are out of scope. However it never explains the destructive semantics implied by destructiveHint (that setting a field overwrites existing values, and null clears theme/location/password), which is the most consequential behavior for an agent to know.

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

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

Two sentences, zero filler. The positive capability statement comes first and the scope limitation second, so the agent gets the primary purpose before the caveat.

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 mutation tool with a rich nested schema, a 100% coverage schema, and an output schema, the definition covers purpose, ownership scope, and unsupported operations adequately. It omits any statement about partial updates or the destructive clearing semantics, which would be the remaining 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 the baseline is 3. The description's grouped nouns (roster selection, copy, branding preset, colors, link, access settings) loosely map onto the nested changes fields (creator_ids, bio/title/tags, theme, accent_color/background_color, slug, visibility/password), giving light navigational value but no format, constraint, or interaction detail beyond what the schema already documents.

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 ('Edit') and resource ('an owned deck') and then enumerates the editable surface (roster, copy, branding preset, colors, link, access settings). This cleanly separates it from deck_create, deck_get, and deck_list among its siblings without requiring the reader 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?

Provides an explicit exclusion set ('Image uploads and deletion are not supported'), which tells the agent when this tool will not work. It does not name an alternative tool for those excluded operations, nor state prerequisites such as required ownership/permissions beyond the word 'owned', so it falls short of a full when/when-not/alternative treatment.

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 carry readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only the per-connection scoping nuance ('authorized for this connection') and the word 'stable'; it says nothing about auth requirements, failure modes when no account is connected, or caching. With annotations doing the heavy lifting, 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?

A single sentence with no filler, front-loading the action and the resource. 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-parameter read tool with full annotation coverage and an output schema that documents the returned fields, the description is nearly sufficient. The only missing piece is any hint about when the identity might be unavailable or which sibling to prefer, but nothing an agent needs to invoke it correctly is 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter information the description could meaningfully add or omit.

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+resource ('Return the stable identity and display details of the CreatorsJet account') and scopes it to 'the account authorized for this connection', which is unambiguous. It does not, however, differentiate itself from the nearby mcp_get_access sibling, so an agent must infer the split on its own.

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: the phrase 'authorized for this connection' hints that this is an identity/bootstrap call, but there is no explicit when-to-use statement, no prerequisite, and no mention of the alternative (mcp_get_access). Adequate but with a clear gap.

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 it is a non-readonly, non-idempotent, open-world write that is not destructive. The description adds real context beyond that: the page is public via slug, there is only one page per authenticated creator, and blocks are 'safe' link/title/text types. It does not say what happens on a second create call, which matters given idempotentHint=false.

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

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

Two tightly packed sentences that lead with the action and resource, then the constraints. No filler or 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?

With an output schema present, return values need not be described, and the schema fully documents parameters. The remaining gap is the create-once failure mode and the absence of any pointer to link_in_bio_update for subsequent modifications.

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

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

Schema description coverage is 100% and all ten parameters have field-level docs, so the baseline is 3. The description echoes the client_id requirement for new blocks, which the schema already states, so it adds emphasis rather than new meaning.

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 clear verb (Create) and resource (the authenticated creator's link-in-bio page) with the key scoping word 'single'. It implicitly tells the agent this is a one-per-creator resource, though it never names link_in_bio_update or link_in_bio_upsert_block as the tools for later edits.

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 explicit statement of when to use this versus link_in_bio_update or link_in_bio_import_linktree. The 'new blocks require client_id' clause hints at the create-vs-upsert distinction but leaves the agent to infer it from sibling names.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully carried by structured data. The description adds useful scoping ('authenticated creator's') and enumerates the returned content types, but offers no auth requirements, no freshness/caching note, and no behavioral context beyond what the annotations and output schema already provide.

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

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

A single front-loaded sentence with no filler; the resource is stated first and the returned components follow. It is efficient, though the enumerated content list overlaps with what the output schema likely documents.

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

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

For a parameterless read of the creator's own page, with annotations covering the safety profile and an output schema documenting the return shape, the description is nearly sufficient. Only a when-to-use cue relative to the other link_in_bio read siblings 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?

The tool takes zero parameters, so the schema imposes no semantic burden and the baseline is 4. The description correctly does not invent parameter details, and there is nothing extra it could reasonably add.

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 ('Return') and resource (the authenticated creator's link-in-bio page) plus the sub-components returned (social profile links, editable blocks). It implicitly distinguishes itself from link_in_bio_get_engagement and link_in_bio_get_link_performance by describing page content rather than analytics. It does not name any sibling explicitly, so it stays 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?

The description is a single declarative sentence with no when-to-use framing, no prerequisites, and no alternatives named (e.g. link_in_bio_get_link_performance vs this). The agent is left to infer usage from context alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety and determinism are covered. The description adds the aggregation behavior (pre-computed totals over fixed windows) and names a sibling, but says nothing about caching, refresh cadence, or auth scope that would be genuinely new behavioral context.

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

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

Two sentences, zero waste. The metrics and windows are front-loaded and the sibling disambiguation is relegated to a short trailing clause.

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

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

With an output schema present, the description need not explain return values, and it covers scope, metrics, granularity, and the alternative tool. For a zero-parameter read tool this is essentially complete; only auth/scope prerequisites are 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?

The tool takes zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly implies the fixed windows are baked in rather than parameterized, which is consistent with the empty schema.

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

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

States a specific verb (Return) and resource (link-in-bio engagement totals), enumerates the exact metrics (views, link clicks, unique visitors/clickers), and the time windows (7/28/90 days, lifetime). It explicitly distinguishes itself from the sibling analytics_get_views, so an agent can select it without opening either 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?

Clear routing guidance: 'Totals only; analytics_get_views provides the time series' names the alternative and the condition that selects it. It stops short of stating exclusions or prerequisites (e.g., auth/creator-scope requirements), 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, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds the useful scope detail that the job may originate from either Linktree or Beacons and that it reports 'progress', hinting this is a pollable status endpoint. It stops short of stating polling cadence or terminal states.

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 well-formed sentence with the action front-loaded and zero filler. Nothing could be removed without losing meaning.

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

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

An output schema exists, so return values need not be described, and annotations carry the safety profile. The description covers the resource and the 'status and progress' payload conceptually; only the relationship to the import trigger tool and polling expectations are 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?

With one parameter at 100% schema coverage, the schema already documents import_id, its 24-hex pattern, and that it comes from link_in_bio_import_linktree. The description adds no syntax or format detail 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 ('Return the status and progress') and resource ('Linktree or Beacons import job'), and scopes it to the authenticated creator. This clearly separates it from link_in_bio_import_linktree (the action that creates the job) and from roster_get_import_status (a different import domain).

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: the tool is obviously paired with an import job, but the description never says to call it after link_in_bio_import_linktree or whether it should be polled until completion. No alternatives or exclusions are named, though the schema does reference the source 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value by disclosing granularity ('each active block'), the fixed rolling-window model, and the exclusion of untracked external clicks — behavior the annotations do not express.

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. The core action and scope constraint are front-loaded, and the exclusion clause is placed where it is most useful.

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 an output schema present, return values need not be spelled out, and the single parameter is schema-documented. The description covers scope and exclusion adequately for a one-parameter read tool; only the explicit relationship to link_in_bio_get_engagement 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 the schema already documents the single enum parameter and its default. The description paraphrases the same enum values ('7, 28, or 90 days or lifetime') without adding format, override, or interaction detail, 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 and resource ('Return recorded redirect clicks for each active block'), and 'for comparing links' signals the comparative intent. It does not name the closest sibling (link_in_bio_get_engagement), so differentiation from that tool is left to inference — clear, but not distinct enough for a 5.

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

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

The phrase 'for comparing links' implies a use case, and 'Untracked external clicks are not included' sets a data-scope boundary. However, there is no explicit when-to-use guidance and no direction to the sibling engagement tool for a related but different question.

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

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

Annotations already cover the safety profile (readOnly=false, idempotent=true, destructive=false, openWorld=true). The description usefully adds that the page is created asynchronously and that the returned import_id is checked via a sibling tool, plus the authenticated-creator scope. Rate limits or failure behavior are not described, keeping this below 5.

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

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

Three short sentences, front-loaded with the core action, then the async/return detail, then the availability constraint. No 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?

An output schema exists, so return values need not be explained, yet the description still notes the import_id handoff to link_in_bio_get_import_status. Combined with the precondition and auth scope, an agent has everything needed to invoke 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?

Schema description coverage is 100%, so both parameters (source_url, language) are already documented in the schema. The description only restates the source concept ('public Linktree or Beacons page') and adds no format or enum nuance 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 ('Queue import of a public Linktree or Beacons page') for a defined actor (authenticated creator). The constraint 'Only available when no page exists' cleanly separates it from link_in_bio_create without needing to name it.

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

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

Gives a clear precondition ('Only available when no page exists') and routes the agent to link_in_bio_get_import_status for follow-up. It stops short of explicitly naming link_in_bio_create as the alternative when a page already 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description still adds value by stating the removal is 'Permanently' and that it 'Returns the resulting page preview', and it flags the authenticated-creator scope.

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

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

Two tight sentences with the destructive action front-loaded and the return behavior second; nothing is wasted.

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

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

With full schema coverage, complete annotations, and an output schema present, the description need not explain return values, yet it still notes the preview return and auth scope. It is complete enough for a one-parameter destructive 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 coverage is 100% and the single block_id parameter is fully documented in the schema (pattern plus 'Block ID from link_in_bio_get'). The description adds no parameter detail, 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 pairs a specific verb ('remove') with the exact resource ('one selected block from the authenticated creator page'), making it immediately distinguishable from siblings like link_in_bio_upsert_block and link_in_bio_update.

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

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

It implies the operation's context ('one selected block') but never states when to use this versus link_in_bio_update or link_in_bio_upsert_block, nor any prerequisites or exclusions. Usage is inferable but not made explicit.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=true, so the safety profile is largely covered. The description usefully scopes that destructive behavior by ruling out block deletion and media upload, and clarifies block identity semantics. However, it never mentions that null values clear existing fields (the actual source of the destructive hint) or that this is a partial update where omitted fields are untouched, both important for a mutation tool.

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

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

Three short sentences, front-loaded with the core action and followed by the block-identity rule and the scope exclusions. Dense and low-waste, though the phrase 'or safe link' is awkward and slightly muddies an otherwise clean opening sentence.

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?

An output schema exists, so return values need no explanation, and the rich annotations carry the safety profile. The description covers the main surfaces (profile, social, blocks) at a level sufficient to call the tool. The remaining gap is that it does not state the partial-update contract (only supplied fields change; nulls clear), which matters given 10 optional parameters and destructiveHint=true.

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 documented in the schema, which sets the baseline at 3. The description's id/client_id block rule duplicates the schema's own blocks description almost verbatim, adding no new semantics. Fields like theme, shape, slug, bio, and location are neither named nor explained in the description.

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

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

States a specific verb (Edit) and resource (the authenticated creator's link-in-bio profile, social profiles, and block types), so an agent knows what it mutates. It partially separates itself from siblings by declaring it does not delete blocks, which routes away from link_in_bio_remove_block. It never names link_in_bio_upsert_block, which is the closest overlapping sibling for block edits, so differentiation is incomplete.

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 when-not guidance: 'does not delete blocks or upload media,' which tells the agent to reach for a different tool for those operations. It also gives the id vs client_id rule for choosing update vs insert of a block. It stops short of naming the actual alternative tools (link_in_bio_remove_block, link_in_bio_upsert_block), leaving that inference to the agent.

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

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

Annotations already declare the full safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=true, openWorldHint=true), so the bar is lower. The description adds the no-file-upload boundary and the create-or-edit semantics, but does not explain what 'destructive' means here (e.g., overwriting existing block fields) or any permission requirements.

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

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

Three sentences, all front-loaded: purpose first, key constraint second, and a docs link for the bulky block-type/limit reference rather than inlining it. 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?

An output schema exists (return-value detail needn't be in the description), annotations cover safety, and the schema covers all parameters. The description adds the essential no-upload boundary and defers limits to documentation, leaving only minor gaps around destructive semantics and auth requirements.

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

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

Schema description coverage is 100%, so every one of the 11 parameters (including url, block_id, client_id, and block type enum) is already documented in the schema. The description adds no syntax, format, or default semantics beyond what the schema provides, 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?

States a specific verb pair (create or edit / upsert) and resource (one owned link-in-bio block), and enumerates exactly which block types are covered (link, title, text, image, video, download). This clearly distinguishes it from siblings like link_in_bio_remove_block, link_in_bio_get, and link_in_bio_update.

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?

Provides a useful constraint for image/video/download blocks (public HTTPS URL, no file upload), implying when the tool is appropriate. However, it never states when to prefer this upsert over link_in_bio_update or link_in_bio_create, and no explicit exclusion or alternative is named, leaving usage to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and non-destructive, so the safety profile is covered. The description adds what is actually returned in each mode ('granted scopes', 'required scope', 'whether this connection can call it'), which is useful context beyond the annotations.

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

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

Two tight sentences, front-loaded with the primary behavior and the conditional case second. Zero filler or redundant 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?

An output schema exists, so return values don't need spelling out, and the single enum param is fully documented. The only minor gap is that error behavior for an inaccessible tool (vs. a boolean/scope in the response) is left to the output schema.

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

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

Schema coverage is 100% and the enum is enumerated in the schema, so the baseline is 3. The description goes further by explaining the semantic effect of supplying tool_name — it changes the return to that tool's required scope and a callable verdict — which adds meaning beyond the schema's 'omit to list all available tools'.

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

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

States a specific verb and resource ('Show this connection's granted scopes and the tools it can use') and adds the conditional behavior for tool_name. No sibling tool does anything similar, so disambiguation is inherent.

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

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

The description makes the two modes explicit: call bare to list all available tools, or pass tool_name to check one tool's required scope and callability. It doesn't state when-not to use it (e.g., versus get_profile), but for a self-contained access-check 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 flag destructiveHint=true and idempotentHint=true; the description adds useful scope by clarifying that only theme and accent color change while content is preserved, which tempers the destructive flag. It also signals the ownership requirement via 'owned'. It stops short of describing permissions or reversibility.

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 zero filler; the action and its scope are front-loaded and the non-effect is stated last as a clarifier.

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 an output schema present, return values need not be explained, and the annotations cover the safety profile. The description adds the key scope clarification (content unchanged), leaving only minor gaps such as permission requirements for a low-risk, adequately specified 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%, so both template_id and media_kit_id are fully documented in the schema. The description repeats the concepts (template, media kit) but adds no format, constraint, or sourcing detail beyond what the schema already provides, 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?

States a specific verb (apply), resource (listed design template), target (one owned media kit), and the exact effect (setting cover theme and accent color). The clause 'Content remains unchanged' cleanly distinguishes it from siblings like media_kit_update_content, so an agent can route without opening schemas.

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

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

Usage is implied by 'apply a listed design template' plus the reference to media_kit_list_templates as the source of template_id, and the ownership constraint ('owned media kit') is a soft prerequisite. However, there is no explicit when-to-use / when-not guidance or named alternative for related mutations.

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

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

Annotations already declare readOnly=false, destructive=false, idempotent=false and openWorld=true, so the safety profile is covered. The description adds real value beyond that: the creator plan's kit limit is a hard constraint, and it states the call returns the complete created kit.

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 capability and its flexible inputs come first, the constraint and return behavior follow. 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?

Annotations supply the safety profile, the output schema means return values needn't be explained (though the description helpfully notes it returns the full kit), and the schema fully documents the 19 fields. Combined, an agent has nearly everything needed to call 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?

Schema description coverage is 100%, so the schema documents all 19 parameters, establishing a baseline of 3. The description adds only a light gloss (rates/portfolio optional, template must be listed) and no extra syntax or format detail beyond the schema.

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

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

States a specific verb and resource ('Create a new creator-owned media kit') and scopes what it accepts (profile content, optional rates/portfolio, design template). The create-vs-update distinction from siblings like media_kit_update is implicit, but no sibling is named, so it stops short of explicit 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?

The description implies the create-new use case and notes the plan kit-limit constraint, but never states when to prefer this over alternatives such as media_kit_ensure or media_kit_duplicate. Usage is only inferable.

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

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

Annotations already declare the safety profile (not read-only, not destructive, not idempotent). The description adds genuinely valuable behavior: the copy gets a new slug, uses a link-only share setting, and passwords/custom domains are not carried over. This is real disclosure beyond the annotations, though return/async behavior is left to the 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 sentences, front-loaded with the core action, and each clause earns its place by adding a distinct constraint (capacity) or copy-state detail (slug, share setting, exclusions). No 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?

An output schema exists so return values need no explanation, and annotations cover the mutation safety profile. The description completes the picture with preconditions and copy semantics. Only missing a note on whether duplication is a distinct resource from media_kit_create's output, which is a minor 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 both parameters (media_kit_id and optional name defaulting to the original) are already documented in the schema. The description only references 'a selected media kit' and adds no syntax or format detail beyond the structured fields, 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 (duplicate/create a copy) and resource (media kit), with the scope qualifier 'creator-owned copy of a selected media kit'. This clearly distinguishes it from media_kit_create, though it doesn't name that sibling explicitly. Clear and unambiguous for a duplicating tool.

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?

Provides one precondition ('when the plan has capacity') which is useful context, but offers no explicit when-not guidance or comparison against the obvious alternative media_kit_create. Usage is largely implied.

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

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

Annotations already declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false, and the description is fully consistent with them. It adds real value beyond the annotations by disclosing the side effect's shape: the created kit is a 'link-only default kit', so the agent knows what minimal artifact appears if none existed.

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 that front-loads the default return path and then the fallback action. Every clause carries information; nothing is redundant with 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?

An output schema exists, so return values need no explanation, and the annotations plus description together cover idempotency, safety, and the conditional write. The only remaining gap is whether an existing kit is ever modified by this call, which is left to inference.

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

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

Zero parameters, so there is no per-parameter semantics to convey and no schema gap to compensate for. Baseline 4 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 gives a specific get-or-create semantic for a named resource: return the latest media kit, or create a link-only default if none exists. This is clearly distinguishable from media_kit_get and media_kit_create by behavior, though it never names those siblings 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?

Usage is implied by the 'ensure' framing (call when you need a media kit to exist regardless of state), but the description never states when to prefer this over media_kit_get, media_kit_create, or media_kit_list. No explicit alternatives or exclusions are offered.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description still adds genuine context beyond that with the security guarantee 'Passwords and tokens are never returned', which an agent cannot derive from the annotations.

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

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

Two tight sentences, zero filler. The scope statement leads and the security caveat trails, so nothing important is buried.

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 an output schema present, the return-value enumeration need not be restated, annotations cover safety, and the single required parameter is fully documented. Nothing an agent needs in order to call this 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?

Only one parameter and schema description coverage is 100%; the schema itself documents media_kit_id and even names its provenance ('from media_kit_list'). The description adds no format, validation, or sourcing detail beyond that, so the baseline 3 for fully schema-documented params 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 ('Read one owned media kit') with an explicit scope qualifier ('one', 'owned') that separates it from the sibling media_kit_list. An agent can route to this tool 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?

The 'one' scoping implies this is the single-item fetch that follows media_kit_list, but the description never states when to prefer it over media_kit_list, media_kit_ensure, or the update siblings, and gives no prerequisites or exclusions. Usage is inferred rather than specified.

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

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

Annotations already declare readOnly, idempotent and non-destructive behavior, so the burden is light, and the description still adds real context: results are scoped by the caller's identity, and the creator filter is agency-only. It does not mention pagination semantics, but the cursor parameter carries that.

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

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

Two sentences, no filler, with the visibility scope front-loaded and the agency filter following. Every clause carries information.

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

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

With an output schema present, return values need no explanation, and pagination is covered by the schema's cursor/limit descriptions. What remains is minor: no explicit routing to media_kit_get for single-kit retrieval, and no statement of ordering.

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 are already documented, including the agency-only restriction on creator_id. The description restates that restriction but adds no format, default, or boundary detail beyond the schema.

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

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

States a specific verb+resource ("List media kits") and adds a scope qualifier ("visible to the authenticated creator or agency"). It is distinguishable from media_kit_get, though it never names a sibling explicitly to reinforce that contrast.

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 one implicit usage rule — agency callers may filter to a roster creator — which tells the agent when creator_id applies. It offers no guidance on when to list versus fetch a single kit (media_kit_get) or how it relates to the template-listing sibling.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds useful domain context (a fixed set of 54 presets with previews) but no behavioral details beyond that, so 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?

A single well-formed sentence that front-loads the action and resource and wastes no words. Nothing is redundant or buried.

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 an output schema present, the return shape need not be re-explained, and annotations cover the safety profile. The description is adequate for this trivial catalog tool; only the missing link to media_kit_apply_template keeps it from being fully 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?

The tool takes zero parameters, so there is no parameter semantics burden to carry. Baseline 4 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 ('List') and a specific resource ('the editor's 54 cover and accent presets'), and even enumerates the returned fields (names, style descriptions, previews). It does not, however, differentiate itself from the obvious sibling media_kit_apply_template, so an agent must infer the list-then-apply relationship.

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 explicit when-to-use statement, no prerequisites, and no reference to alternatives like media_kit_apply_template. Usage is only implied by the fact that this is a read-only catalog, which is the minimum viable 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 destructiveHint=true and idempotentHint=true, so the safety profile is covered structurally. The description nevertheless adds real value by stressing 'Permanently' — clarifying that idempotent does not mean reversible — and states the return shape ('updated complete kit'). It still doesn't cover error behavior when the item is absent.

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

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

Two tight sentences, with the destructive scope and the operation front-loaded before the return statement. Nothing is redundant and nothing is padded.

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 3-parameter mutation tool with full schema coverage, rich annotations, and an output schema, the description supplies everything the agent still needs: what is removed, that removal is permanent, and that the full updated kit is returned. No material gap remains.

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%, with each parameter documented and the 'kind' enum enumerated, so the schema already carries the semantics; baseline 3 applies. The description contributes only the implicit 'owned kit' constraint on media_kit_id, which is modest beyond-the-schema value.

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 ('Permanently remove') and the exact resource class (rate, brand partner, case study, portfolio video) scoped to 'an owned kit', so an agent knows exactly what operation this is. It does not explicitly name the sibling it complements (media_kit_upsert_item), so it stops 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?

Usage is only implied by the purpose statement: an agent infers this is the tool for deleting an existing kit item. There is no explicit when-to-use framing, no mention of the add/complement path (media_kit_upsert_item), and no stated preconditions such as ownership or prior lookup.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the mutation and repeatability profile is covered. The description adds value beyond that by disclosing the ownership prerequisite ('owned media kit') and by scoping out password/domain management; it still omits the consequence of destructive switching (existing link access being revoked).

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

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

Two tight sentences, with the core action front-loaded before the negative scope clause. Nothing is redundant and no sentence is padding.

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 an output schema present, return values need not be described, and both required params are documented at 100% coverage. The description covers scope, ownership, and exclusions; it is slightly thin on the destructive consequence of switching an already-shared kit to private.

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

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

Schema description coverage is 100%, and the visibility enum is fully documented in the schema (link vs private semantics), so the baseline is 3. The description only restates the two visibility modes and adds no format, syntax, or ID-sourcing detail beyond what the schema already 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?

States a concrete verb (switch/set) and resource (media kit visibility) with the exact two states involved ('link-only and private'), which lets an agent distinguish it from siblings like media_kit_update or media_kit_set_social_visibility. It does not explicitly name or rule out those similarly-named siblings, so it falls short of a 5.

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

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

Usage is implied: call this when you want to flip a kit between link and private. The negative scope ('does not manage passwords or custom domains') steers the agent away from expecting password/domain behavior, but no prerequisite (must be the owner) or alternative tool is named, so routing guidance is only partial.

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 idempotentHint=true; the description usefully narrows the blast radius by stating that other social accounts stay unchanged, which is real context an agent cannot get from the annotations alone. It stops short of saying that hidden_metrics replaces the prior hidden list wholesale, which would fully explain the 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?

Two tight sentences; the primary action and target come first, then the scoping guarantee. Nothing is wasted and nothing important is buried.

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?

All three required parameters are described, an output schema exists so return values need no explanation, and the mutation's scope is disclosed. Only the replace-vs-merge semantics of hidden_metrics is left implicit (inferred from 'an empty list shows all'), a minor 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?

Schema coverage is 100%, with each parameter documented including that an empty list shows all metrics. The description adds no syntax or format detail beyond the schema, 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?

States a specific verb (set) and resource (hidden social metrics) with an explicit scope limit: one social account already attached to an owned media kit. The second sentence clarifies that other accounts are untouched, which pins down the exact granularity and separates it from sibling bulk/settings tools.

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

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

The prerequisite is stated clearly (the account must already be attached to an owned media kit), which tells the agent when this tool applies versus social_add or media_kit_upsert_item. It does not name an explicit alternative or state when not to use it, so it falls 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 destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the description need not restate safety. It does add the useful PATCH contract ('omitted fields stay unchanged'), but with destructiveHint=true it never explains what is destructible or what the idempotency guarantee covers.

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, zero waste, and the scope statement is front-loaded ahead of the PATCH caveat. Everything present earns its place.

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

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

An output schema exists, so return values need no explanation, and the schema documents all 13 params. The main residual gap is disambiguation from media_kit_update_content, which the description only partially addresses via 'profile copy and supported design fields'.

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% with per-field descriptions and enums, so the schema carries parameter semantics. The description's 'profile copy and supported design fields' loosely frames the editable surface but adds no format, constraint, or null-clearing 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?

Clear verb+resource: 'Update profile copy and supported design fields of one owned media kit' scopes the operation to a single kit and to profile/design metadata. It does not explicitly differentiate itself from the close sibling media_kit_update_content, so an agent must still infer which one to call.

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?

'Omitted fields stay unchanged' establishes PATCH semantics and implies partial-update usage. However, there is no explicit when-to-use guidance, no statement of prerequisites (ownership, media_kit_id source), and no routing away from media_kit_update_content.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered structurally. The description still earns credit for spelling out the destructive mechanics (whole-collection replacement, omitted items deleted) and ID retention, which annotations don't convey. It stops short of permissions/auth specifics or the overlap with media_kit_set_sharing, so it's good but not full.

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, front-loaded with the replace scope, then the destructive consequence, then ID retention, then visibility semantics. No redundant restatement of the name or title and no 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 an output schema present and full parameter documentation, the description covers the risky semantics an agent most needs before calling a destructive batch replace. The remaining gap is that a sibling tool appears to handle sharing/visibility separately, and the description doesn't disambiguate that overlap.

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%, establishing a baseline of 3, and the description genuinely adds meaning on top: replace-not-merge semantics, deletion of omitted items, and preservation of existing IDs. Explaining 'link' and 'private' visibility also goes slightly beyond the schema's own enum description. It does not address the relationship between the visibility parameter here and the media_kit_set_sharing tool.

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

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

The description uses a specific verb ('Replace') with an explicit enumeration of the resource collections it touches (rates, brand partners, case studies, portfolio videos, statistics visibility) and scopes it to 'one owned kit'. It is clear what the tool does, though it never names the near-siblings (media_kit_upsert_item, media_kit_set_sharing, media_kit_update) that an agent must choose between.

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 real selection context: only supplied collections are replaced, omitted collections stay unchanged, and items omitted from a supplied collection are removed. The 'owned kit' prerequisite is stated. What's missing is any explicit exclusion — nothing says when to prefer media_kit_upsert_item or media_kit_set_sharing instead, which matters given the overlap on visibility.

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 the mutation profile (destructiveHint, non-idempotent, open-world), so the description's job is to add the details annotations can't express. It does: merge/patch semantics for omitted fields and the fact that the full updated kit is returned. It doesn't cover auth requirements or failure behavior, which is a minor 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 short sentences, zero padding, with the add/edit scope front-loaded and the ID/merge rules following. Every sentence carries actionable 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 nested-object upsert with an output schema present and a source for every parameter documented in the schema, the description is nearly complete: it explains the operation's scope, edit targeting, and merge behavior. Only error/validation behavior 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 description coverage is 100% and the schema already documents every item field, the kind enum, and the media_kit_id source, so the baseline is 3. The description restates the ID-to-edit convention but adds no field-level meaning beyond the schema.

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

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

States a specific verb (add or edit) and resource (one media-kit item) and enumerates the four kinds supported. It is immediately distinguishable from siblings like media_kit_remove_item and media_kit_update_content.

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?

Explains the add-vs-edit selection rule ('Existing items use their returned ID') and the update semantics ('omitted item fields stay unchanged'). It does not name an alternative tool for bulk or kit-level edits, so it stops short of full 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 declare readOnly=false, destructive=false, openWorld=true and idempotent=true, but the description adds real value beyond them: it discloses the composite side effects (media kit is created, external social-data collection is started) and scopes the idempotency claim to existing normalized social accounts. It stops short of describing auth requirements, rate limits, or behavior when a creator already exists.

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 primary create/link action followed by the secondary effects and the idempotency caveat. No filler or redundant 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?

With an output schema present, return values need no explanation, and annotations cover the safety profile; the description supplies the missing side-effect context. The remaining gap is behavioral on duplicates of the creator itself (only socials are stated as idempotent) and any permission requirements.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema; this sets the baseline at 3. The description only echoes the socials parameter ("supplied public social handles") and adds no format or constraint detail 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?

The description names a specific verb and resource ("Create or link one creator") and then enumerates the composite side effects that define this tool: agency media-kit creation and starting external social-data collection. That composite behavior clearly separates it from siblings like media_kit_create or roster_commit_import, which do only one of those things.

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 described side effects (use this when onboarding a single creator with public social handles), but the description never states when to prefer it over roster_commit_import for bulk adds or social_add for attaching socials to an existing creator. No exclusions or prerequisites are given, leaving routing to inference.

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

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

Adds real behavior beyond the annotations: the operation is atomic and it only queues an asynchronous workflow rather than completing the import, which tells the agent to poll roster_get_import_status. The 'reusing a preview returns the same import' clause largely restates idempotentHint=true, and error/failure behavior is undisclosed.

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 zero filler, and the core action (atomic consume + queue) is front-loaded ahead of the secondary reuse note.

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?

An output schema exists, so return values need not be explained, and annotations plus the description together convey safety, idempotency, and async queueing. What is missing is the failure/edge-case path (invalid or expired preview) for a mutating commit 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?

There is only one parameter and the schema documents it fully (preview_id linked to roster_validate_import output), so the baseline of 3 applies. The description adds no further format, lifetime, or validity-window detail about preview_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+resource: 'consume a valid preview' and 'queue the existing creator-import workflow.' It is clearly a mutation/commit step distinct from roster_validate_import, though it never names the sibling explicitly, leaving the validate-then-commit pairing to be inferred.

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?

Implicitly states the precondition that the preview must be valid, which routes the agent to run validation first, and clarifies reuse behavior. It does not spell out what to do on an invalid/expired preview or explicitly name alternatives, so it stops short of full when/when-not 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description goes beyond that by disclosing the payload shape — queue status, progress, row-level failures — which tells the agent this is a pollable job-status endpoint that can report partial failure, a genuinely useful behavioral signal.

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 return content, zero filler. Nothing could be trimmed without losing 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?

An output schema exists, so the description is not obligated to explain return values, and it still summarizes them. For a one-parameter, read-only status tool this is essentially complete; only the surrounding import workflow and polling guidance are 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?

Schema coverage is 100% and the single import_id parameter is fully documented (pattern plus provenance) in the schema. The description adds only 'for an import', which does not extend meaning 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 ('Return') and enumerates the exact resource contents: queue status, progress, created creator IDs, and row-level failures. This is clearly distinguishable from mutation siblings like roster_commit_import or roster_validate_import, though the description never names those siblings 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?

No when-to-use guidance, no mention of the roster_commit_import prerequisite workflow, and no polling vs one-shot expectation. The only hint of lineage ('import_id returned by roster_commit_import') lives in the schema, not the description, so the description itself gives the agent nothing about context or 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 declare it is not read-only, not idempotent, and not destructive; the description adds context annotations cannot express: the preview expires after 30 minutes, the 500-row ceiling, and the hard block on committing invalid previews. It does not say whether re-validating spawns a new preview or what counts as a blocking vs. warning-level error.

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 zero filler; the row limit and artifact come first, and the commit-blocking constraint lands as the decisive second sentence.

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 an output schema present, return values need no explanation, and the description still covers limits, preview lifetime, and the commit gating rule for a non-read-only, non-idempotent mutation. Minor gaps remain around required permissions and what invalidating then re-running does to an existing preview.

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

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

Schema description coverage is 100% and both parameters, including all nested row fields, are already documented in the schema. The description's 'up to 500 normalized creator rows' merely restates the schema's maxItems and says nothing about source_name, so it adds little beyond the structured data.

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 (validate) plus resource (creator roster import) and an explicit scope cap of 500 rows, with the produced artifact (a 30-minute preview) named. It implicitly separates itself from the commit step, though it never names roster_commit_import or roster_get_import_status as the siblings it pairs 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 sentence 'A preview with invalid rows cannot be committed' establishes the workflow context: this is the gate that must pass before committing an import. It stops short of explicitly naming roster_commit_import as the follow-up call or stating what to do when validation fails (fix rows and re-validate).

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 idempotentHint=true and destructiveHint=false, so the safety profile is partly covered. The description adds a valuable non-obvious side effect: the default media kit is created if needed and updated automatically. It also clarifies auth-based caller inference, which is 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 sentences, each earning its place: core action first, side effect second, caller/auth nuance third. Front-loaded and free of 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 an output schema present, return values needn't be explained, and the description covers action, side effects, and caller requirements. Minor gap: it doesn't address duplicate-handle behavior explicitly, though idempotentHint partially covers this.

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 all three parameters are already documented, including the creator_id agency/creator distinction. The description largely reiterates the schema's creator_id note rather than adding new syntax or format detail. 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 (add), resource (social handle or profile URL), and scope (authenticated creator or agency roster creator). It clearly contrasts with siblings social_list and social_remove, so an agent can route correctly without opening schemas.

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

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

Gives concrete context on the two caller scenarios (agency vs creator) and the creator_id requirement for each. It does not explicitly name alternatives like social_remove for deletion, but the usage 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, idempotentHint, destructiveHint=false, and closed-world scope, so the safety profile is fully covered. The description's only added behavioral fact is the caller/role requirement, which largely restates the creator_id schema description. No pagination or result-shape context beyond what the annotations and output schema provide.

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, and the primary scope statement leads before the conditional requirement. 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?

For a read-only paginated list with a full output schema and rich annotations, the description supplies the one thing structure does not make obvious: the caller-dependent requirement for creator_id. Nothing essential is missing, though redirecting to sibling tools is a minor 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%: limit, cursor, platform, and creator_id are each documented in the schema including enums and the agency/creator distinction. The description adds no semantics beyond the schema text, 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 (List) and resource (connected social accounts) and scopes it to two caller contexts (authenticated creator vs. agency roster creator). It does not, however, differentiate itself from sibling list/mutation tools such as social_add and social_remove, so an agent must infer the read-vs-write boundary from the name alone.

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 a concrete conditional rule: agency callers must supply creator_id, creator callers omit it. This tells the agent when the tool applies to whom, but names no alternative tool and gives no exclusion for when listing is unnecessary.

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 destructiveness, idempotency, and closed-world scope, so the bar is lower. The description still earns credit by disclosing the non-obvious side effect that the account is also removed from associated media kits, plus the caller-type authorization rule for agency callers.

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

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

Two sentences, front-loaded with the destructive effect and the media-kit cascade before the selection mechanics. Dense but every clause carries information; minor loss for cramming three constraints into one long first sentence.

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?

Covers the target selection modes, the caller-dependent creator_id requirement, and the cascading media-kit effect; an output schema exists so return values need not be explained. Nothing an agent needs to invoke it correctly appears to be missing, though permission/auth details beyond 'agency callers' are not expanded.

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 beyond the schema by framing social_id vs platform+handle_or_url as alternative selection strategies and by stating the agency-only requirement for creator_id, not just repeating field definitions.

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

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

Names a specific verb and resource (remove a linked social account from the authenticated creator or an agency roster creator) and adds the cascade to associated media kits. An agent can distinguish this from social_add and social_list without opening either 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?

Specifies how to select the target (by social_id, or by platform with optional handle_or_url) and states the agency precondition that creator_id is required. It gives clear context but does not contrast itself against siblings such as social_list or social_add, nor state when removal is inappropriate.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds plan-gated authorization context (Creator Max / agency Pro, Scale, Enterprise), which is real behavioral information beyond the annotations; it does not, however, mention rate limits or whether counts vary by plan.

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

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

A single front-loaded sentence stating the returned facets first, then the access prerequisite. Every clause earns its place and nothing is padded.

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 an output schema documenting the returned filter values and counts, annotations covering the safety profile, and zero parameters, the description only needs to convey purpose and access gating — both of which it does. Nothing required for correct invocation is missing.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly introduces no parameter information it doesn't need.

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 (Return) plus specific resource (the valid industries, countries, and categories accepted as Find sponsors search filters) and scope (with directory counts). It is clearly distinguishable from sibling search tools like sponsor_search_brands, which consume these values rather than enumerate 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?

The description states an eligibility prerequisite ('Requires Creator Max or an agency Pro, Scale, or Enterprise plan'), which is useful context, but never says when to call this versus the sibling search tools or that it should be invoked to discover valid filter values before searching. Usage is only implied.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuine context beyond them: a plan/entitlement gate that determines whether the call succeeds at all. It does not describe failure behavior when the plan check fails, but the entitlement disclosure is real added value.

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

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

Two tightly written sentences with zero padding; the what and the payload come first, the prerequisite second. Every clause carries information.

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

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

For a one-parameter read with an output schema, the description covers purpose, payload, and the entitlement prerequisite that an agent could otherwise miss. Only the entitlement-failure behavior and any routing to the search sibling are absent, which is a minor 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 coverage is 100% and the schema itself documents company_id as the brand id from sponsor_search_brands, so the single parameter is fully specified structurally. The description adds nothing about the id format or provenance, 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 and resource ("Return one brand from the Find sponsors directory") and enumerates the payload (description, social URLs, technology list). It contrasts implicitly with search-style siblings via "one brand," though it never names sponsor_search_brands or sponsor_lookup_brand as the alternative it is not.

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: this is the by-id fetch whose id comes from the search tool, and the description adds an entitlement prerequisite (Creator Max / agency Pro, Scale, Enterprise). It gives no explicit when-to-use routing against sponsor_lookup_brand or sponsor_get_contact, which is the main gap.

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 read-only, idempotent, and non-destructive semantics, so the bar is lower; the description adds genuinely new context by stating the plan requirement (Creator Max or agency Pro/Scale/Enterprise) and that the email is conditional on prior reveal. It stops short of describing pagination or auth mechanics, but the plan gating is meaningful operational intelligence.

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: the payload contents lead, followed by the eligibility constraint. No filler, and the most decision-relevant information (returned fields) is front-loaded; the plan sentence is dense but 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?

An output schema exists, so return values need not be restated; the description covers the two things the agent most needs beyond the schema: the entitlement gate and the conditional email state. Minor gaps around rate limits or the reveal hand-off remain, but the definition is complete enough to invoke correctly.

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

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

With a single parameter at 100% schema description coverage, the schema fully documents person_id (pattern plus its origin). The description adds no param-level detail beyond what the schema provides, 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?

States a specific verb and resource ('Return one influencer-marketing contact') and enumerates the returned fields, which distinguishes it from sponsor_search_contacts by scope ('one'). It does not explicitly name the sibling it complements, but the resource is unambiguous.

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

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

Usage is implied rather than stated: the schema note that person_id comes from sponsor_search_contacts and the phrase 'when already revealed' hint at a search-then-get-then-reveal workflow. There is no explicit when-to-use/when-not or direct pointer to sponsor_reveal_email.

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