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

With no annotations, the description carries the full burden and does well: it discloses the nature of the output (plain-English read, states PENDING/APPROVED/REVERSED/TEST_ACTION), mentions the date-window limit, and implies a read-only operation via 'diagnostic' and 'pulls'. It lacks an explicit statement that no data is modified, but the diagnostic framing strongly implies it.

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 four tightly written sentences. It leads with 'PRIMARY diagnostic', packs in the funnel logic, states the output, and mentions optional parameters and the range limit. Every sentence adds value with no redundancy or 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?

Despite having 5 parameters and no output schema, the description covers the tool's purpose, its output nature, the parameters' intent, and key constraints (max 45-day, optional narrowing). It is sufficiently complete for an agent to select and invoke the tool correctly without additional context.

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

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

While the schema already covers all 5 parameters (100% coverage), the description adds meaningful context beyond the schema: it explains the purpose of orderId ('trace a specific test OrderId'), groups campaign/SubId as narrowing options, and highlights the 45-day range constraint that applies to the date parameters. This goes above the baseline of 3.

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

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

The description uses the specific verb 'pulls' and names the resource ('click → action → revenue funnel'), explicitly stating it returns a plain-English diagnosis of why clicks may not produce revenue. It clearly distinguishes itself as 'PRIMARY diagnostic' against sibling tools like list_actions or find_action_by_order, making its purpose 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?

The description clearly identifies when to use this tool (as the PRIMARY diagnostic for a date window when clicks exist but revenue is missing) and provides constraints like the 45-day max range. However, it does not explicitly name alternatives 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?

With no annotations, the description carries the full burden. It discloses the asynchronous nature via 'async ClickExport job' and notes that results arrive after completion, which adds behavioral context. However, it does not mention potential side effects (e.g., creating a job, required permissions, failure modes) or how timeoutMs affects polling, leaving a transparency 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?

The description is two sentences, front-loaded with the primary action and scope, and contains no redundant words. 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?

The tool has an asynchronous job mechanism and no output schema, so the description needs to explain the return format, job lifecycle, and the meaning of the timeout parameter. It only states 'Returns click rows once the export completes,' which is vague and does not clarify how the agent should handle long-running exports or interpret the result. This is insufficient for the tool's complexity.

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?

All four parameters have descriptions in the schema (100% coverage). The description mentions filtering by program/SubId, which aligns with the schema but adds no extra meaning. The timeoutMs parameter is not discussed, but its schema description covers it. Thus the description does not add value 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?

The description begins with a specific verb+resource+scope: 'List clicks for a single day.' It also mentions the async ClickExport job and that it returns click rows, clearly distinguishing it from single-click retrieval tools like get_click and other report exports.

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 for when to use this tool: to export clicks for a specific day with optional filters. It does not explicitly describe when not to use it or name alternatives, but the context is unambiguous enough for an agent to select it for bulk daily click exports.

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 carries the full burden. It discloses the source report (Advanced Action Listing) and what info it returns (Status and reversal reason), but does not explicitly state whether the operation is read-only, whether it requires special permissions, or any potential side effects. The verb 'Trace' implies a safe lookup, but explicit behavioral guarantees are missing.

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 primary purpose and followed by a key differentiation. Every word earns its place, with no filler or redundancy.

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

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

With no output schema, the description explains key return elements (Status, Status Detail/DispositionCode) and the data source, giving a reasonable picture for a lookup tool. However, it does not mention pagination, limits, or whether the result is a single action or list, and it omits the optional date range defaults that are only in the schema. Slightly more detail would make it 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?

Schema description coverage is 100%, so the baseline is 3. The description mentions OrderId in context but does not add details about startDate/endDate formats or defaults beyond what the schema already provides, so it does not significantly enhance parameter understanding.

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

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

The description clearly states a specific verb ('Trace') and resource ('a specific order by its OrderId via the Advanced Action Listing report'), and distinguishes itself from the 'plain Actions endpoint' by emphasizing its unique OrderId filtering capability. This makes the purpose unambiguous and differentiates it from sibling tools like list_actions or get_action.

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 trace a specific order by OrderId, e.g., a test order) and explicitly notes that the plain Actions endpoint cannot filter by OrderId, effectively excluding that alternative. However, it does not explicitly state when not to use it or mention other alternative tools like run_report, so it stops short of a full when/when-not/alternatives guide.

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 and explicitly lists the return fields (name, id, list of REST APIs) and describes the call as the 'smallest', giving a sense of lightweight behavior. It doesn't cover error cases or explicitly state read-only, but for a simple get, this is reasonably transparent.

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: the first states the core function and return values, the second adds practical usage context. Every word earns its place, making it concise and front-loaded.

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

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

