mcp

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

Annotations indicate non-destructive write (destructiveHint=false, readOnlyHint=false), but the description adds crucial behavioral detail: 'Never overwrites existing state — fully append-only.' This safety guarantee is valuable context beyond the structured hints.

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 waste: first establishes core action, second lists value propositions/use cases, third provides behavioral guarantee. Information is front-loaded and every sentence earns its place.

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

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

For a 10-parameter mutation tool, the description adequately covers intent, safety semantics, and typical workflows. However, with no output schema provided, it could briefly mention what the tool returns (e.g., confirmation of appended record) to be 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?

With 100% schema description coverage, the schema carries the parameter documentation burden. The description mentions specific record types (progress, snippet, architecture) which adds context for the 'type' parameter, but does not elaborate on parameter syntax, validation rules, or relationships between fields (e.g., completion_pct requiring type=progress).

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 specific verb 'Append' with clear resource 'history record to a task', and enumerates distinct use cases (progress, notes, snippets, architecture documents) that clearly differentiate it from sibling tools like create_task or get_task_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?

States 'This is the primary way to report progress...' establishing it as the standard mechanism for task updates. However, it lacks explicit 'when not to use' guidance (e.g., when to use create_task vs add_task_history) though the 'append' semantics imply existing task requirement.

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

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

Annotations declare idempotentHint=true and destructiveHint=false. The description adds crucial state-machine context that this configuration is 'Required before visitors can authenticate,' clarifying sequencing requirements. No contradictions with annotations; 'Configure' correctly implies the non-read-only nature.

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?

Four sentences with zero redundancy: (1) core purpose, (2) capability enabled, (3) prerequisite status, (4) method selection guide. Information is front-loaded and 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?

Appropriately complete for a 7-parameter configuration tool with no output schema. Covers the 'why' (prerequisite) and key option explanations. Could briefly acknowledge idempotent behavior explicitly, though covered by annotations.

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?

Input schema has 100% description coverage, establishing a baseline of 3. The description adds minor semantic color ('one-click email login') for the methods parameter but does not significantly elaborate on other parameters like allowed_domains or session_ttl_verified beyond the schema definitions.

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

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

States specific action ('Configure visitor authentication'), target resource ('published website'), and mechanism ('email-based login'). The prerequisite statement ('Required before visitors can authenticate') implicitly distinguishes this from sibling get_visitor_auth_config by establishing this as the mandatory setup action versus a read operation.

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 prerequisite guidance ('Required before visitors can authenticate') and explains when to use specific method options ('Use method "link" for one-click...'). Lacks explicit reference to get_visitor_auth_config as the alternative for reading current configuration.

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

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

Annotations indicate this is a mutating, non-idempotent operation (readOnlyHint: false, idempotentHint: false), but the description doesn't warn about duplicate task creation risks. It adds valuable behavioral context that run_once tasks 'deactivate automatically' after execution, but misses other side effects like validation failures or timezone handling implications.

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 efficiently structured sentences: purpose declaration, feature/guidance combo, and actionable reference examples. Zero redundancy. Information density is high with every clause serving either functional definition or practical implementation guidance.

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 7-parameter complexity with nested objects and no output schema, the description adequately covers the scheduling domain mechanics, timezone awareness, and action types. Minor gap: it doesn't address error handling, validation constraints, or the implications of idempotentHint=false (duplicate prevention).

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

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

With 100% schema coverage, the baseline is 3. The description elevates this by providing concrete cron pattern examples ('0 9 * * 1' for Monday 9am) that clarify the 'schedule' parameter syntax, and contextualizes the 'run_once' parameter with specific use cases (publishing pages). This practical guidance exceeds the raw schema definitions.

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

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

The description opens with a clear specific verb ('Create') and resource ('scheduled task'), immediately establishing the tool's function. It distinguishes itself from sibling tools like 'create_task' by emphasizing automatic execution 'at specified times' and cron expression support, making the scheduling domain explicit.

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 specific parameters: 'Use run_once=true for one-time scheduled actions (e.g., publish a page at a specific date/time).' This clearly delineates recurring vs. one-time usage patterns. However, it lacks explicit contrast with sibling 'create_task' (immediate execution vs. scheduled) or reference to 'delete_scheduled_task' for cleanup.

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

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

Annotations indicate this is a non-idempotent write operation (readOnlyHint: false, idempotentHint: false). The description adds practical guidance on slug naming conventions but omits error handling (e.g., duplicate slug behavior), return values, or side effects that would help an agent predict outcomes.

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?

