Rolli MCP

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

No annotations are provided, so the description carries the full burden. It discloses that the run is marked as failed rather than deleted, which is a behavioral detail. However, it does not mention side effects, reversibility, or required 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 extremely concise with two short sentences, containing no extraneous information. 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?

For a simple tool with one parameter and no output schema, the description covers the essential purpose and effect. It could be improved by mentioning if cancellation is irreversible or requires specific permissions, but it is largely complete.

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

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

The only parameter 'id' is fully described in the input schema as 'Run UUID' (100% coverage). The tool description adds no extra semantic information beyond what the schema provides, so a 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 action ('cancel'), the resource ('Rolli Agent run'), and the effect ('marks as failed'). It distinguishes from sibling tools like 'delete_agent_run' (likely deletes the record) and 'rerun_agent_run' (restarts).

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 when to use the tool (to stop a pending or running run), but provides no explicit guidance on alternatives or when not to use it. No exclusions or context are mentioned.

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 core behavior (recurring schedule with optional notifications) but does not mention side effects such as immediate scheduling, cost/credit implications, or required setup beyond the schema. It is not misleading but omits deeper 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, well-structured sentence that front-loads the action and object, then adds key distinguishing details. No unnecessary words 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?

The tool has 20 parameters and no annotations or output schema, yet the description remains high-level. It does not mention required fields (e.g., name, question), how to configure specific recurrence days, or what the tool returns. The rich schema covers parameter details, but the description itself does not fully orient an agent on the tool's workflow.

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 adds context by linking recurrence types and notification options to related parameters, but it does not go beyond what the schema already documents for individual parameters.

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 explicitly states the action ('Create'), the resource ('recurring Rolli Agent report'), and the key attributes ('cron-like cadence', 'daily, weekly, monthly, or one-time', 'optional email and Slack notifications'). It clearly distinguishes from sibling tools like update_agent_schedule or start_agent_run.

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 creating recurring reports but provides no explicit guidance on when to choose it over related tools (e.g., start_agent_run for immediate runs, update_agent_schedule for edits). No alternatives or exclusions are mentioned.

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?

Description discloses soft-delete nature (record remains, hidden from listings) and preconditions. Without annotations, it covers key behavior but omits reversibility and 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?

Two sentences: first defines action and behavior, second adds usage constraint. Perfectly concise, front-loaded with essential 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?

Covers key aspects: purpose, behavior, usage context. Lacks details on success/failure response and idempotency, but overall adequate for a simple delete 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?

Only one parameter 'id' with schema description 'Run UUID'. Description adds no extra parameter detail beyond schema, but schema coverage is 100%, 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?

Clear action 'soft-delete' on 'Rolli Agent run'. Distinguishes from siblings like cancel_agent_run and list_agent_runs by specifying soft-delete behavior and run status constraints.

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

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

Explicitly states when to use: only on completed or failed runs. Provides actionable instruction to cancel running runs first. Clear guidance against misuse.

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 provided, but description fully covers irreversibility and deletion of execution history, which are critical behavioral traits for a delete 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?

Two sentences: first states purpose and irreversibility, second gives alternative. No wasted words, front-loaded with key 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 simple delete tool with one parameter, description covers purpose, irreversibility, and alternative, making 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 coverage is 100% with one parameter 'id' described as 'Schedule UUID'. Description adds no extra meaning beyond 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?

Description clearly states 'Permanently delete a Rolli Agent schedule and its execution history', specifying verb (delete) and resource (schedule with execution history). It distinguishes from siblings like pause_agent_schedule.

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

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

Explicitly provides alternative: 'Use pause_agent_schedule to temporarily stop a schedule without losing history', guiding when to use this tool vs 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 burden. It discloses that the tool polls until search completion, the meaning of results_pending, the fields returned, and the need to use get_expert_search for pending results. This is substantial behavioral context, though it does not cover error conditions or all possible statuses.

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 at two sentences, with the core purpose front-loaded. Every sentence adds value: the first states the primary function, the second explains async behavior and output format. 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?