For a parameterless account summary tool, the description covers what it returns, why it's useful, and its lightweight nature. No output schema exists, but the enumerated return values (name, id, accessible APIs) are sufficient for an agent to understand the tool's output.

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

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

The tool has zero parameters, so the description doesn't need to add parameter details, warranting the baseline of 4. The description's mention of the 'configured AccountSID' clarifies the implicit configuration dependency without needing schema elaboration.

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 it retrieves the account summary (name, id, and accessible REST APIs) for the configured AccountSID. This is a specific verb+resource, and the context about confirming auth and scoped APIs distinguishes it from sibling tools that focus on campaigns, catalogs, actions, and reports.

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 notes it is the 'smallest call' and useful for confirming auth, the persona prefix, and scoped APIs, which provides clear context for when to use it. It doesn't explicitly mention alternatives or when not to use it, but the guidance is sufficient for a parameterless getter.

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 convey behavior. It lists returned fields and implies a read-only fetch, but does not disclose error behavior (e.g., not found), authentication needs, or any side effects. This is acceptable for a simple getter but lacks detail beyond the field list.

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

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

Single sentence, front-loaded with the verb and resource, and no wasted words. The field list provides necessary detail without bloating the description.

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-entity retrieval, the description is nearly complete. It lists the returned fields, which compensates for the missing output schema. It does not cover error cases, but for this scope the description 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 already documents actionId as 'Action Id' with 100% coverage. The description adds minimal new information ('by its Id' aligns with the schema). Given the high schema coverage, the baseline score 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 retrieves a single Action by its Id, specifying the exact fields returned. This distinguishes it from sibling tools like list_actions (which lists actions) and find_action_by_order (which finds by order).

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 usage is implied: use this when you have an actionId and need full details for one action. However, there is no explicit guidance on when to prefer this over alternatives such as list_actions or find_action_by_order.

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 mentions that the response includes status and resolution, but it does not describe error handling (e.g., behavior when the inquiry ID is not found) or any permission requirements, leaving important behavioral 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 a single, concise sentence with no redundant words or filler. It front-loads the core purpose and remains easy to parse.

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 get-by-id tool with no output schema, the description adequately states the purpose and hints at the return content (status and resolution). It could be slightly more complete by explicitly noting error behavior or what happens if the inquiry is not found, but overall it meets the needs 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?

The input schema fully documents the inquiryId parameter with the description 'Action inquiry Id', and the tool description's phrase 'by its Id' reinforces this. Since schema coverage is 100%, the description adds no substantive meaning beyond the schema, so the baseline of 3 applies.

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

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

The description uses the specific verb 'Get' and clearly identifies the resource as 'a single action inquiry by its Id', which distinguishes it from sibling tools that list or perform other actions. It also highlights the included fields (status, resolution), clarifying the tool's exact scope.

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 this tool is for retrieving one specific inquiry when the ID is known, but it does not explicitly state when to use it versus alternatives like list_action_inquiries or get_action. No exclusions or alternative recommendations are provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only says 'Get details,' which implies a read operation, but it does not mention whether the tool requires authentication, how it handles invalid or missing campaign IDs, or what the return value structure is. For a getter, this is minimal and leaves important behavioral aspects 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?

The description is a single sentence that clearly and directly states the tool's function. It is front-loaded with the verb 'Get' and the resource, and contains no unnecessary words. This is appropriately sized for a simple single-parameter getter.

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

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

Given the tool's simplicity (one required parameter, no output schema, no annotations), the description is minimally viable. It states what the tool does and how to invoke it, but does not elaborate on what 'details' are included, potential limitations, or use cases. While adequate for a straightforward getter, it lacks the richness needed for full contextual completeness.

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

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