Extremely concise with two efficient sentences. The purpose is front-loaded in the first sentence, and the second sentence provides actionable guidance without verbosity.

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

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

Given the absence of an output schema, the description should ideally specify what the tool returns (e.g., task ID, object) to enable subsequent tool calls. The parameter schema is well-covered, but the operational contract remains incomplete.

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

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

With 100% schema description coverage, the schema already fully documents all 6 parameters including examples. The description reinforces the slug parameter with additional examples but does not add semantic meaning beyond what the structured schema provides.

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

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

The description clearly states the specific action (Create) and resource (task item in the shared task tracker), effectively distinguishing it from siblings like create_record, create_entity, and create_scheduled_task through the 'task tracker' context.

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?

While it establishes the context (shared task tracker), it lacks explicit guidance on when to use this versus create_record or create_entity, and does not mention prerequisites or when not to use the 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?

While annotations declare the operation as destructive and idempotent, the description adds crucial behavioral context not present in structured data: the deletion cascades to 'all its run history'. This warns the agent that this operation destroys associated historical data, a significant side effect beyond just removing the task configuration.

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 single sentence is perfectly front-loaded with the action ('Delete') and contains zero waste. Every phrase earns its place: 'scheduled' differentiates from regular tasks, and 'run history' clarifies the destructive 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 presence of clear annotations (destructive, idempotent) and complete input schema coverage, the description successfully covers the primary behavioral nuance (cascade deletion of history). It appropriately omits return value details since no output schema exists to document.

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

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

With 100% schema description coverage, the schema adequately documents both 'project_id' and 'task_id'. The main description adds no parameter-specific semantics, but given the complete schema coverage, it doesn't need to. Baseline score 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 ('Delete') with a specific resource ('scheduled task') and distinguishes it from sibling tools like 'delete_task' and 'delete_record' by specifying 'scheduled'. It further clarifies scope by mentioning 'run history', which ties to related history-management siblings.

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

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

The description implies usage through the resource type ('scheduled task') and cascade behavior ('run history'), but lacks explicit guidance on when to use this versus 'delete_task' or prerequisites like requiring the task to be inactive. The schema references 'list_scheduled_tasks' for the ID, but this guidance is in the schema rather than the main description.

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?

While annotations declare readOnlyHint=true and idempotentHint=true, the description adds valuable operational context: the output format (Markdown), specific status groupings, inclusion of completion percentages, and temporal scope (recent activity from today and yesterday). It also clarifies the scope is 'all tasks' (unfiltered). No contradictions with annotations.

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

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

Three sentences total with zero waste. Front-loaded with the core output specification (Markdown overview, status groupings, percentages) before usage guidance. Every sentence earns its place—first defines behavior, second adds temporal context, third provides usage scenarios.

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 lacking an output schema, the description adequately compensates by detailing the report structure (grouped by status with percentages) and content (recent activity). Given the tool's simplicity (no parameters, read-only) and the clarity of the described output format, the description provides sufficient context for invocation.

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 contains zero parameters. Per evaluation rules, zero-parameter tools receive a baseline score of 4. The description appropriately requires no parameter explanation since none exist.

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 'Generate[s] a Markdown overview of all tasks grouped by status' with specific groupings (in_progress, blocked, open, done) and completion percentages. This precisely defines the verb (Generate), resource (tasks), format (Markdown), and aggregation logic, effectively distinguishing it from sibling tools like list_tasks or get_task which likely return structured data rather than formatted 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?

Explicitly provides usage context: 'Use this at the start of a session for a quick backlog overview, or to share current status.' This guides the agent toward appropriate scenarios (session initialization, status sharing) versus alternatives like list_tasks (likely for programmatic filtering) or get_task (single-task retrieval). Lacks explicit 'when not to use' guidance.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds value by disclosing return data types (pageview counts, breakdowns, UTM data) which compensate for the missing output schema. Does not mention rate limits, caching behavior, or data retention windows, but meets baseline expectations given strong annotation 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?

Two efficient sentences with zero waste. Front-loaded with the core purpose ('Get visitor analytics'), followed immediately by return value specification, then parameter guidance. Every clause earns its place; no redundancy with schema annotations.

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

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

Given no output schema exists, the description adequately compensates by enumerating expected return values (summary totals vs. breakdowns). With 100% schema coverage and straightforward 3-parameter structure, the description provides sufficient context for correct invocation, though it could explicitly note that project_id refers to an existing monitored project.

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?