Given the tool's simplicity (one parameter) and lack of output schema, the description provides a complete picture of what to expect: the search behavior, the result list fields, and the results_pending edge case. It does not describe the initial poll response structure, but the overall coverage is strong.

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 'query' parameter is well-described as a natural-language description with examples). The tool description adds little beyond repeating that the query is natural-language, so it does not exceed the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose: 'Find experts matching a natural-language query using Rolli's AI-driven recommendation engine.' This is a specific verb (find) and resource (experts) that distinguishes it from siblings like keyword_search and user_search. The scope 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 implies when to use this tool: for natural-language expert searches. It also provides explicit follow-up guidance: 'A status of results_pending means the search succeeded but results are still being written; fetch them with get_expert_search.' However, it does not explicitly contrast with keyword_search or other search variants, leaving some room for ambiguity.

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. It explains the behavior during and after execution. However, it does not mention side effects, authentication needs, or rate limits. For a read operation, this is adequate but could be more 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?

Two sentences: first states purpose, second explains behavior. No unnecessary words, front-loaded. Highly concise and 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 simple tool with 1 parameter and no output schema, the description fully covers what the tool does and what it returns. No missing 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?

Only one parameter 'id' with schema description 'Run UUID'. Schema coverage is 100%, so baseline is 3. The description does not add additional context 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 'Get a Rolli Agent run by ID' and elaborates on what is returned (progress during execution, full results after). It distinguishes from sibling tools like list_agent_runs, cancel_agent_run, etc.

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 explains when to use it (while running vs. after complete) but does not explicitly state when not to use or provide alternatives. It is clear enough for most scenarios.

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 fully discloses the tool's read-only nature and the specific data returned (full configuration and exactly 10 most recent execution records). No contradictions or hidden behaviors.

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 conveying all essential information without redundancy. Front-loaded with the action and scope.

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, read operation), the description fully covers what the agent needs to know. No output schema is needed because the description explains the return content sufficiently.

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 the parameter 'id' described as 'Schedule UUID'. The tool description adds no extra semantics beyond the schema, so a 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?

Description clearly states it retrieves a schedule's full configuration and its 10 most recent execution records. This specific verb+resource combination distinguishes it from sibling tools like list_agent_schedules (which only lists) and get_agent_run (which gets a single run).

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 when both configuration and recent execution records are needed. However, it does not explicitly exclude cases where only one is needed or mention alternatives like list_agent_schedule_runs. Still, the context is clear enough for an AI to differentiate.

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 clearly explains that the tool returns search status and, when complete, an array of recommended experts with profiles and AI summaries, and importantly discloses the async behavior: results_pending: true means the backend is still writing, so retry is needed. This is valuable context beyond the schema, though it omits error handling or 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?

The description is two sentences, front-loaded with the core purpose, and includes essential async retry info without any filler. Every phrase 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 simple single-parameter tool with no output schema, the description adequately explains the return payload (status, expert array, AI summaries) and the results_pending retry scenario. However, it does not cover potential error conditions or what happens with an invalid ID, so it is complete but not exhaustive.

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 fully describes the only parameter 'id' as 'Expert search ID', so the description adds little beyond 'by ID'. With 100% schema coverage, the baseline is 3; no additional semantic nuance or format details are given 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?

The description clearly states the tool retrieves results for an expert search by ID, using a specific verb ('Get') and resource ('expert search results'), which differentiates it from sibling tools for keyword and user searches.

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 used after creating an expert search and having its ID, but it does not explicitly state when to use this tool versus alternatives like list_expert_searches or expert_search. The retry hint for results_pending provides operational guidance but not tool-selection 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. It indicates a read operation via 'get' but does not explicitly state read-only nature, auth requirements, or rate limits. The description is adequate but minimal.

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 clear sentence with no wasted words, front-loading the action and result.

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 parameterless retrieval tool, the description covers the key information. However, the lack of output schema means the agent must infer the return format; mentioning the returned fields helps slightly.

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 are no parameters, so the description does not need to add parameter semantics. Baseline for zero parameters is 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 the tool gets current integration settings and specifies the two fields returned (webhook return URL and integration name), making the purpose specific and distinct from sibling tools like update_integration_setup.

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 when to use (when current settings are needed) but provides no explicit guidance on when not to use or mention of alternatives like update_integration_setup.

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 discloses truncation behavior and how to detect it (truncated: true), explains the meaning and handling of results_pending, and mentions the workaround for complete data. This is thorough and anticipates user needs.

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 sentences, front-loading the core purpose and then adding necessary details about truncation and pending status. There is no wasted text; each sentence provides valuable information. The structure is clear and scannable.

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

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