Schema description coverage is 100% (the campaignId parameter has a description: 'Campaign/Program Id'). The description adds no new parameter semantics beyond restating that the tool works by CampaignId. Baseline 3 is appropriate since the schema already documents the parameter adequately.

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 purpose: 'Get details for a single program/campaign by its CampaignId.' It specifies the action (get), the resource (details for a single program/campaign), and the key identifier (CampaignId). This distinguishes it from sibling tools like list_campaigns (which lists multiple 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?

No usage guidance is provided. The description does not mention when to use this tool versus alternatives such as list_campaigns or get_action. It implicitly suggests use for a single campaign by ID, but does not explicitly state 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?

With no annotations provided, the description carries the full burden. It discloses the return fields (landing page, referring URL, campaign, device, SubId) and implies the existence-check behavior via 'confirm a specific click was recorded.' It does not cover errors or authentication, but for a simple read operation, it provides meaningful 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 two sentences, front-loaded with the tool's purpose, and contains no filler. Every word adds value.

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

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

The tool is simple (1 param, no output schema), and the description adequately explains what it does, what it returns, and a primary use case. It lacks explicit error behavior, but for this simple get-by-id operation, it is reasonably complete.

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

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

Schema coverage is 100% and the parameter has a clear description ('The click id (irclickid / im_ref)'). The tool description repeats this information without adding new meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Get') and resource ('a single click') with a clear identifier (irclickid / im_ref). It lists the returned fields (landing page, referring URL, campaign, device, SubId), making it distinct from sibling tools like export_clicks or get_action.

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 a clear context: 'Use to confirm a specific click was recorded.' This gives a specific scenario. However, it does not explicitly mention alternatives or when NOT to use it, so it falls short of a full 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, the description carries the full burden. It discloses the behavior of returning available filters and columns and its role as a prerequisite for run_report. While it doesn't explicitly state read-only, 'get metadata' clearly implies a safe read operation. This is sufficient for a simple metadata 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?

The description is two sentences long, front-loaded with the core purpose, and the second sentence adds practical usage guidance. Every word earns its place with no redundancy.

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

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is complete enough. It states what is returned (filters and columns) and when to use it. A slight gap is the lack of an explicit return structure description, but this is minor for a metadata getter.

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

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

The schema already provides 100% coverage with a clear description ('Report Id, e.g. from list_reports'). The tool description adds no additional parameter-specific meaning, so the baseline of 3 for high schema coverage 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 a specific verb+resource: 'Get a report's available filters and columns.' This distinguishes it from siblings like run_report (which executes) and list_reports (which lists reports). The purpose 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?

The description explicitly says to call this before run_report to learn parameter names, providing clear when-to-use guidance. However, it does not mention when not to use it or name alternatives, so it misses the full 'when/when-not/alternatives' criterion for 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, the description carries the burden of disclosing behavioral traits. It explicitly states 'read-only' and 'GET', which signal a non-mutating operation. It also adds context about 'persona-scoped' access. While it doesn't detail response formats or potential rate limits, for a generic read-only escape hatch this is adequate and exceeds the minimum.

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 extremely concise: three short sentences. Each adds essential information: purpose, usage priority, and safety. There is no fluff or repetition, and it is front-loaded with the core purpose.

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

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

Given the tool's simplicity (generic GET endpoint, 3 well-documented parameters, no output schema), the description covers the critical aspects: what it does, when to use it, and that it is read-only. The schema handles parameter details. It could mention that responses are raw API JSON, but for a fallback tool this 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 input schema has 100% coverage of parameters, each with descriptive text (path, query, paginate). The description does not add additional parameter semantics beyond that, but it does set the context of 'persona-scoped' which relates to the path. Per the rubric, with high schema coverage, a 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 a specific verb ('GET'), names the resource ('any persona-scoped Impact endpoint'), and clearly positions itself as a fallback for endpoints not covered by curated tools. This distinguishes it from siblings like list_campaigns and get_campaign, making the purpose immediately 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?

The description explicitly instructs 'Prefer curated tools first' and states the tool is for endpoints 'not covered by a curated tool.' This provides clear when-to-use and when-not-to-use guidance, directly addressing the 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?

With no annotations provided, the description carries the burden of disclosing behavioral traits. The verb 'List' clearly indicates a read-only operation, and 'you've submitted' specifies that results are scoped to the user's own inquiries. This is sufficient for a simple list tool, though pagination behavior is not mentioned.

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 front-loads the verb and resource, with a parenthetical clarifying the term 'action inquiries'. Every word contributes meaning 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 list tool with one optional parameter and no output schema, the description adequately covers the purpose and scope. It could mention return fields or pagination details, but these are reasonably inferable from the resource name and pageSize parameter. It is complete enough for an agent to select and 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?

The single parameter pageSize has 100% schema description coverage, including a default value. The tool description adds no parameter semantics beyond what the schema already provides, so the baseline score 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 clearly states the verb 'List' and the resource 'action inquiries', and defines these as disputes for missing/incorrect/rejected actions. This distinguishes it from sibling tools like list_actions (lists actions) and get_action_inquiry (fetches a single inquiry).

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—use this to list submitted action inquiries—but does not explicitly contrast with alternatives such as get_action_inquiry for detailed views or list_actions for action records. No when/when-not guidance is provided beyond the implied scope.

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 and does so excellently. It discloses the state behavior (including reversed/test orders), the distinction between event-date and last-modified date filters, the 45-day max range, the 7-day default, and the lack of pagination. This is substantial behavioral disclosure beyond typical descriptions.

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

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

The description is concise and well-structured, with four sentences that each add critical details without redundancy. It front-loads the purpose and then packs in behavioral facts efficiently.

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

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

Given the tool has 6 optional parameters and no output schema, this description covers all essential usage aspects: state filtering, two date ranges, range limits, defaults, and pagination absence. It is sufficiently complete for an agent to invoke correctly without needing additional information.

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 description significantly enriches the schema by explaining the semantics of the state parameter (omit to scan all three), clarifying that ActionDateStart/End relate to event dates while StartDate/End relate to last-modified, and adding constraints like the 45-day max and default 7-day window. This goes well beyond what the schema descriptions alone provide.

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 as listing actions (conversions/commissions), and the distinction from sibling tools like get_action or find_action_by_order is clear due to the focus on listing multiple actions. The scope is further clarified by the state-scanning behavior.

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 useful context on when to use this tool, such as the default scanning of all states and the different date filter types. It does not explicitly name alternative tools for single-action retrieval or order-based search, but it does note the absence of pagination, which helps set expectations.

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 full burden. It discloses the listing scope and optional status filter, but omits pagination behavior (pageSize is not mentioned) and does not explicitly state that it is a read-only operation. Some behavioral context is provided, but not comprehensive.

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

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

The description is two sentences with no wasted words. It front-loads the action ('List') and includes the key optional behavior. 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?

Given the simple tool (2 optional params, no output schema), the description covers the core purpose and status filter. However, it omits mention of pagination via pageSize and what fields are returned, leaving some context gaps. It is adequate but not complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful clarification for the status parameter by explaining it filters by Active/Expired, making it more friendly than the schema's 'InsertionOrderStatus filter'. It does not add anything for pageSize, but the added status clarity justifies a 4.

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 'List the programs/campaigns this partner has joined' – a specific verb+resource. It distinguishes itself from sibling tools like get_campaign (singular) and list_catalogs. The optional status filter adds further specificity.

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 context ('this partner has joined') which implies when to use the tool, but it does not explicitly contrast with alternatives like get_campaign or state when not to use it. Usage is implied rather than directly 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?

There are no annotations, so the description carries the full burden. It mentions 'by CatalogId' but does not disclose pagination behavior, default page size, maximum results, error scenarios, or return format. The schema provides pageSize details, but the description itself adds little 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?

The description is a single, concise sentence that front-loads the action ('List items') and resource ('product catalog'). There is no redundancy or waste, making it easy to parse quickly.

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 (2 params, 1 required) with a schema that explains defaults and limits. However, the description omits return value details and pagination explicitly, and there is no output schema. It is adequate for an agent to understand the core purpose, but not fully complete for a list operation with pagination.

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 both parameters (catalogId and pageSize) clearly described in the schema. The description only repeats 'by CatalogId' and adds no extra meaning beyond the schema. Since coverage is high, the baseline score 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 a clear verb-resource structure: 'List items in a product catalog by CatalogId.' It differentiates from siblings like 'list_catalogs' (which lists catalogs, not items). However, it doesn't explicitly say it returns a paginated list or mention any other filters, so it's not fully specific.

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

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

The description provides no guidance on when to use this tool versus alternatives. It implies you need a CatalogId (also noted in the schema), but it doesn't explicitly say 'use after list_catalogs' or contrast with other list tools. No exclusions or alternative references are given.

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 must disclose behavioral traits but only states the basic action. It does not mention pagination behavior, response format, authorization needs, or potential side effects, leaving the agent with minimal understanding of what happens when invoked.

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 is front-loaded with the verb and resource. Every word earns its place, and there is no wasted content.

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 fully specified in the schema, the description is mostly sufficient. However, it could be more complete by indicating what fields are returned or any filtering behavior, though this is not critical for a basic 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?

The schema fully documents the only parameter pageSize (min, max, default), so the baseline is 3. The description adds no additional parameter meaning, but the schema already covers it adequately.

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 'List' and resource 'product catalogs,' with scope 'available to this partner.' This clearly identifies the tool's function and distinguishes it from siblings like list_campaigns and list_catalog_items, which operate on different resources.

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 by naming the resource and scope, but provides no explicit guidance on when to choose this tool over alternatives such as list_catalog_items. The phrase 'available to this partner' gives context but does not mention exclusions 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?

With no annotations, the description carries the full transparency burden. It adds the useful ApiAccessible=true constraint and the relationship to run_report, but it does not disclose whether the list includes all reports or only runnable ones, nor does it mention any output format, pagination, or ordering. This is adequate but leaves 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 main purpose, and includes only the essential additional detail about ApiAccessible. No wasted words.

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

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

For a simple list tool with no parameters and no output schema, the description is fairly complete. It explains what the tool does and the key prerequisite for running reports. It could have mentioned what fields are returned (e.g., report ID, name) or whether the list includes all reports vs. only runnable ones, but given the low complexity, it 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 tool has zero parameters, so the schema already covers everything. The description does not need to explain parameters. Baseline 4 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 lists reports for the Impact.com account, using the specific verb 'List' with the resource 'reports'. It also distinguishes itself from the sibling tool 'run_report' by noting the ApiAccessible=true prerequisite for running reports.

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 by explaining that only reports with ApiAccessible=true can be run via run_report, implying this tool is used to discover available reports and check that flag before running. However, it does not explicitly say 'use this when you need to list reports' or contrast with other list tools beyond run_report.

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 present, so the description bears the full transparency burden. It states that execution is synchronous and that rows are returned, which is useful, but it does not disclose whether the operation is read-only, potential rate limits, timeouts, or pagination behavior. This is adequate but not comprehensive.

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 core action ('Run a report synchronously and return its rows') and then provides essential parameter guidance and date format. No redundant words 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?

Given the variable-parameter nature, lack of output schema, and sibling tools, the description could be more complete. It references get_report_metadata for params and date format, but does not mention run_report_export as an alternative for large results or describe output limitations/pagination. This is a noticeable gap for a synchronous report 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?

The schema already covers both parameters (reportId and params) at 100%, so the baseline is 3. The description adds meaningful context by noting that params vary by report, listing common parameters (StartDate, EndDate, ProgramId/SUBAID), specifying YYYY-MM-DD date format, and referring to get_report_metadata for discovery. This goes beyond what the schema alone 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 uses a specific verb 'Run' with a resource 'report' and the qualifier 'synchronously' while clarifying it returns rows. This distinguishes it from sibling run_report_export, which likely handles asynchronous/batch exports, and from list_reports which lists reports rather than executing 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 explicitly points to get_report_metadata for discovering report parameters, giving a clear alternative/companion tool. It implies the sync use case for direct row retrieval but does not explicitly mention when to prefer run_report_export for larger datasets, so it lacks exclusion 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?

With no annotations provided, the description carries the full burden of disclosure. It transparently explains the async polling behavior and the two expected outcomes (result rows or job URI). However, it does not mention potential errors, rate limits, or whether the operation has side effects like creating a persisted job, leaving some behavioral aspects opaque.

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 consists of three short sentences, each serving a distinct purpose: describing the operation, the use case, and the return behavior. There is no redundant or filler content, making it highly concise 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?

For a tool with no output schema and no annotations, the description covers the essential workflow: starting an async export, polling, and the possible return values. It lacks details on error handling or what happens if the job fails, but given the moderate complexity and the schema covering parameters, it is fairly 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 input schema already provides full descriptions for all 3 parameters, so the baseline is 3. The description adds minimal extra semantics, only indirectly clarifying the timeout parameter by mentioning polling and timeout behavior. It does not add details about the 'params' object or 'reportId' 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?

The description clearly states the tool starts an asynchronous report export with specific formats (CSV/JSON) and polls for readiness. It uses a specific verb-resource pair and distinguishes itself from the synchronous sibling 'run_report' by indicating it is for large reports.

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 a clear usage context with 'Use for large reports,' implying that the synchronous alternative is more appropriate for small reports. It does not explicitly name the alternative tool, but the guidance is sufficient for an agent to decide when to use this tool.

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