Social Perks

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

With no annotations, the description carries the burden, and it does disclose a key behavior: the campaign goes live immediately with no separate publish step. It also states the return values. However, it doesn't mention permissions, idempotency, or failure modes, which are important for a mutating operation.

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

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

The description is three concise sentences, each adding value: purpose, return values, and the immediate-launch behavior. No filler or repetition.

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

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

For an 8-parameter tool with no output schema and no annotations, the description explains the essential behavior and return values. The schema covers parameter details, and the 'goes live immediately' note clarifies the lifecycle. It doesn't cover edge cases, but it's sufficiently complete for the core function.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add any additional parameter meaning beyond the schema, nor does it need to since the schema entries are self-explanatory.

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

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

The description clearly states the action ('Create and launch a new campaign') and identifies the resource (a campaign for the calling business). It also mentions return values (id, name, dashboard URL), which further distinguishes it from sibling tools that read or review campaigns.

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

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

The description provides clear context: it is for creating and immediately launching a campaign, which distinguishes it from list/view/review siblings. It doesn't explicitly name alternatives, but the 'goes live immediately' note implies when this tool is appropriate (creation) versus a draft/publish workflow absent here.

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?

No annotations are provided, so the description bears full responsibility for disclosing side effects or constraints. It merely says 'get' without noting read-only semantics, authentication requirements, error behavior, or data source/reliability. The examples of metrics offer slight return-value context but no behavioral depth.

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

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

The description is a single sentence of 14 words, immediately leading with the verb and resource. It is free of filler and every word contributes meaning.

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

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

For a simple lookup tool with one optional parameter and no output schema, the description conveys the essential purpose. However, it does not detail the structure of benchmark results, how metrics are calculated, or edge cases. It is minimally adequate but leaves some gaps.

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

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

Schema coverage is 100%—the businessType parameter already has a description including the 'Omit for the full catalog' behavior. The description text adds no new semantic detail beyond what the schema provides, matching the baseline for full coverage.

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

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

The description clearly identifies the tool's action ('Get') and resource ('industry benchmarks') with concrete examples (engagement rate, conversion rate). This distinguishes it from sibling tools like getCampaignStats, which focuses on campaign-level data, and getPricing, which handles pricing information.

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

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

The description implies usage for retrieving industry benchmarks by business type, but does not explicitly state when to use it over alternative tools or provide any exclusions. It lacks guidance on scenarios such as comparing against campaign stats or when to omit the businessType parameter.

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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It explicitly lists the stats returned (which implies a read-only operation) but does not mention error behavior, permissions, or what happens if the campaign ID is invalid. The lack of a note about side effects or data scope beyond 'single campaign' leaves some gaps.

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

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

The description is two sentences, front-loaded with the purpose and metrics, followed by a brief usage context. Every word adds value, with no redundancy or filler.

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

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

For a simple read-only tool with one parameter, the description adequately captures what the agent needs to know: the purpose, the metrics included, and a typical use case. While there is no output schema, the enumerated metrics give a reasonable expectation of the response content. It is not overly complex, so this level of detail is sufficient.

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

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

The schema has 100% coverage for its single parameter, with the description 'Campaign to fetch stats for.' The tool description reinforces the 'single campaign' scope but adds no additional syntax, format, or constraints beyond what the schema already specifies. Therefore, the baseline of 3 is appropriate.

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

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