Given the tool has a single parameter, no output schema, and no annotations, the description covers all essential aspects: return content, truncation behavior, retry conditions, and cross-reference to a related tool. It is complete for the tool's complexity and leaves no critical 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 already describes the only parameter (id) with 100% coverage as 'Keyword search ID.' The description does not add additional semantics beyond this, but it adequately references the ID without needing further explanation. Baseline 3 applies because schema covers the parameter.

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?

Description starts with a specific verb+resource: 'Get results for a keyword search by ID.' It clearly states what is returned (search status, analytics summary, posts) and distinguishes itself from get_keyword_search_posts, which retrieves complete post data. The purpose is unambiguous and well-differentiated from sibling 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?

Provides explicit guidance on when to use this tool (to get results by ID) and when to use the alternative (get_keyword_search_posts) if responses are truncated. It also explains the results_pending state and advises retrying after a few seconds, offering actionable usage context.

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 an important behavioral trait: oversized responses are truncated (truncated: true) and recommends platform filtering for full data. This goes beyond the schema, though it does not cover auth or rate limits. Given the truncation is critical for downstream handling, this is strong 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?

Two concise sentences: the first states the tool's core function, the second adds a crucial warning about truncation and mitigation. No filler, all information 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 simple two-parameter retrieval tool with a complete schema, the description fully covers what the tool does and a key caveat (truncation). No output schema exists, but the return value ('actual social media posts') is clearly stated. The truncation warning and platform-filter tip complete the picture.

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%: both search_id and platform are documented with descriptions, and platform has an enum. The description indirectly references the platform parameter ('request one platform at a time') but adds no new semantic detail beyond the schema. 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 uses a specific verb (Get) and resource (raw posts from a keyword search), clearly differentiating from sibling tools like get_keyword_search (likely metadata) and get_user_search_posts. It explicitly states it returns actual social media posts matching the search query.

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 clear usage context: to fetch raw post data. Includes actionable guidance for handling truncation by requesting one platform at a time. However, it does not explicitly mention alternatives (e.g., when to use get_keyword_search instead), but the context is sufficient for a typical retrieval 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?

With no annotations, the description carries the burden. It clearly indicates a read-only operation and describes the output conceptually, but it does not disclose prerequisites, limitations, or the exact structure of the returned tree. This is adequate but not 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?

The description is two sentences long, front-loaded with the core purpose, and contains no redundant information. 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 read tool with two parameters and no output schema, the description explains the core purpose and output concept ('shows how topics and subtopics are distributed'). However, it could elaborate on the return format (e.g., nested tree with counts) to be fully complete, so it misses the top score.

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% for both parameters, so the schema already documents them. The description adds no parameter-specific details beyond tying the tool to a keyword search, which matches the 'search_id' parameter. 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 action ('Get') and resource ('conversation topic tree'), and adds specificity by explaining it shows topic/subtopic distribution. This distinguishes it from sibling tools like get_keyword_search or get_keyword_search_posts.

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 to view topic hierarchies for a keyword search, but it does not explicitly state when to use it over alternatives or mention exclusions. There is no comparison to other tools, so guidance is only implicit.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explains the return content (search counts, per-user breakdowns, credit fields), including null behavior for one-time credit grants. It also mentions default behavior when month is omitted (last 12 months). It does not cover side effects or rate limits, but for a read-only query tool, this is solid coverage.

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 efficient, using two sentences to convey the core purpose, return details, and parameter behavior. It is front-loaded with the key action and avoids filler, with every sentence providing substantive 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?

Given the simple nature of the tool (single optional parameter, no output schema), the description adequately covers the return payload and parameter behavior. It does not specify exact pagination or error handling, but these are not critical for this use case, and the description 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?