Input schema has 100% description coverage with clear enum documentation. The description reinforces the period options and implicitly maps metric enum values to return types (e.g., 'daily trend' for trend metric), but does not add significant semantic depth beyond what the schema and enum names already provide. Baseline 3 is appropriate given schema 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?

States specific verb ('Get') + resource ('visitor analytics') + scope ('for a project'). The return value enumeration (pageview counts, unique visitors, etc.) clearly distinguishes this from sibling 'get_' tools like get_tracking_scripts or get_project_status by specifying it retrieves statistical data rather than configuration or content.

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

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

Provides clear context on valid period values ('today', '7d', '30d', '90d') and maps metric types to expected return data (referrers, devices, etc.). However, it lacks explicit guidance on when NOT to use this versus siblings like get_tracking_scripts or prerequisites like requiring the tracking scripts to be installed first.

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

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

Annotations declare readOnly/idempotent/destructive hints, so description focuses on workflow context and return value content (schema includes endpoints/fields). Adds valuable behavioral context about the two-phase workflow (list → get schema → execute) that annotations don't cover. Minor gap: doesn't specify return format structure (JSON Schema, OpenAPI, etc.).

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 waste: sentence 1 states purpose, sentence 2 defines prerequisite relationship with execute_integration, sentence 3 defines prerequisite relationship with list_integrations. Perfectly front-loaded and information-dense.

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?

Without an output schema, the description adequately explains what gets returned (full schema details). References the correct sibling tools to complete the workflow picture. Minor deduction for not clarifying the schema format type, but sufficient for tool selection and invocation given strong annotations.

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 both parameters (service, project_id) fully documented including examples for service. Description maps 'specific integration' to the service parameter but doesn't add syntax, validation rules, or format details beyond what the schema already provides. Baseline 3 appropriate given schema 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?

Description uses specific verb 'Get' with clear resource 'full schema of a specific integration' and details scope (endpoints, required fields, input parameters). Distinctly positions the tool as integration-specific via references to execute_integration and list_integrations, differentiating it from siblings like get_entity_schema.

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

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