The description uses the specific verb 'Get' with a clear resource ('summary stats for a single campaign') and enumerates the exact metrics returned, making the tool's purpose unambiguous. It also distinguishes itself from sibling tools like listCampaigns (which lists campaigns) and getBenchmarks (which likely compares against benchmarks).

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 a clear intended use: 'Useful for an agent reporting back to its user.' This provides context for when the tool is appropriate. However, it does not explicitly mention alternatives or edge cases (e.g., 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?

With no annotations provided, the description must carry the burden of behavioral disclosure. It does mention the return structure ('Returns USD value and recommended perk type/value'), which adds value. However, it does not explicitly state whether the operation is read-only (implied by 'Get'), potential error conditions, or any rate limits. The transparency is adequate but not thorough.

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

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

The description is a single, efficient sentence that clearly states the purpose and output. It is front-loaded and contains no wasted words. Every phrase adds value, making it an example of concise, well-structured documentation.

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

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

The tool is simple (no output schema, 3 optional params), and the description explains what the tool returns, which is essential since no output schema exists. It lacks details on default behavior when parameters are omitted, but that is partially covered by the schema's 'default' hints. Overall, the description is complete enough for a straightforward pricing lookup 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 each parameter has a description in the input schema. The tool description adds no additional meaning about the parameters or their relationships. Per the rubric, the baseline for high schema coverage is 3, which is appropriate here.

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

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

The description clearly states the tool's function: 'Get the market-rate pricing for a marketing action.' It specifies the resource (pricing), the action (market-rate lookup), and the output (USD value and recommended perk). This distinguishes it from sibling tools like getBenchmarks or getCampaignStats, which focus on different data.

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 a clear use case: when you need market-rate pricing for a marketing action. It provides context without explicitly naming alternatives or exclusions. Since no sibling tool offers pricing directly, the intent is clear, but the description doesn't explicitly say when not to use it or mention alternative tools.

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

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

There are no annotations, so the description should disclose behavioral traits. It notes the fixed count of 125 and the filtering capability, which is useful, but it does not mention pagination behavior, authentication, or the shape of the returned data, leaving some behavioral aspects implicit.

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

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

The description is a single sentence that immediately states the primary action and scope, followed by a brief note on filters. No unnecessary detail or repetition exists.

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

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

Given the absence of an output schema and annotations, the description should clarify return values and pagination; it does not explicitly do so. The count of 125 gives a sense of scale, but the tool's pagination parameters remain unexplained in the description, leaving the context incomplete for a simple list operation.

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

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

Schema description coverage is 0%, so the description must compensate. It maps 'platform', 'type', and 'effort' to platformId, type, and maxEffort, adding meaning to those filters. However, it does not describe pagination parameters (page, perPage) or clarify the scale of 'effort,' providing incomplete semantic coverage.

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

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

The description clearly states the tool lists marketing actions, specifies the count (125) and the platform (Social Perks), and mentions filterability. This distinguishes it from sibling list tools like listCampaigns and listSubmissions.

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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or recommended contexts. The purpose is inferred solely from the verb 'list' and the tool name, offering no comparative direction.

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

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

The description discloses two behavioral traits: authentication is required and results are scoped to the caller. Without annotations, this is useful but not comprehensive; no mention of error behavior, pagination, or sorting.

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

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

The description is two short sentences, directly stating purpose and scope, with 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?

For a simple list tool with one optional parameter and no output schema, the description covers the core purpose and auth requirement, but it omits the meaning of the status parameter and any response structure details, leaving notable gaps.

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

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

The input schema has a single 'status' parameter with enum values but no descriptions (0% coverage). The description does not explain the status parameter or its filtering effect, leaving the agent to infer from the enum values alone.

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 'List campaigns' uses a specific verb ('List') and resource ('campaigns'), and adds scope with 'the caller's campaigns,' distinguishing it from sibling tools like listActions and listSubmissions.

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

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

The description provides clear context that authentication is required and the tool returns only the caller's campaigns, implying use for self-owned data. However, it does not explicitly contrast with sibling tools like getCampaignStats or createCampaign.

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?

With no annotations provided, the description carries the full burden of explaining behavior. It discloses that results are paginated and filterable by state, but it does not clarify what happens if businessId/campaignId are both provided or omitted, nor does it mention other behavioral nuances like error handling.

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

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

The description is a single, front-loaded sentence that communicates the core action, scope, filtering, and pagination without unnecessary words. It is efficient and well-structured.

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

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

The description gives the essential details for a basic list operation but lacks deeper context like return shape, default behavior, or constraints on combining filters. Given the tool has multiple optional parameters and no output schema, this is a noticeable gap, though it is not critically incomplete.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for the state and pagination parameters indirectly, but it does not explicitly explain the purpose of businessId or campaignId, nor how they interact. Parameter names help, but the description is insufficient for a low-coverage schema.

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

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

The description clearly states the tool lists submissions for a business or campaign, with a specific verb and resource. It distinguishes itself from siblings like listActions and listCampaigns by focusing on submissions and mentioning filtering and pagination.

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

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

The description provides clear context on when to use this tool (to list submissions) and mentions filtering and pagination. It lacks explicit exclusions or alternatives, but the intended use is obvious enough for an agent to select it appropriately.

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?

With no annotations, the description carries the burden and discloses key side effects: 'Approving releases the perk' and 'rejecting requires a reason.' This gives the agent critical behavioral context beyond the schema, though it doesn't mention other traits like idempotency or finality.

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

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

The description is two concise sentences, front-loaded with the purpose, and includes essential behavioral and usage context without any fluff. 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 3-parameter mutation tool with no output schema, the description covers the purpose, trigger context, and key side effects. It doesn't explain return values or post-conditions, but the most important outcome (perk release) is disclosed, making it sufficiently complete.

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

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

Schema description coverage is 100%, with all parameters including decision's enum and reason's requirements already clearly documented. The description does not add new parameter details beyond reiterating that rejection requires a reason, which is already in the schema, so 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 clearly states the tool's specific verb and resource: 'Approve or reject a submission.' It also distinguishes itself from siblings by noting this is for manual review over auto-verification, and contrasts with submitProof (the prior step).

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 explicit usage context: 'Use this when the business chooses manual review over auto-verification.' This clearly indicates when the tool is appropriate, though it doesn't explicitly name alternative tools or when-not-to-use scenarios, 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?

No annotations are provided, so the description must disclose behavioral traits itself. It only states the basic search function without mentioning what is returned, whether results are filtered or listed, authentication requirements, or any side effects. For a read-only search tool, this lacks important transparency.

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

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

The description is a single, concise sentence that front-loads the action and resource. No filler or redundant information is present.

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

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

The tool has no output schema and no annotations, so the description should provide sufficient context for invocation and expected results. It only states the search criteria, omitting the return format, pagination, or whether it returns a list or single result. The description is too sparse for a tool with no other contextual structure.

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

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

The schema has 0% description coverage, so the description must compensate. It names the two parameters ('platform' and 'follower count') and explains they are search criteria, which adds meaning beyond the bare schema. However, it does not elaborate on expected values, constraints, or inclusivity of 'minFollowers'.

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 ('Search'), names the resource ('influencers'), and specifies the filtering criteria ('by platform and follower count'). This clearly distinguishes it from sibling tools focused on campaigns and submissions.

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

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

The description implies the tool is used for finding influencers based on platform and follower count, but it does not provide explicit when-to-use guidance or mention alternatives among sibling tools. It gives context but no exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context by noting that submissions enter a review queue or auto-approve based on the campaign's verification mode. However, it omits other important behavioral nuances for a write operation, such as whether submissions are editable, idempotent, or require specific authentication/permissions.

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

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

The description is two sentences and immediately states the tool's purpose and the post-submission behavior. Every word earns its place: the proof types are compressed into a parenthetical, and the review-queue behavior is delivered without jargon or 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?

The description covers the core flow (submission, verification, review/auto-approve) despite having no output schema and a moderately complex input schema with a nested metadata object. It does not mention what the response contains (e.g., submission ID or status) or address edge cases like duplicate submissions, but the essential context for invoking the tool is present.

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 input schema already describes all five parameters with 100% coverage, so the baseline is 3. The description adds light value by explicitly linking proof types (screenshot, video, etc.) to the proofType enum and emphasizing that the proofUrl must be public, but these are also partially reflected in the schema. No significant new meaning beyond the schema's own descriptions.

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 starts with a specific verb+resource ('Submit proof of completion for a campaign action') and lists concrete proof types (URL, screenshot, video, platform-verified data). This distinguishes it from siblings like reviewSubmission (for moderating) and listSubmissions (for browsing), and leaves no ambiguity about the tool's function.

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 primary use case clear: when a user has completed a campaign action and needs to submit proof. However, it does not explicitly mention when not to use it or direct users to alternatives (e.g., reviewSubmission for reviewing submissions), so it lacks the explicit exclusionary guidance seen in top-tier examples.

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