The input schema already documents the 'month' parameter with format, but the description adds meaningful semantics beyond the schema: 'Omit to get the last 12 months' clarifies the default behavior and confirms the parameter is optional. This exceeds the baseline for schema coverage.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Get API usage data'. It enumerates what is returned (search counts, per-user breakdowns, IQ credit balance) and differentiates from sibling tools focused on searches, agent runs, and schedules.

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 for usage/credit inquiries, but it does not explicitly mention when to use it over sibling tools or provide alternatives. It gives contextual details like 'Optionally filter by month' but lacks explicit exclusions or comparisons, so guidance is merely 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains oversized response truncation (truncated: true) and the meaning of results_pending, allowing the agent to handle these conditions appropriately. It doesn't mention auth or rate limits, but for a read operation the disclosed behaviors are sufficient.

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, then immediately covers the two most important caveats (truncation and pending results). No filler words or redundant information; 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 single-parameter read tool with no output schema, the description covers essential context: what the response contains, how to handle truncation, and how to interpret the pending state. It doesn't spell out the exact response structure, but the high-level description is adequate given the tool's simplicity.

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 for the single 'id' parameter, so the baseline is 3. The description only refers to 'by ID' and doesn't add any new semantic detail beyond the schema's 'User search ID' description, which is acceptable given the schema's completeness.

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 opens with a specific verb and resource ('Get results for a user search by ID'), immediately distinguishing it from sibling tools like get_user_search_posts and list_user_searches. It also states the return payload (profile info, metrics, content analysis), making the tool's role clear and 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 points to get_user_search_posts as the alternative when oversized responses are truncated, and provides actionable retry guidance for results_pending. This gives clear when-to-use and when-to-defer context, which is more than most sibling descriptions offer.

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 behavioral disclosure. It usefully discloses that oversized responses are truncated and includes the truncated flag. However, it does not mention whether the operation is read-only (though 'get' implies so), potential failure modes, or any authentication requirements. The truncation detail adds value but other behavioral aspects remain unspecified.

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 purpose and a concise note about truncation. Every sentence contributes value, and there is no redundant or filler text.

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 with one parameter and no output schema. The description states the return type (social media posts) and truncation behavior, but it does not clarify what 'raw posts' entails or the exact response structure. Given the lack of output schema, more detail about the returned data would improve completeness, though the description is adequate for a basic retrieval 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 input schema has full coverage for the single parameter 'search_id' with description 'User search ID.' The tool description does not add extra meaning beyond the schema, so the baseline of 3 is appropriate. The parameter's purpose is fully documented in 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's function: 'Get raw posts from a user search' and elaborates with 'Returns the actual social media posts from the searched user profile.' This provides a specific verb+resource and effectively distinguishes it from sibling tools like get_user_search (likely metadata) and get_keyword_search_posts (keyword variant).

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 defining what the tool does, but it does not explicitly state when to use it over alternatives or provide exclusions. For example, it doesn't contrast with get_user_search or get_keyword_search_posts. The context is clear but limited to the intended operation.

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?

Discloses key behavioral traits beyond basic function: polling until completion, truncation of oversized responses with a truncated flag, and the results_pending status. Since no annotations are provided, this fully covers the operation's side effects and return 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?

Purpose is front-loaded in the first sentence, followed by crucial behavioral notes. The query guidance is lengthy but earns its place by preventing misuse. 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?

Given the complexity of a cross-platform search tool with polling and possible truncation, the description thoroughly sets expectations for return states and directs users to sibling tools for complete data. Adequate even without an 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?

Although the schema covers all parameters, the description significantly enhances the query parameter by explaining token-OR matching, boolean operators (AND, OR, NOT), quoting, and providing a concrete example. This goes far beyond the schema's minimal 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?

Description states a specific verb ('Create') and resource ('keyword/hashtag search') across multiple social media platforms, making the tool's purpose clear. It also distinguishes itself from sibling tools like get_keyword_search and get_keyword_search_posts by clarifying that it creates and polls the search, while those retrieve results.

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 when-to-use guidance: for truncated responses, use get_keyword_search_posts; for results_pending status, use get_keyword_search. Also recommends boolean syntax and focused searches over broad queries, clearly steering usage behavior.

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 provided, so description carries burden. Explicitly states discarded runs are excluded, but lacks details on rate limits, auth needs, or pagination 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?

Three sentences, no redundancy, purpose stated first. Efficient and clear.

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

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

No output schema, but parameters are well-documented. Missing details like return format or total count, but completes basic listing needs.

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 baseline 3. Description adds no additional meaning beyond schema-defined parameters like status, user_id, limit, offset.

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?

Description clearly states it lists Rolli Agent runs, mentions paginated summary, and excludes discarded runs. Distinguishes from siblings like get_agent_run and cancel_agent_run.

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

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

No guidance on when to use this tool versus alternatives like get_agent_run or other list tools. Does not mention prerequisites or 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?