Provides explicit workflow guidance: 'Call this before execute_integration' and prerequisite 'Use list_integrations first'. This clearly defines when to use the tool and the necessary sequencing with sibling tools, including implicit 'when-not-to-use' (don't call execute_integration without consulting this first).

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?

While annotations declare readOnly/idempotent status, the description adds valuable context about response contents: specifically mentioning computed fields (completion percentage) and architecture document versions. This helps the agent understand what data richness to expect beyond a generic task object.

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, dense sentence that front-loads the action and efficiently packs three distinct value-adds: the operation, the computed fields, and the architecture document versions. Zero waste.

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 only one well-documented parameter and comprehensive annotations, the description adequately covers the return value semantics (status, completion percentage, versions) despite no output schema. Could mention idempotency or cache behavior, but sufficient for this complexity level.

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

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

With 100% schema description coverage for the single 'slug' parameter (including helpful examples like 'sapi-fase4'), the schema carries the semantic load. The description doesn't add parameter-specific guidance beyond implying single-item lookup.

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 the verb ('Get') and resource ('single task'), and distinguishes from sibling list_tasks by specifying unique returned fields (computed completion percentage, architecture document versions). However, it doesn't explicitly mention the lookup is 'by slug' though this is implied.

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 term 'single task' implies use for individual retrieval versus listing, but lacks explicit guidance on when to use this versus list_tasks or get_task_history. No mention of error cases (e.g., slug not found).

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

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

Annotations cover safety profile (readOnly, idempotent). Description adds valuable external dependency context (S3 storage for content) and documents the kinds of records returned. Does not disclose ordering (chronological?), pagination behavior, or size limits that would be useful for a history retrieval 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 sentences with zero waste. First sentence front-loads the core purpose and scope; second sentence provides actionable parameter guidance. 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?

Input parameters are fully documented between schema and description. However, lacking an output schema, the description omits what the history object structure looks like (e.g., chronological ordering, timestamp fields, author metadata), which would be necessary for the agent to use the results effectively.

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

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

With 100% schema coverage, baseline is 3. Description adds value by mapping the 'type' filter values to human-readable content types (e.g., 'progress updates' for 'progress') and emphasizing the S3 retrieval behavior for with_content, helping the agent understand the cost/implication of that flag.

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 specific verb ('Get') + resource ('full history of a task') and explicitly lists content types (progress updates, notes, snippets, blockers, architecture documents) to distinguish from sibling get_task (current state) and add_task_history (write operation).

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

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

Provides explicit usage guidance for the with_content parameter ('Use with_content=true to fetch MD content from S3'), indicating when to enable that flag. Lacks explicit contrast with get_task for when to query history versus current state, preventing a 5.

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

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

Annotations already establish read-only, idempotent, non-destructive safety profile. Description adds valuable behavioral context by detailing what data is returned ('whether auth is enabled, which methods are allowed, and the success redirect URL'), compensating for the lack of an output schema. No contradictions with annotations.

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

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

Two sentences with zero waste: first establishes purpose, second previews return value content. Appropriately front-loaded and sized for a single-parameter read tool. Every sentence earns its place by conveying distinct information (action vs. return payload).

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?

Complete for a simple read tool with one required parameter. Good annotations cover safety properties. Absence of output schema is adequately compensated by the description's preview of returned fields (enabled status, methods, redirect URL). No gaps remain for an agent to invoke this tool 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?

Input schema has 100% description coverage for the single 'project_id' parameter. Description mentions 'for a project' which aligns with the parameter but does not add additional semantic details, syntax examples, or validation rules beyond what the schema already provides. Baseline score appropriate 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?

Description uses specific verb 'Get' with clear resource 'visitor auth configuration' and scope 'for a project'. The term 'Get' effectively distinguishes this from sibling 'configure_visitor_auth', indicating this is the read counterpart to the configuration setter.

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 context that this is a read operation ('Get', 'Shows'), implying it retrieves current state rather than modifying it. However, it does not explicitly name 'configure_visitor_auth' as the alternative for modifications or provide explicit when-to-use guidance beyond the implicit getter/setter relationship.

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

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

Annotations cover safety (readOnlyHint, destructiveHint, idempotentHint). The description adds valuable behavioral context by disclosing what data is returned ('status, next run time, and last execution'), compensating for the missing output schema. No contradictions with annotations.

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

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

Single sentence that is front-loaded with the action ('List all scheduled tasks') and efficiently packs in both the filtering scope and return value preview. No redundant 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 low complexity (2 primitive parameters, no nested objects), good annotations, and 100% schema coverage, the description is sufficient. It appropriately compensates for the lack of output schema by listing the key return fields.

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

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

With 100% schema description coverage, the baseline is 3. The description provides minimal additional parameter semantics beyond 'for a project' (mapping to project_id). It does not elaborate on the 'active_only' filtering behavior beyond the schema's own 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 uses a specific verb ('List') with clear resource ('scheduled tasks') and scope ('for a project'). It distinguishes from the sibling 'list_tasks' by specifying 'scheduled tasks' in both name and description, though it lacks explicit contrast with siblings.

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

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

The description implies usage by specifying the resource type ('scheduled tasks'), allowing inference that this is for scheduled automation rather than general tasks (addressed by 'list_tasks'). However, it lacks explicit when-to-use guidance, prerequisites, or named alternatives.

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

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

Annotations already establish read-only, idempotent, non-destructive safety. The description adds valuable behavioral context: the default filtering of snoozed tasks and hints at return values (completion percentage, status). It does not contradict annotations, though it could disclose pagination behavior or rate limits.

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

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

Two sentences with zero waste. First sentence establishes purpose and return data; second sentence delivers critical behavioral context about snoozed tasks. Information is front-loaded and appropriately sized for the tool's complexity.

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 schema (4 flat optional params) and absence of output schema, the description adequately covers the snoozed-filtering quirk and mentions key return fields. It could improve by addressing pagination limits or explicitly contrasting with 'export_tasks', but it is sufficiently complete for invocation.

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

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

With 100% schema description coverage, the schema fully documents all four parameters. The description references 'include_snoozed=true' as an example, reinforcing its usage, but does not add semantic meaning (format constraints, valid ranges) beyond what the schema already provides. 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?

Clearly states the tool lists 'tracked tasks' with specific attributes (completion percentage, status). The verb 'List' and resource 'tasks' are specific. However, it does not explicitly differentiate from sibling 'export_tasks' or 'list_scheduled_tasks', though 'tracked' provides implicit distinction from 'scheduled'.

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 specific behavioral guidance about snoozed tasks being hidden by default and how to reveal them. However, it lacks guidance on when to choose this tool over 'get_task' (singular), 'export_tasks', or 'list_scheduled_tasks', or prerequisites for usage.

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