No annotations are provided, and the description only says it returns history and previews. It does not disclose read-only nature, pagination, rate limits, or any side effects.

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 with 16 words, efficient and front-loaded with the core action.

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 three parameters and no output schema, the description mentions 'full execution history' and 'preview' but omits pagination details and return format, making it adequate but not thorough.

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 descriptive parameter names and descriptions. The description adds no extra meaning beyond the schema, earning baseline 3.

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

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

The description clearly states 'List the full execution history of a Rolli Agent schedule', specifying the verb and resource, and distinguishes from siblings like list_agent_runs by focusing on schedule history.

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 viewing execution history but provides no explicit guidance on when to use this vs alternatives like list_agent_runs or list_agent_schedules.

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 provided. The description indicates a read operation via 'List', but does not explicitly state idempotence, no side effects, or other behavioral traits. Minimal disclosure.

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

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

Two sentences, front-loaded with purpose. No extraneous information. Highly concise.

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?

Lacks output schema, but for a simple list tool with well-documented pagination parameters, the description covers essential context. Could mention return format but not critical.

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

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

Schema coverage is 100% and both parameters have clear descriptions in schema. The description adds no additional meaning 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?

The description clearly states the tool lists Rolli Agent scheduled reports and explains their cadence. It distinguishes from sibling tools like list_agent_runs and list_agent_schedule_runs.

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 guidance on when to use this tool versus alternatives like get_agent_schedule or list_agent_schedule_runs. The usage is implied but not 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?

The description mentions pagination and filtering by status, which are key behaviors. But it does not specify ordering, rate limits, or that it is a read-only operation. Without annotations, more detail would improve 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?

Two sentences efficiently convey the core functionality. The description is front-loaded with the action and result, but some details could be added without sacrificing conciseness.

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 optional parameters and no output schema, the description covers the basics. However, it leaves questions about default sorting and what exactly is returned (e.g., full objects vs. summaries).

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 description adds context about filtering by status and pagination. However, it does not elaborate on the 'page' parameter beyond what the schema states.

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

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

The description clearly states it lists expert searches, which distinguishes it from sibling tools like get_expert_search or list_keyword_searches. However, it could be more explicit about the scope (e.g., all searches in the system).

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 or when-not-to-use guidance is provided. It does not differentiate from other list tools like list_keyword_searches, leaving the agent to infer context.

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 correctly implies a read-only operation ('list') and mentions pagination and filtering. It does not disclose default behaviors (e.g., page size) or edge cases, but is adequate for a simple list 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?

Two short sentences with no wasted words. Key purpose is front-loaded ('List all keyword searches'). Perfectly concise.

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 2 parameters and no output schema, the description covers essential functionality (listing, filtering, pagination). It could mention defaults but is largely complete.

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

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

Schema coverage is 100% and both parameters have descriptions. The description adds minimal extra meaning beyond confirming filtering and pagination, 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?

Description explicitly states 'List all keyword searches' with clear verb and resource. It distinguishes from sibling tools like 'get_keyword_search' (single) and other list tools (e.g., 'list_expert_searches') by specifying the resource type.

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?

Description explains paginated and filtered behavior, providing context for when to use. However, it lacks explicit exclusions or mention of alternatives, though the sibling list compensates.

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 full burden. It mentions pagination and filtering but does not disclose any behavioral traits like authorization needs, rate limits, or consequences of invalid parameters. The description is minimal.

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 immediately states the action and resource, then concisely adds the return characteristics. There is no wasted text.

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 low complexity (2 optional params, no output schema), the description covers the basics. However, it lacks details on default behavior for pagination and status, error handling, and the structure of returned data. It is adequate but not comprehensive.

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 clear descriptions for both parameters. The description adds context about pagination and filtering by status, but this is already implied by the schema. It does not provide significant additional 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?

The description uses a specific verb ('List') and resource ('user searches'), and mentions pagination and filtering. It clearly distinguishes from sibling list tools that target different resources (e.g., agent runs, schedules, expert searches).

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 information about when to use this tool versus alternatives such as `get_user_search` for a single search or `user_search` to create one. There is no explicit guidance on context or 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?

No annotations are provided, so the description must carry the full burden. It states the schedule stops executing and history is preserved, but does not clarify whether currently running executions are interrupted or only future ones. This gap reduces 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 concise, consisting of two sentences with no superfluous information. It is front-loaded with the action and resource, making it 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 pause action with one parameter and no output schema, the description is complete. It explains the effect and points to the resume counterpart, providing sufficient 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?

Schema coverage is 100% with a single 'id' parameter described as 'Schedule UUID'. The description adds no additional meaning beyond the schema, so a 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 'Pause' and the resource 'Rolli Agent schedule', explaining that it stops executing and preserves the schedule and history. It also distinguishes itself from the sibling tool 'resume_agent_schedule'.

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 when to use (to stop execution temporarily) and mentions resumption with a specific sibling tool. It does not explicitly state when not to use, but the context is clear enough.

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 fully discloses side effects: resets to pending, re-enqueues, force-cancels running runs first, returns 422 for completed runs, and fails immediately if credit balance is insufficient. This is comprehensive and beyond the basic 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?

Three concise sentences, each adding value. The first sentence states the primary action and target states, the second explains the effect, and the third covers error and prerequisite conditions. 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?

The description covers purpose, behavior, error cases, and prerequisites, making it quite complete for a one-parameter tool. It does not explicitly describe the success return value, but the absence of an output schema reduces the need; the effect is clearly described via 'resets to pending and re-enqueues it'.

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 the single 'id' parameter already described as 'Run UUID'. The description does not add further semantics for this parameter, matching the baseline score of 3. No additional parameter details are needed.

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 (rerun) and the target resource (failed, waiting, or stuck Rolli Agent run). It distinguishes itself from sibling tools like cancel_agent_run and start_agent_run by specifying the applicable run states and the reset/re-enqueue 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?

It explicitly states when the tool is applicable (failed, waiting, or stuck runs) and when it should not be used (completed runs, returns 422). It also mentions prerequisite credit requirements. Although it does not name alternative sibling tools, the clear when-not conditions provide sufficient 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?

No annotations provided, so description carries full burden. Discloses recalculation of next_run_at, which is useful. However, does not specify whether resuming immediately triggers a run, or any other side effects like validation checks.

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

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

Two short, front-loaded sentences with no filler. Every sentence 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?

No output schema, but description does not mention what the tool returns (e.g., updated schedule object). For a simple tool with one parameter, it is mostly complete but missing return information. Also could note that schedule must be paused.

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 a single parameter 'id' described as 'Schedule UUID'. Description adds no extra meaning beyond the schema. Baseline of 3 applies due to high 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?

Description clearly identifies the verb 'Resume', the resource 'paused Rolli Agent schedule', and adds context about next_run_at recalculation. It effectively distinguishes from sibling tools like pause_agent_schedule.

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

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

Implies usage when a paused schedule needs to be resumed, but lacks explicit when-to-use, when-not-to-use, or alternative tool references (e.g., start_agent_run). No guidance on 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, the description fully carries the burden and succeeds: it discloses the immediate failure on insufficient IQ credit, the 2-minute inline poll, the typical 3–5 minute run duration, and the report format (markdown, signals, evidence links, confidence rating). These are non-obvious behavioral traits that the schema would never reveal.

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 with zero filler: the first states the purpose and output; the second covers the credit-failure condition; the third explains polling, the fallback to get_agent_run, and expected duration. Every sentence earns its place, and the most important information is front-loaded.

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

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

Given the tool's complexity (8 params, nested object, async execution) and the absence of an output schema and annotations, the description is remarkably complete. It covers the input type, the processing pipeline, the output structure, the failure mode, the timeout behavior, and the follow-up mechanism—enough for an agent to select, invoke, and correctly interpret the result.

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 only adds that the question is plain-English and mentions searching across platforms, but it does not add meaning beyond what the schema already provides for parameters like mode, max_post, platforms, or available_credits. It neither improves nor harms 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 opens with 'Start a Rolli Agent investigation' and proceeds to detail the full workflow—plans search strategy, queries Rolli IQ, analyzes posts, produces a markdown report with signals and confidence rating. This clearly distinguishes it from sibling search tools like keyword_search and user_search, and from get_agent_run, by framing the agent's autonomous investigation lifecycle.

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 clear context on when to use the tool (for plain-English investigations) and explains polling behavior: it polls up to 2 minutes, and if not finished, returns a run ID and directs the caller to get_agent_run. This is useful guidance, but it does not explicitly contrast with simpler search tools or state when not to use the agent, so it is clear but lacks explicit 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?

No annotations provided. Description only says 'Update' without disclosing side effects, permissions, or response behavior. Agents may need more info on reversibility or auth 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?

Single sentence with front-loaded purpose and immediate constraint. Every word 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?

Adequate for a simple update tool. Missing return value information, but not critical given no output schema. The condition is stated clearly.

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 covers all 3 parameters with descriptions. Description adds 'rename or pin' mapping to label and pinned, but schema already implies those. No significant extra 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?

Clearly states it updates metadata (rename or pin) of a Rolli Agent run. Verb+resource is specific and distinct from siblings like cancel_agent_run or start_agent_run.

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?

Mentions that at least one of pinned or label is required, giving a clear condition. Does not explicitly exclude other uses, but the specificity implies 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.

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

With no annotations provided, the description carries the full burden and discloses two important behaviors: partial update semantics (unspecified fields unchanged) and automatic recalculation of next_run_at when recurrence parameters change. This adds value beyond the schema, though it omits other side effects or prerequisites.

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 action, and contains no redundant information. Every sentence adds meaningful detail.

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 high complexity (18 params, no annotations, no output schema), the description covers the core semantics sufficiently. However, it does not address how to clear optional fields (using null is impossible due to schema), potential validation constraints, or what the response contains, leaving 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?

All 18 parameters already have rich descriptions in the schema, so the baseline is 3. The description adds a hint about recurrence parameters influencing next_run_at, but it does not enumerate which parameters are recurrence-related or provide additional syntax details 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 performs a partial update on a Rolli Agent schedule, using a specific verb and resource. This distinguishes it from sibling tools like create_agent_schedule, delete_agent_schedule, pause_agent_schedule, and resume_agent_schedule.

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 use for modifying specific schedule fields without affecting others, but it does not explicitly reference alternatives or state when not to use this tool. Sibling tools exist for creation, deletion, pausing, and resume, but no direct comparison or exclusion is 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 must fully disclose behavioral traits. It states the tool 'updates' and 'sets,' implying a write operation, but does not clarify whether it overwrites existing values, requires any pre-existing setup, or triggers side effects. The description is honest but minimally informative beyond the basic action.

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 two concise sentences, no redundant words, and directly states the tool's action and parameter purpose. It is efficiently front-loaded and every sentence provides necessary 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?

Given the simple operation (single required parameter, no output schema), the description is mostly complete. It explains that the tool sets a webhook URL for notifications. However, it could improve by noting whether it updates an existing configuration or requires one, and if there are any prerequisites. Sibling tools (e.g., get_integration_setup) imply existence of a setup, but the description itself is slightly thin.

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

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

There is one parameter, return_url, with a schema description: 'URL that will receive webhook notifications when a search completes.' The tool description merely echoes this ('Set the webhook URL that receives notifications when a search completes'), adding no new semantic value. Schema coverage is 100%, 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?

The description clearly states 'Update integration configuration. Set the webhook URL that receives notifications when a search completes,' which precisely identifies the tool's purpose (update) and resource (integration setup/webhook URL). It distinguishes from sibling tools like get_integration_setup that only retrieve.

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 implicitly indicates when to use this tool (when you need to set or update the webhook URL for search completion notifications). It does not explicitly state when not to use it or mention alternatives, but the purpose is clear enough for an AI agent to decide.

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 well. It discloses polling until completion, response truncation with the truncated: true indicator, and the results_pending status meaning results are still being written. These are meaningful behavioral traits beyond what the schema conveys.

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

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

The description is four sentences, each serving a purpose: stating the action, describing the polling behavior, noting truncation, and explaining results_pending. It is somewhat lengthy but well-structured and front-loaded with the core action.

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 moderate complexity (async search, possible truncation, pending status) and the absence of annotations and output schema, the description is quite complete. It explains key behaviors and points to sibling tools for resolution of special states, leaving no major gaps for an agent to infer.

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 descriptions cover all four parameters (100% coverage), so the baseline is 3. The description does not add parameter-level detail beyond what the schema already provides; it only references social media platform and the overall action.

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?

Description opens with 'Create a user profile search on a social media platform', a specific verb+resource statement. It clarifies the polling and result-return behavior, and contrasts with sibling tools like get_user_search and get_user_search_posts which are referenced for follow-up actions.

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 guidance for two edge cases: truncated responses should use get_user_search_posts, and results_pending status should be followed up with get_user_search. This gives clear alternatives for specific outcomes, though it does not broadly contrast with other search initiation tools like keyword_search.

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