Servicialo MCP Server

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

With no annotations provided, description carries full disclosure burden effectively. Reveals auto-assignment logic (single provider auto-assignment), default discoverability state ('Auto-discoverable by default'), and blocking side effects. Includes auth requirement ('Requires X-Org-Api-Key header'). Missing only error handling or rate limit details.

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?

Perfectly structured with front-loaded purpose, followed by workflow sequence, behavioral constraints, and auth requirements. No redundant words; every sentence conveys distinct operational intelligence. Dense but 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?

Adequately covers the multi-step workflow context and tool relationships, but insufficient for the parameter complexity (8 params, 0% schema coverage). With no output schema, the description should ideally explain what successful creation returns or validation rules, which it omits.

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 has 0% description coverage, so description must compensate but fails to document most parameters. Mentions 'X-Org-Api-Key' (likely mapping to 'apiKey' param) but provides no semantics for required fields like 'orgSlug', 'duration_minutes', 'vertical', or 'currency'. Does not clarify that 'apiKey' appears to be a header despite being in the body 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?

Opens with specific verb-resource combination ('Add a bookable service to an organization') and distinguishes from sibling 'service_create' by embedding this in the explicit admin workflow ('Use after admin_create_organization'). Clearly identifies the domain and scope.

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

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

Provides explicit prerequisites ('Use after admin_create_organization'), post-requisites ('Next step: admin_set_availability'), and clear conditional logic for when to use sibling tool 'service_assign_provider' ('With multiple providers...'). Also warns about blocking conditions ('unassigned services block admin_toggle_discoverable').

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 successfully discloses auth requirements ('Requires X-Org-Api-Key header') and data behavior ('org owner is auto-provisioned as a provider'), but lacks details on pagination, rate limits, or return structure.

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 waste: purpose (sentence 1), usage guideline (sentence 2), behavioral context (sentence 3), and auth requirement (sentence 4). 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 2-parameter list tool without output schema, the description adequately covers invocation prerequisites and mentions providerId as a key return field. However, it could briefly describe the return structure (e.g., array of provider objects) to fully compensate for missing output schema.

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

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

Schema description coverage is 0%, requiring the description to compensate. It implicitly maps 'X-Org-Api-Key header' to the apiKey parameter and 'organization' to orgSlug, but does not explicitly document parameter formats, validation rules, or where to obtain the orgSlug value.

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

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

The description opens with a specific verb ('List') + resource ('providers/professionals') + scope ('active', 'for an organization'), clearly distinguishing it from sibling tools like provider_get (single record) or provider_create (mutation).

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 the tool ('Use this to get providerId before calling admin_set_availability'), providing clear workflow sequencing and directly referencing the sibling tool that depends on this data.

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 destructive overwrite behavior, authentication requirements, and workflow dependencies. Minor deduction for not describing return values or error states on failure.

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 waste. Front-loaded with critical destructive warning. Each sentence delivers distinct value: purpose/warning, prerequisite, format specification, and authentication. No redundant content.

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

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

For a destructive admin operation with 4 parameters, no annotations, and no output schema, the description covers purpose, prerequisites, destructive nature, and parameter formats effectively. Lacks only return value description and error handling guidance.

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 has 0% description coverage. Description compensates partially: explains providerId source, schedule format ('day names and HH:MM times'), and implies apiKey maps to X-Org-Api-Key header. However, orgSlug is undocumented and apiKey parameter semantics remain ambiguous.

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 ('Replace') + resource ('weekly availability schedule') + target ('provider'). The parenthetical 'not additive — overwrites all existing blocks' clearly distinguishes this from additive update tools and the sibling getter availability_get_provider_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?

Explicit prerequisites ('Get providerId from admin_list_providers first'), destructive behavior warning ('overwrites all existing blocks'), and auth requirement ('Requires X-Org-Api-Key header'). Clearly indicates when to use (full replacement) vs. when not to (additive changes).

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 delivers: it discloses the retry requirement ('first call...may return registry_updated: false — call again to confirm'), mentions the specific auth header needed (X-Org-Api-Key), and hints at return value structure.

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 well-structured sentences with zero waste: purpose statement, usage timing, behavioral quirk with retry logic, and auth requirement. 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?

Despite no output schema and zero parameter descriptions in the schema, the description captures the critical implementation details (retry behavior, auth header) and workflow context needed to use this toggle effectively after organization creation.

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

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

Schema description coverage is 0%, requiring the description to compensate. While it conceptually explains the operation (publishing/unpublishing an org), it does not explicitly map these concepts to the parameter names (orgSlug, discoverable, apiKey) or explain that discoverable=true means publish.

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 specific verbs (Publish/unpublish) and clear resource scope (organization in the Servicialo global registry), distinguishing it from sibling admin tools that handle creation or configuration rather than visibility toggling.

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 'Use as the last step after configuring services and availability' establishing clear workflow sequencing. Also references admin_create_organization in the retry note, implicitly guiding the agent on tool ordering.

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 successfully discloses key behavioral traits: it creates a public URL at a specific path pattern (/{orgSlug}/agenda/{slug}), has dependencies on pre-existing configuration (services/availability), and enables self-service booking. It does not mention error handling, idempotency, or rate limits, preventing a perfect score.

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 waste. It front-loads the core definition, followed by URL structure, prerequisites, and usage comparison. Every sentence provides distinct, non-redundant information that aids tool selection.

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 high complexity (9 parameters, 0% schema coverage, no annotations, no output schema), the description adequately explains the business concept and workflow integration but has clear gaps in parameter documentation. It successfully explains 'what' and 'when' but not 'how' regarding the parameter interface.

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

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

Schema description coverage is 0%, requiring the description to compensate significantly. While it references orgSlug and slug via the URL path example and implies proveedorId through 'Links to a specific provider,' six other parameters (title, apiKey, isActive, isPublic, description, allowComments) remain completely undocumented. This falls short of adequately compensating for the schema gap.

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 defines the tool as creating 'a public agenda — a shareable booking page where external clients can self-book appointments,' using a specific verb and resource. It clearly distinguishes this from sibling tools by contrasting it with API/dashboard booking methods and linking to provider/service entities created by other 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 prerequisites ('Create this after services and availability are configured') and clear alternative pathways ('Without a public agenda, clients can only be booked via the API or dashboard'). This directly guides the agent on when to use this tool versus booking_create or admin dashboard functions.

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. Excellently discloses cascade effects ('related sessions... comments... service configs'), validation logic ('confirm: true'), and irreversibility. Zero contradiction with implied destructive 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?

Three sentences with zero waste: action/scope, cascade effects, and confirmation/irreversibility. Critical safety information (cascades, confirmation) is front-loaded appropriately for a destructive operation.

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

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

For a destructive 4-parameter tool with no output schema and zero annotation coverage, description covers essential domain logic (cascading deletes, confirmation gate, permanence). Could improve by indicating success/failure response patterns.

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 has 0% description coverage. Description compensates partially by explaining the 'confirm' parameter's validation requirement ('Requires confirm: true'), but does not clarify orgSlug, agendaId, or apiKey semantics. Baseline compensation for critical 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 opens with specific verb 'Delete' + resource 'public agenda' + scope 'permanently', clearly distinguishing from sibling tools agendas_create, agendas_get, agendas_list, and agendas_update.

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

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

States explicit prerequisite 'Requires confirm: true' and warns 'Cannot be undone', guiding safe usage. Lacks explicit naming of alternatives (e.g., agendas_update for modifications) but irreversibility warning strongly implies caution criteria.

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 and no output schema, the description comprehensively discloses return content: booking flow types (service_first, provider_first, auto), booking policies (advance, same-day, on-demand), cancellation policies, privacy settings, and session count. Also clarifies this operates on 'public' agendas, disclosing access scope.

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

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

Front-loaded purpose statement followed by comprehensive return value enumeration and usage guideline. The second sentence is lengthy but every clause documents a specific configuration field that would otherwise be unknown without an output schema. 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?

Given the complex agenda domain (multiple sibling tools) and absence of output schema, the description admirably documents the complete return payload structure. However, the lack of parameter semantics for orgSlug and apiKey (with 0% schema coverage) leaves a documentation gap for required inputs.

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 has 0% description coverage. Description mentions 'by ID' implying agendaId, and 'public agenda' hints at orgSlug context, but provides no explanation for apiKey (the third parameter). With zero schema coverage, the description only partially compensates for missing parameter documentation.

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 ('agenda') + scope ('complete details...by ID'). Explicitly distinguishes from sibling agendas_update by stating this should be used 'before agendas_update to inspect current settings', clarifying the read vs. write relationship.

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

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

Provides explicit when-to-use guidance ('Use before agendas_update to inspect current settings'), establishing the prerequisite relationship with the update tool. Lacks explicit 'when not to use' exclusions, though the sibling contrast is 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. It successfully discloses return payload structure ('provider, service, and session counts'), but fails to mention safety profile (read-only vs mutation), pagination behavior, or error scenarios. The term 'public' hints at filtering logic but isn't elaborated.

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 optimally concise with two sentences and zero redundancy. The first sentence establishes the operation, and the second adds value by previewing the return structure without wasting 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 lack of output schema and annotations, the description partially compensates by describing return fields. However, it omits pagination details, authentication requirements for the apiKey parameter, and the distinction between public and private agendas, leaving operational gaps.

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

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

Schema description coverage is 0%, requiring the description to compensate fully. While 'for an organization' implicitly clarifies the 'orgSlug' parameter, the 'apiKey' parameter is completely undocumented in the text, leaving critical authentication semantics unexplained.

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 ('List'), resource ('public agendas'), and scope ('for an organization'). However, it does not explicitly differentiate from the sibling 'agendas_create' tool or clarify what makes an agenda 'public' versus private/internal.

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 is provided on when to use this tool versus alternatives like 'agendas_create' or other listing tools. There are no prerequisites mentioned (e.g., needing the orgSlug beforehand) 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 carries full disclosure burden. It successfully explains the partial update semantics and the auto-linking side effect when providers are assigned. However, it lacks disclosure of error behavior, authorization requirements, or what happens if the agendaId doesn't exist.

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?

Front-loaded with purpose and partial-update warning. The long enumerated list of configurable fields is information-dense and justified given the 0% schema coverage and 32 parameters. No wasted words, though necessarily lengthy. Structure flows from general behavior to specific field categories to side effects.

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 complex 32-parameter mutation tool with no output schema, the description covers the domain logic thoroughly (booking flows, cancellation policies, assignment strategies). It explains the partial update contract and auto-linking behavior. Only missing generic operational details like error states or return value structure.

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

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

With 0% schema description coverage and 32 parameters, the description compensates well by categorizing parameters (visibility, booking flow order, selection modes, assignment strategy, etc.) and listing valid enum values for complex fields. It misses documenting some parameters (slug, apiKey, category, expiresAt, allowComments, defaultDurations, allowGroupSelection, cancellation penalty specifics), but covers the majority of business-logic-critical fields.

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 'Update a public agenda's configuration' providing a specific verb (update) and resource (agenda configuration). It clearly distinguishes from siblings (agendas_create, agendas_delete, agendas_get) through the update verb and by specifying this handles existing agenda configuration changes.

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 'Partial update — only provided fields are changed' which is critical usage guidance for PATCH-like semantics. Also notes the side effect that 'When a provider is assigned, their services are auto-linked.' Missing explicit guidance on when to use vs. agendas_create, but the partial update instruction provides clear behavioral 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?

No annotations provided, so description carries full burden. It successfully clarifies this returns persistent configuration data (base weekly schedule) rather than computed availability. However, lacks details on authentication requirements (despite apiKey param), rate limits, or whether the schedule is returned as time blocks or rules.

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

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

Two tightly constructed sentences with zero waste. Front-loads the core operation, immediately clarifies the scope distinction (not free slots), and ends with the mutating counterpart reference. 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?

For a read operation with 3 simple parameters and no output schema, the description successfully explains the conceptual model (configuration vs computed slots) and operational context. Could improve by noting the required org/provider hierarchy explicitly, but adequately covers the tool's function given its 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?

Schema has 0% description coverage requiring description to compensate. Description implies 'provider' maps to providerId and organizational context to orgSlug, but does not explicitly document any parameters or the apiKey authentication mechanism. Provides minimal semantic context for the arguments.

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?

Excellent specificity: states 'Get the configured weekly availability schedule' (verb + resource), explicitly distinguishes from sibling 'availability_get_slots' by clarifying 'not free slots, but the base configuration', and identifies the target entity (provider).

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 alternative 'Use admin_set_availability to modify' clarifying this tool is read-only relative to its mutating sibling. The 'not free slots' caveat helps guide selection vs 'availability_get_slots', though could more explicitly state when to prefer each.

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 delivers substantial behavioral context: it discloses the 'Agenda-aware' filtering logic, explains that modes 1-3 hide provider details while others expose them, and notes that providers are auto-assigned in mode 1. Missing minor details on rate limits or error states.

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

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

Information-dense yet well-structured: front-loaded with core purpose, followed by agenda logic, enumerated modes (1-5), and closing usage hint. Every sentence earns its place; no redundant text despite covering complex multi-mode behavior.

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

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

For a tool with 11 parameters, zero schema coverage, and no output schema, the description adequately covers the primary business logic through the five modes. However, it lacks description of the return format (what constitutes a 'slot' object) or error handling, which would be necessary for complete agent autonomy.

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?

Given 0% schema description coverage across 11 parameters, the description compensates effectively by explaining the five operational modes which map to parameter combinations (orgSlug, clientId, agendaId, serviceId, providerId). It implies date range usage but omits specifics on apiKey, timezone, duration, and the distinction between 'date' vs 'dateFrom/dateTo' fields.

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-object ('Query available time slots') and immediately qualifies the scope ('within a date range'). It distinguishes this tool from siblings by detailing its unique 'Agenda-aware' logic and five distinct operational modes, clearly differentiating it from booking_create (mentioned as a follow-up step) and availability_get_provider_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?

Provides explicit sequencing guidance ('Use before booking_create') and detailed parameter-combination logic through the five modes. However, it lacks explicit contrast with the sibling tool 'availability_get_provider_schedule' or guidance on when to prefer one over the other, and omits prerequisite warnings (e.g., apiKey requirements).

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

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

With no annotations provided, the description carries the full burden. It discloses important behavioral traits: the optional application of cancellation policy charges (financial side effect) and the confirmation requirement (safety mechanism). However, it omits whether the action is reversible, what notifications are triggered, or the exact consequence to the session record.

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

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

The description consists of three short, front-loaded sentences with zero redundancy. Each sentence conveys distinct, essential information (action, optional charges, confirmation requirement) without filler.

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

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

For a destructive operation with 7 undocumented parameters and no output schema, the description covers the minimum (action, safety confirmation, policy option) but leaves significant gaps. It fails to explain the 'cancelledBy' enum semantics, the purpose of the 'reason' field, or what success/failure looks like.

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?

Given 0% schema description coverage across 7 parameters, the description inadequately compensates. It explicitly references 'confirm' and 'applyCancellationPolicy' (2 parameters) and implies 'sessionId', but provides no context for critical required fields like 'reason', 'orgSlug', the 'cancelledBy' enum values, or 'apiKey'.

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 core action ('Cancel an existing session') with a specific verb and resource. It distinguishes this from creation-focused siblings like booking_create, though it doesn't explicitly clarify the difference between this and booking_update_status.

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 one critical usage constraint ('Requires confirm: true'), which acts as a safety check. However, it lacks explicit guidance on when to use this tool versus booking_update_status or prerequisites like authentication requirements.

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, description carries full burden and adds substantial context: auto-assignment strategies (round_robin, least_booked), titular provider preference logic, default agenda fallbacks, and strict preconditions. Minor gap: doesn't explicitly confirm destructive nature or idempotency behavior despite idempotencyKey parameter.

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 dense sentences with zero waste: purpose front-loaded, followed by provider assignment logic, agenda fallback rules, and preconditions/workflow. No redundant phrasing despite covering complex conditional logic.

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 high complexity (11 params, 0% schema coverage, no annotations) and lack of output schema, description thoroughly covers input validation logic and workflow integration. Minor deduction for not describing return values or success confirmation, which would be helpful 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?

Schema has 0% description coverage. Description compensates for critical business logic parameters (providerId, publicAgendaId, clientId, serviceId) explaining optional vs required behaviors and system defaults. However, leaves 6 parameters (apiKey, orgSlug, duration, notes, idempotencyKey, modalidad) completely undocumented, creating gaps for auth, timing, and retry semantics.

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?

Opens with specific verb-resource pair ('Create a new session/appointment') and clearly distinguishes from sibling tools by describing singular booking creation (vs. booking_create_recurring) and referencing the booking lifecycle (cancel, reschedule) via workflow guidance.

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 names prerequisite tools ('use client_create first', 'service must exist') and specifies the correct sibling to call beforehand ('Use availability_get_slots to find valid time slots before calling this'), providing clear when-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?

With no annotations provided, the description carries the full disclosure burden. It effectively communicates that the tool 'Generates multiple individual sessions linked by a recurrence series ID' (critical behavioral trait) and discloses the 'Max 52 occurrences' constraint. It misses idempotency and conflict handling details, but covers the essential mutation 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?

The three-sentence structure is perfectly efficient with zero waste: sentence one defines purpose with example, sentence two explains the key behavioral mechanism (series ID generation), and sentence three states the critical constraint. 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 complex tool with 10 parameters, 0% schema coverage, nested recurrence objects, and no output schema, the description is insufficient. It explains the recurrence concept but omits documentation for the majority of parameters, return structure, and conflict resolution behavior (despite 'skipConflicts' existing in the schema).

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

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

Given 0% schema description coverage and 10 parameters including complex nested objects (recurrence), the description fails to compensate adequately. While it mentions the 52-occurrence limit (mapping to endCondition.count), it provides no semantics for required fields like 'confirm', 'orgSlug', 'clientId', 'providerId', or 'skipConflicts', leaving most parameters undocumented.

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 recurring sessions') and resource, with the parenthetical example '(e.g. weekly therapy)' effectively distinguishing it from the sibling tool 'booking_create' which handles single sessions. It specifies the key differentiator: generating multiple linked sessions.

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 the description implies usage through the 'recurring' qualifier and 'weekly therapy' example, it lacks explicit guidance on when to select this tool versus the sibling 'booking_create' for single sessions. No prerequisites or exclusion criteria 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 provided, the description carries the full burden. It adds valuable context by enumerating return data categories (client, provider, service, financial, delivery proof), which compensates partially for the missing output schema. However, it lacks disclosure of safety traits (read-only status), error behaviors, 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?

Single, efficiently structured sentence that front-loads the action ('Get complete details') and appends specific return value categories without waste. Every clause earns its place by distinguishing scope or content.

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

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

Given the tool's moderate complexity (3 params, no nested objects) and lack of annotations/output schema, the description adequately covers the return payload composition but remains incomplete regarding parameter documentation and operational safety characteristics.

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

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

Schema description coverage is 0%, requiring the description to compensate. It only implicitly references sessionId via 'by its ID', but provides no semantics for required parameter orgSlug or optional apiKey, leaving critical parameters undocumented.

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 'complete details of a session/appointment by its ID', using a specific verb and resource. It distinguishes from siblings like booking_list (which lacks ID filtering) and client_get/provider_get (different resources), though it doesn't explicitly contrast with other booking operations.

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 (e.g., 'use booking_list if you don't have the session ID'). No prerequisites or conditions are mentioned, leaving the agent to infer usage from the parameter schema alone.

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

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

No annotations provided, so description carries full burden. It discloses cursor-based pagination behavior, which is valuable. However, it fails to clarify read-only safety, rate limits, return value structure, or what occurs when filters are omitted (e.g., returns all sessions vs. error).

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

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

Two sentences with zero waste. Front-loaded with core functionality (listing sessions with filters) followed by pagination support. 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 basic listing tool but incomplete given the complexity (11 parameters, no output schema). Covers primary filtering and pagination but lacks required parameter emphasis, return value description, and error conditions expected for a query tool with numerous filter combinations.

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 0% schema description coverage, the description partially compensates by enumerating the filterable fields (provider, client, service, status, date range). However, it omits semantics for 5 other parameters including the required 'orgSlug', 'apiKey' (authentication), 'cursor' (pagination mechanics), 'limit', and 'orderBy'.

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

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

Clear verb ('List') and resource ('sessions'), with explicit mention of available filters. However, it does not explicitly distinguish from sibling 'booking_get' (single retrieval vs. list) or clarify when to use this versus other booking 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?

No explicit guidance on when to use this tool versus alternatives like 'booking_get' for single-record retrieval. Does not mention prerequisites like the required 'orgSlug' parameter or authentication requirements despite 'apiKey' being present in the schema.

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

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

With no annotations, description carries full burden and successfully discloses the destructive-composite behavior (cancel+create rather than true update) and confirmation requirement. Could improve by mentioning idempotency or error scenarios.

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 well-structured sentences with zero waste: purpose (sentence 1), mechanism (sentence 2), and constraint (sentence 3). Information is front-loaded appropriately.

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 basic invocation given the complexity of 7 parameters and mutation behavior, but gaps remain in parameter documentation and expected return value given no output schema exists.

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 0% schema coverage, description must compensate for 7 parameters but only implicitly covers newScheduledAt ('new time') and explicitly covers confirm. Critical parameters like orgSlug, sessionId, and newProviderId remain undocumented.

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 (reschedule) and resource (session), and distinguishes from siblings by explaining the composite nature (cancels original + creates new) versus simple updates or cancellations.

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 the critical safety constraint 'Requires confirm: true', but lacks explicit guidance on when to use this versus booking_update_status or booking_cancel (e.g., time changes vs status changes).

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

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

With no annotations provided, the description carries the full burden. It discloses the lifecycle nature and valid state transitions, implying a state machine. However, it omits mutation safety details, error handling for invalid transitions, and whether operations are idempotent or reversible.

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 zero waste. Front-loaded with the core verb ('Advance'), followed by scope ('Servicialo lifecycle'), and specific enumerated actions. 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?

Insufficient for a state machine tool with conditional parameters (noShowType/deliveryType dependent on action) and no output schema or annotations. Missing: return value description, conditional parameter logic, and error states for invalid transitions.

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 0%, requiring heavy description compensation. While it explains the action enum values (confirm, start, etc.), it completely ignores six other parameters including critical conditional fields like noShowType and deliveryType, failing to explain they are required only for specific actions.

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 advances a session through the Servicialo lifecycle with specific verbs (confirm, start, complete, deliver, no-show). It effectively distinguishes from sibling tools like booking_cancel and booking_reschedule by focusing on state progression rather than termination or time modification.

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?

Lists the five valid lifecycle actions explicitly, providing clear context for when to use this tool (state transitions). However, it lacks explicit exclusions or guidance on when to use booking_cancel versus the no_show action, or prerequisites for valid state transitions.

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 critical side effect ('Freezes the period') and prerequisite check, but lacks error behavior or idempotency details given no annotations provided.

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

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

Three tight sentences with zero redundancy; front-loaded with action, followed by prerequisite and side effect.

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 basic invocation but lacks workflow context (relationship to cierre_evaluar_org) and error state details for a destructive/freezing operation.

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

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

Schema has 0% description coverage and the description fails to explain parameter semantics, formats, or relationships (e.g., what 'periodo' format is expected).

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

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

Specific verb ('Close') and resource ('organizational period') clearly stated; distinguishes from sibling client-level cierre_* 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?

Explicitly states hard prerequisite (ALL active clients with historialCompleto=true must be closed first) and implies this is a finalizing action.

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 immutability and uniqueness constraints (one per client per period) which are critical behavioral traits; no annotations exist to contradict

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 high-value sentences with zero fluff; front-loaded with the action verb and critical immutability property

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 business logic well but lacks return value description (no output schema exists) and detailed parameter semantics needed given empty 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?

With 0% schema coverage, description only partially compensates by implying periodo defines the time period; fails to explain orgSlug, notas, or expected periodo format

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?

Explicitly states it creates a client monthly closing (specific verb+resource), distinguishes from org-level siblings (cierre_cerrar_org) and other operations via 'immutable financial snapshot'

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 prerequisite (historialCompleto=true) and constraint (one per period), but doesn't mention cierre_preview_cliente as alternative for checking existing closings

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 critical side effect (freezes current and prior periods) and confirmation requirement; no annotations exist to contradict.

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, all high-value: purpose, side effects, prerequisites, and parameter constraint; no fluff.

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 financial operation with side effects; covers freezing behavior and confirmation needs, though could note success/failure output given no output schema exists.

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?

Explains the 'confirm' parameter semantics given 0% schema coverage, but leaves orgSlug, periodo, and montoDistribuido unexplained despite lack of schema 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?

Specific verb (distribute) and resource (profits), clearly distinguishes from sibling cierre tools (e.g., vs listar_utilidades which only lists, vs cerrar_org which closes).

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 prerequisites (period must be organizationally closed first) and required confirmation, though could explicitly reference prerequisite tools.

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

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

Discloses business logic constraints (frozen period restriction) and confirmation requirement not visible in schema, though could clarify what 'reopen' means for the client.

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 three high-value sentences; action is front-loaded with constraints following logically.

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?

Adequately covers key constraints for this deletion operation despite lacking parameter descriptions; sufficient for correct invocation given standard ID patterns.

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?

Adds critical semantic for 'confirm' parameter (must be true) but fails to compensate for 0% schema coverage for orgSlug and cierreId identifiers.

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 (delete/reopen) and resource (client closing), though 'Delete (reopen)' phrasing is slightly ambiguous; distinguishes from sibling cierre 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?

Explicitly states critical constraint (only if period not frozen) and confirmation requirement, effectively guiding when tool is invocable.

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?

Since no annotations exist, description adequately discloses return values (counts, percentage, possibility flag) but omits side effects, idempotency, 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?

Front-loaded with action verb, two concise sentences covering purpose and returns, no redundant 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 return values (necessary given no output schema) but lacks domain context about what 'closing' entails and its position in the closing 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 has 0% description coverage and description fails to compensate by not explaining 'periodo' format, 'orgSlug' semantics, or optional 'apiKey' usage.

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 evaluates organizational closing readiness for a period and distinguishes from sibling 'cierre_cerrar_org' by focusing on evaluation rather than execution.

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 no guidance on when to use this evaluation tool versus the actual closing tool (cierre_cerrar_org) or other cierre module siblings.

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 fails to disclose return structure, pagination behavior, side effects, or what constitutes a 'closing' record.

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 brief (13 words) and front-loaded, though arguably too terse given the complexity of the cierre module.

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 4 parameters, complex sibling ecosystem (8 cierre_* tools), and no output schema, description inadequately explains the domain concept of 'cierre' (settlement/closing).

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 0% schema coverage, description partially compensates by mapping 'period' and 'client' to filtering intent, but omits required orgSlug semantics and apiKey purpose.

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 'List client closings for an organization' but 'closings' is ambiguous (financial settlement? account closure?) and fails to distinguish from sibling cierre_listar_utilidades or client_list.

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 filtering capability ('Filter by period and/or client') but provides no guidance on when to use this versus cierre_preview_cliente or cierre_evaluar_org.

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?

Describes return structure (per-period records with specific fields) which is necessary given no output schema exists, but omits side effects, rate limits, or 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?

Two concise sentences with no redundancy; immediately states purpose then return values.

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?

Adequately covers return values given no output schema exists, though parameter documentation is missing for the simple 2-parameter input.

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 0% schema description coverage, the description fails to explain parameter semantics beyond implicitly referencing 'organization' for orgSlug; apiKey is unexplained.

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 lists retained earnings with specific financial return fields (ingresos, costos, etc.), distinguishing it from sibling client-management and distribution 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?

No explicit guidance on when to use this vs alternatives like cierre_distribuir_utilidades or cierre_evaluar_org; only states what the tool does.

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?

Since no annotations exist, description adequately conveys it's safe (preview only) and lists specific return values (ventas, cobros, pagos, sessions) compensating for missing output schema.

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

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

Two concise sentences, front-loaded with action and critical distinction; no fluff.

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 return values adequately given lack of output schema and explains domain-specific terms (ventas, cobros, pagos, sessions), though parameter documentation is missing.

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

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

With 0% schema description coverage, description fails to compensate by explaining parameter formats (e.g., periodo format, clientId format) or semantics beyond property names.

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 action (preview financial snapshot) and distinguishes from siblings via 'WITHOUT creating the closing', but 'financial snapshot' could be more specific about being a pre-closing report.

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 read-only use case vs committing tools via 'WITHOUT creating', but lacks explicit workflow guidance (e.g., 'use before cierre_crear_cliente').

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. Adds critical behavioral context: email-based deduplication logic ('linked, not duplicated') and implies idempotent-like behavior. Missing error handling and return value details, but covers the key business rule.

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 core purpose; second sentence delivers critical deduplication behavior. Perfectly front-loaded and appropriately sized.

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 12 undocumented parameters and no output schema, the description is incomplete. It covers the creation logic and deduplication rule but omits required parameter documentation, return value structure, and error scenarios expected for a complex 12-parameter mutation tool.

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

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

Schema has 0% description coverage with 12 parameters. Description mentions 'email' in the deduplication context but fails to document the 3 required parameters (orgSlug, name, lastName) or explain the other 9 optional fields (rut, apiKey, idempotencyKey, etc.). Insufficient compensation for schema deficiency.

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 specific verb (Create), resource (client), and scope (in the organization). Clearly distinguishes from siblings like client_get, client_list, and client_update through the explicit creation intent.

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 context through the email deduplication behavior, indicating when duplicates are avoided. However, lacks explicit guidance on when to use client_update vs client_create, or prerequisites like required fields.

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 partially succeeds by disclosing return value characteristics (financial summary, recent sessions) in lieu of an output schema. However, it fails to mention error behaviors (e.g., client not found), authorization requirements, or whether the operation is safe/idempotent.

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 with no redundant text. However, given the complete lack of schema documentation and annotations, it may be overly terse—leaving insufficient space to explain the five parameters or behavioral constraints.

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

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

For a tool with five parameters (two required), zero schema documentation, no annotations, and no output schema, the description is insufficient. It hints at return value structure but provides no guidance on required parameters (orgSlug, clientId) or how to construct a valid request, leaving significant gaps for agent operation.

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

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

Schema description coverage is 0%, requiring the description to compensate for five undocumented parameters. The description implicitly maps to includeFinancials and includeHistory by mentioning 'financial summary' and 'recent sessions,' but completely omits the required identifiers (orgSlug, clientId) and authentication (apiKey), leaving critical parameters unexplained.

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 (Get) and resource (client details), and distinguishes this from sibling tools like client_list (implied single vs multiple) and client_create/client_update (read vs write). It specifies unique content areas (financial summary, recent sessions) that hint at the scope of returned data.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives like client_list. While the naming convention (get vs list) implies single-record retrieval by identifier, there is no text explaining prerequisites (e.g., needing a clientId from client_list) or when to prefer this over other client tools.

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

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

No annotations are provided, so the description carries full burden. It mentions pagination behavior but fails to disclose critical traits: read-only vs. destructive nature, authentication requirements (apiKey parameter exists but is undocumented), rate limits, or response structure. This leaves significant behavioral gaps.

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

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

The description consists of two efficient sentences with no filler. The first establishes core functionality and the second specifies filter capabilities, making it appropriately 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 7 parameters, zero schema descriptions, no annotations, and no output schema, the description provides the minimum viable context for a list operation. However, it lacks necessary details on the required orgSlug, authentication via apiKey, and expected return values.

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 0% schema description coverage, the description partially compensates by mapping capabilities to parameters: 'search' (search), 'pagination' (limit/cursor), 'filter by provider' (providerId), and 'outstanding debt' (hasDebt). However, it fails to mention the required orgSlug or the apiKey parameter, leaving critical inputs undocumented.

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

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

The description clearly states the verb (List) and resource (clients of an organization) and mentions key capabilities (search, pagination, filtering by provider/debt). However, it does not explicitly differentiate from sibling cierre_listar_clientes or clarify when to use this versus client_get for single client retrieval.

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 scenarios (when you need a list with filters) but provides no explicit when-to-use guidance, prerequisites, or alternatives. It does not indicate when to prefer this over client_get (single retrieval) or cierre_listar_clientes.

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. Mentions email immutability constraint but fails to disclose mutation side effects, idempotency, authorization requirements, or what happens if clientId doesn't exist.

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

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

Two sentences, zero fluff. First establishes purpose, second states key constraint. Every word earns its place and critical 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?

For an 11-parameter mutation tool with no output schema and zero schema descriptions, the description is inadequate. Lacks parameter definitions, return value structure, error scenarios, or partial vs full update semantics.

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 has 0% description coverage. Description vaguely references 'personal data' (covering name, phone, etc.) but fails to explain 11 parameters including critical identifiers (orgSlug, clientId, proveedorTitularId) or apiKey purpose. Insufficient compensation for zero schema documentation.

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 ('Update') + resource ('client's personal data') + scope ('existing'). Distinguishes effectively from sibling tools like client_create (new vs existing) and client_get (read vs write).

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

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

Provides one explicit constraint ('Email cannot be changed via MCP') which prevents incorrect usage. Implies usage for existing clients only, but lacks explicit when-to-use guidance versus client_create or error handling 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 disclosure burden. It successfully covers: variable substitution placeholders (Spanish locale), return values (campaign ID and recipient count), draft state behavior, and confirmation requirement. Minor gap: doesn't explain apiKey authentication implications or adHocFilters structure.

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

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

Three dense sentences with zero waste. Front-loaded with purpose, middle covers configuration specifics, end covers lifecycle and prerequisites. Every clause delivers unique information not found in structured fields.

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?

Strong coverage for a 10-parameter tool with no output schema: description explains return values and complex audience selection logic. Minor deduction: description focuses on 'email' while the schema's 'type' parameter supports whatsapp/auto, suggesting slightly incomplete capability coverage.

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 has 0% description coverage, so description must compensate. It effectively documents audienceType/audienceId enums, confirm requirement, and emailBody format. However, it doesn't explain the 'type' parameter (which allows 'whatsapp'/'auto' per schema), apiKey usage, or adHocFilters nested structure, leaving some parameters undocumented.

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 specific verb 'Create' + resource 'email campaign' + key trait 'HTML body' and 'segmented audience'. Critically distinguishes from sibling tool comms_send_campaign by clarifying this creates a draft while the sibling executes it.

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

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

Explicit workflow guidance: 'Campaign starts as draft — use comms_send_campaign to execute'. Also clarifies when to use 'predefined' vs 'adhoc' audience types with specific valid values for audienceId. States mandatory requirement 'confirm: true'.

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 successfully indicates that delivery logs are available per recipient (a key data behavior), but fails to disclose safety properties (idempotency, read-only nature), rate limits, or the structure/format of the returned campaign details.

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 12-word sentence is efficiently structured with the primary action front-loaded ('Get details'). However, given the lack of schema documentation and annotations, the description may be overly terse—trading necessary explanatory detail for brevity.

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 retrieval tool with 5 parameters and no output schema, the description minimally covers the main entity (campaign) and optional sub-resource (logs). However, significant gaps remain: no explanation of what constitutes a 'campaign' in this domain, no return value description, and no parameter documentation beyond the log feature.

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?

Given 0% schema description coverage, the description inadequately compensates for undocumented parameters. It implicitly explains 'includeLogs' and 'logLimit' via 'optional delivery logs', but completely omits the two required parameters ('orgSlug', 'campaignId') and the 'apiKey' authentication parameter, leaving critical inputs undefined.

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 ('details of a specific campaign'), clearly distinguishing it from sibling 'comms_list_campaigns' (single retrieval vs. listing) and 'comms_send_message' (read vs. write). It also identifies the secondary resource ('delivery logs per recipient').

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 the word 'optional' hints at when to request logs, the description provides no explicit guidance on when to use this tool versus 'comms_list_campaigns' (e.g., 'use this when you have a specific campaign ID'), nor does it mention prerequisites like authentication or required permissions.

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 successfully enumerates what data is returned (WhatsApp settings, email config, confirmation/reminder channels), which compensates partially for the missing output schema. However, it fails to disclose whether this is a safe read-only operation, potential error conditions, or rate limiting concerns.

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, information-dense sentence that front-loads the action ('Get') and resource. The parenthetical list of preference types (WhatsApp, email, etc.) efficiently clarifies scope without verbosity. No wasted words or redundant phrases.

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 this is a simple retrieval tool with 2 parameters and no output schema, the description adequately covers the conceptual output (preference fields). However, it falls short of completeness due to the complete absence of parameter documentation and lack of guidance on the tool's relationship to the broader communications workflow (e.g., that preferences affect 'comms_send_message' behavior).

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

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

Schema description coverage is 0% for both 'orgSlug' and 'apiKey' parameters. The description mentions 'for an organization', providing weak semantic context for 'orgSlug', but completely omits 'apiKey'. With zero schema documentation, the description inadequately compensates by failing to explain parameter formats, requirements, or the API key's purpose.

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 communication preferences for an organization, specifying the exact resource and using a precise verb ('Get'). It distinguishes from siblings like 'comms_update_preferences' and 'comms_send_message' by focusing on retrieval of preference settings rather than mutation or messaging operations.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'comms_update_preferences' or 'comms_get_campaign'. It omits prerequisites (e.g., whether the organization must exist) and gives no hints about read-after-write patterns or caching considerations.

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 fails to disclose read-only safety, pagination behavior (despite cursor/limit parameters existing), or return format. The agent cannot determine if this is a safe operation or how to handle multi-page results.

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 two-sentence structure is front-loaded with the core purpose first, and every sentence conveys distinct information (scope and filtering capability). However, given the tool's complexity (5 parameters including pagination), the extreme brevity borders on under-specification.

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

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

For a tool with 5 parameters, pagination support, and no output schema or annotations, the description is insufficient. It does not explain the pagination mechanism, required orgSlug context, or what data structure to expect in returns, leaving significant gaps in contextual understanding.

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 0% schema description coverage, the description must compensate significantly. It only explicitly references 'status' filtering and implicitly 'organization' scoping. It completely omits explanation of pagination parameters (cursor, limit) and the apiKey authentication parameter, leaving critical functionality undocumented.

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 communication campaigns and specifies the channels (WhatsApp/email). However, it does not explicitly distinguish from sibling `comms_get_campaign`, which likely retrieves a single campaign versus this tool's list functionality.

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 mentions the ability to 'Filter by status,' providing some usage context. However, it lacks explicit guidance on when to use this versus `comms_get_campaign` or `comms_send_message`, and does not mention pagination requirements for large result sets.

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 full burden. It discloses output format (PNG), WhatsApp delivery for 'send' action, and template data requirements. However, it lacks critical behavioral details: return value structure (JSON with URL?), error handling for missing data fields, image storage duration, or 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?

Three sentences with zero waste: sentence 1 establishes purpose and templates, sentence 2 explains action modes, sentence 3 covers data requirements. Information is front-loaded and density is optimal.

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 9 parameters with nested objects and no output schema or annotations, the description covers the primary use case adequately but has notable gaps: the 'upload' action is unexplained, the return value format is unspecified, and required parameters like 'orgSlug' lack semantic context. Sufficient for basic operation but incomplete for robust agent usage.

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 0%, requiring description compensation. It successfully explains the 'template' enum values, 'action' values (partially), and the nested 'data' object structure (clientName, providerName, etc.). However, it leaves 6 of 9 parameters (orgSlug, apiKey, clientId, whatsappTo, whatsappBody, width) completely undocumented.

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 core function ('Render a communication template as a visual image') with specific format (PNG) and lists available templates. However, it could better distinguish from sibling tools like 'comms_send_message' by explicitly contrasting image rendering vs. text messaging.

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 'preview' (get image URL) vs 'send' (render and send via WhatsApp). However, it completely omits the 'upload' action present in the schema enum, leaving a gap in usage 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 full burden and discloses key behaviors: asynchronous processing ('asynchronously'), immediate return behavior ('Returns immediately'), state validation requirements ('draft or scheduled status'), and safety confirmation ('Requires confirm: true'). Minor gap regarding error handling or idempotency prevents a 5.

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

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

Five sentences, each earning its place: action definition, behavioral details, prerequisites, post-call flow, and safety requirement. No redundancy or filler. Front-loaded with the core action 'Execute a draft or scheduled campaign.'

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 0% schema coverage and no output schema, the description effectively covers critical gaps: explains the async flow, documents the tracking mechanism via sibling tool, and mandates the confirmation parameter. Lacks only error state documentation or response structure details 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?

Schema description coverage is 0% (apiKey, confirm, orgSlug, campaignId all undocumented in schema). Description compensates partially by explaining confirm must be true and implying campaignId refers to draft/scheduled campaigns, but orgSlug and apiKey remain unexplained. Adequate but incomplete compensation for the schema gap.

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 the tool 'Execute[s] a draft or scheduled campaign' and 'Sends messages to all matching recipients asynchronously' — specific verb (execute/send), specific resource (campaign), and distinguishes from siblings like comms_create_campaign (creates vs executes) and comms_send_message (individual vs campaign bulk).

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 prerequisites ('Campaign must be in draft or scheduled status'), explicit post-call guidance ('Returns immediately — use comms_get_campaign to track progress'), and critical invocation requirement ('Requires confirm: true'). Clearly distinguishes when to use this versus comms_get_campaign for tracking.

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

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

With no annotations provided, the description carries the full burden. It discloses the confirmation safety requirement ('confirm: true') and the mutual exclusivity of template vs custom content. However, it omits critical behavioral details for a write operation: whether messages are sent immediately or queued, error handling (e.g., invalid phone numbers), rate limits, or if messages can be recalled.

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: purpose first, parameter logic second, requirement third. Every sentence earns its place with 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?

Given 8 parameters with 0% schema coverage and no output schema, the description provides minimum viable context for the primary use case (sending templated vs custom messages) but leaves addressing parameters (orgSlug, clientId) and the nested 'variables' object unexplained. For a high-stakes messaging operation, additional behavioral context (side effects, failure modes) is needed.

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

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

Schema description coverage is 0%, requiring the description to compensate. It explains templateKey, customMessage (including the 2000 char maxLength implied by context), and confirm. However, it fails to explain orgSlug, clientId, apiKey, or crucially, 'variables' (which likely populates template placeholders), leaving significant gaps in parameter understanding.

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

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

The description clearly states the action ('Send'), channel ('WhatsApp or email'), scope ('single'), and target ('specific client'). The word 'single' effectively distinguishes this from sibling campaign tools (comms_list_campaigns, comms_get_campaign) which imply bulk operations.

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 guidance on parameter selection ('Use templateKey for predefined templates or customMessage for free text') and prerequisites ('Requires confirm: true'). Lacks explicit contrast with campaign tools or guidance on when messaging is appropriate vs other communication methods.

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 successfully discloses two key behavioral traits: partial update semantics and upsert behavior (create if missing). However, it omits auth requirements (apiKey parameter exists but is unexplained), safety implications, or side effects of changing preferences.

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: purpose statement front-loaded, followed by partial update semantics, then upsert behavior. Every sentence earns its place with no redundancy.

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

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

Adequate for a 13-parameter mutation tool with no output schema. Covers the critical behavioral contract (partial update, upsert) but remains thin on domain specifics (doesn't mention email/whatsapp specifically) and omits parameter documentation that the schema fails to provide.

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

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

Schema description coverage is 0%, requiring the description to compensate. It provides semantic grouping ('communication channels', 'features') that maps to the boolean toggles and message fields, but fails to document the required orgSlug identifier, apiKey authentication, or specific enum values for primaryChannel.

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 enables/disables 'communication channels and features' for an organization, using specific verbs. Distinguishes itself from sibling comms_get_preferences by specifying 'update' behavior and from comms_send_message by focusing on configuration rather than message transmission.

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 implicit usage guidance through the 'Partial update' explanation (only provided fields changed) and upsert behavior ('Creates preferences if none exist'). However, lacks explicit when-to-use guidance or comparison to comms_get_preferences for read 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 provided, the description carries full burden for behavioral disclosure. It partially compensates by noting the return structure ('Returns disputes with client and provider info'), but fails to disclose safety characteristics, pagination behavior, error modes, or that the apiKey parameter implies authentication 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 three-sentence structure is optimally front-loaded: purpose (sentence 1), filtering constraints (sentence 2), and return value preview (sentence 3). Every sentence earns its place with zero redundancy or 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 6 parameters with 0% schema coverage and no output schema, the description provides minimal viable context by explaining the core entity and return structure, but remains incomplete regarding pagination semantics (page/limit) and authentication. Adequate but with clear gaps.

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

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

Schema coverage is 0%, requiring the description to compensate. It adds semantic meaning for 'status' and 'type' via the filtering mention and implies 'orgSlug' through 'organization,' but leaves 'page', 'limit', and 'apiKey' completely undocumented. This is partial compensation for the schema gap.

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 'List[s] disputes for an organization' with specific verb, resource, and scope. While the term 'disputes' distinguishes it from sibling tools like finance_list_cobros or client_list, it could strengthen differentiation by clarifying if these are payment disputes vs other types.

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 mentions filtering capabilities ('Filter by status or type') but provides no explicit guidance on when to use this tool versus finance_list_payments or other financial listing tools. No prerequisites, exclusion criteria, or alternatives are documented.

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 successfully discloses the partial-update behavior (unmentioned fields remain unchanged), which is essential for a configuration update. However, it misses other critical behavioral details: side effects on active overdue accounts, validation constraints (e.g., step ordering), and idempotency.

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, both essential. First establishes purpose; second gives critical partial-update instruction. No redundancy, well front-loaded.

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

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

For a configuration tool with 5 parameters (including a nested array of objects with enums and constraints) and 0% schema coverage, the description is insufficient. It does not explain the domain model (what constitutes a valid dunning step sequence), valid enum semantics for 'channel', or the interaction between 'steps' and 'blockOnStep5'.

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 0%, requiring heavy description compensation. While it notes that 'organizationSlug' is the only required field, it fails to explain the complex domain semantics of 'steps' (dunning escalation workflow), 'blockOnStep5' (what gets blocked?), or 'gracePeriodDays' context, leaving the agent to guess the business logic from property names alone.

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

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

Clear verb 'Update' and resource 'dunning (payment recovery) configuration' with helpful parenthetical definition. However, it does not explicitly distinguish from sibling 'dunning_get_config' (read vs write), though the verb difference is somewhat implicit.

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 crucial usage guidance that this follows partial-update/PATCH semantics ('only provided fields are updated'), explaining how to populate parameters. However, lacks explicit guidance on WHEN to use this vs the sibling 'dunning_get_config' or prerequisites like permissions.

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 compensates by detailing return values: 'whether dunning is enabled, grace period, step timings, and blocking settings'. Missing safety context (read-only assumed from 'Get' but not explicit) and rate limits. Adequate given no output schema exists.

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

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

Two sentences with zero waste: first establishes purpose, second details return payload. Perfectly front-loaded and appropriately sized for tool 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?

Acceptable for a simple getter with 2 parameters. Return value description substitutes for missing output schema, but 0% parameter coverage and lack of usage context leave gaps that should be filled.

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 0% (no parameter descriptions in JSON schema). Description mentions 'organization' implying organizationSlug context, but completely omits apiKey parameter semantics. Insufficient compensation for undocumented 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?

Excellent clarity: specific verb 'Get' + resource 'dunning (payment recovery) configuration' + scope 'for an organization'. The parenthetical explanation of dunning and explicit distinction from sibling 'dunning_configure' makes the purpose unmistakable.

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?

Zero usage guidance provided. No mention of when to use this vs. sibling 'dunning_configure', prerequisites for the organizationSlug parameter, or typical workflows (e.g., check config before updating).

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 disclosure burden. It successfully reveals the deletion scope (both Resend and database), the fallback behavior (reversion to default sender), and the safety mechanism (requires confirm: true). Does not address reversibility or impact on queued emails.

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 well-structured sentences with zero redundancy: action, implementation details, consequence, and requirement. Every sentence adds distinct value beyond the schema and title.

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

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

Adequate for a destructive operation with no annotations or output schema, covering the essential behavioral impact and confirmation requirement. However, clear gaps remain in parameter documentation (apiKey, orgSlug) and lack of return value description.

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 0% schema description coverage, the description partially compensates by documenting the critical `confirm` parameter ('Requires confirm: true'). However, it fails to explain `apiKey` entirely and only implicitly references `orgSlug` via 'organization', leaving gaps for a 3-parameter tool.

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

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

The description uses specific verbs ('Remove', 'deletes') and identifies the exact resource (configured email sending domain). It distinguishes from siblings like email_domain_register and email_domain_verify by explicitly describing the removal action and organizational impact (reverting to default Coordinalo address).

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 implicit usage context through the consequence description (reverting to default address), but lacks explicit guidance on when to choose this over email_domain_verify or register, and does not specify prerequisites beyond the confirmation flag.

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, description carries full disclosure burden. It successfully documents the null-return edge case and enumerates specific status values (PENDING, VERIFIED, FAILED). Lacks explicit read-only safety declaration, though implied by 'Get'.

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 delivers purpose, return structure, status enum values, and null-handling behavior; second sentence provides sibling tool reference. 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?

Despite no output schema, description adequately documents return behavior (domain object with status field or null) and enumerates possible status values. Sufficient for a simple getter tool, though could briefly describe the domain object structure beyond status.

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 has 0% description coverage. Description partially compensates by mentioning 'organization' which maps conceptually to the required 'orgSlug' parameter, but provides no explicit parameter guidance, syntax details, or mention of the optional 'apiKey' 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 uses specific verb 'Get' with clear resource 'email sending domain' and scope 'configured for an organization'. It distinguishes from sibling tools by explicitly referencing 'email_domain_register to set one up', clearly positioning this as retrieval-only versus 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?

Provides explicit alternative tool reference ('Use email_domain_register to set one up') indicating when NOT to use this tool. Also clarifies edge case behavior with 'Returns null if no domain is configured', establishing expectations for empty states.

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 critical destructive behavior (replaces previous domain), return value type (DNS records), and external dependency (must configure in domain provider). Missing: auth requirements, rate limits, or error scenarios.

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 waste: purpose (sentence 1), return value/behavior (sentence 2), destructive warning (sentence 3), and next step instruction (sentence 4). Information is front-loaded and logically sequenced.

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?

Comprehensive for a 3-parameter tool with no output schema. Describes return values (DNS records), complete workflow (register → configure → verify), and side effects (replacement). Only gap is detailed parameter documentation.

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 0%, requiring description compensation. Mentions 'domain' and 'organization' concepts mapping to parameters, but does not explicitly document the apiKey parameter or parameter formats/constraints. Partial compensation for the schema gap.

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 (Register), resource (custom email sending domain), scope (via Resend), and target (organization). It effectively distinguishes from siblings like email_domain_verify by positioning this as the initial registration step.

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

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

Explicitly references the sibling tool email_domain_verify for the next workflow step ('After adding DNS records, call email_domain_verify'). Warns about replacement behavior ('Replaces any previously configured domain'). Lacks explicit 'when not to use' exclusions, but provides clear workflow 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?

No annotations provided, so description carries full burden. Discloses three possible return states (VERIFIED, PENDING, FAILED) with semantic meanings ('ready to send', 'DNS not yet propagated'). Explains the asynchronous nature of DNS propagation. Missing idempotency details or retry guidance for PENDING state.

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. Front-loaded with action and return value, followed by prerequisite, then return state enumeration. Every sentence provides distinct value (action, timing, possible outcomes).

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, the description essentializes return values by listing all three status states and their business meanings. Covers the DNS verification workflow context adequately. Could improve with retry behavior for PENDING or remediation steps for FAILED, but sufficient for correct 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?

Schema coverage is 0% with no parameter descriptions. Description mentions 'organization' which loosely maps to orgSlug, and implies domain configuration context, but fails to document apiKey or explicitly define orgSlug as the organization identifier. Inadequate compensation for complete schema description absence.

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 ('Trigger DNS verification'), target resource ('configured email domain'), and return value ('updated status'). Distinguishes from sibling tools like email_domain_register (setup) and email_domain_get (passive retrieval) by emphasizing the active verification trigger.

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 temporal prerequisite: 'Call this after the organization has added the required DNS records.' Establishes workflow sequence. Lacks explicit naming of alternatives (e.g., when to use email_domain_get instead), but the 'trigger' verb implies active vs. passive usage.

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 data grouping behavior (specific 0-7, 7-30, 30-90, 90+ buckets), but omits operational traits like read-only nature, rate limits, or auth requirements since no annotations exist.

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

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

Two tightly written sentences with front-loaded purpose; every clause earns its place with zero 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?

Adequately compensates for missing output schema by detailing the report structure (age buckets), though pagination mechanics remain unexplained.

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 has 0% description coverage and description fails to compensate—no guidance on orgSlug, cursor pagination, or apiKey purpose.

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

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

Specific verb-resource pair ('Get accounts receivable aging report') and clearly distinguishes from sibling finance tools via 'age buckets' and 'old debts' focus.

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 ('who owes money', 'old debts'), though lacks explicit alternatives or exclusions (e.g., vs finance_client_balance).

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 and no output schema, the description carries the burden of explaining what the tool returns. It successfully lists the balance components (sales, charges, payments, debt, credits), but omits information about error states, data freshness, or whether the operation is idempotent/read-only.

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, efficiently structured sentence that front-loads the verb and resource, with the colon-separated list providing precise scoping 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 lack of output schema, the description partially compensates by describing the return structure. However, with 0% schema coverage on three parameters, the description fails to provide adequate context for the input requirements, leaving the agent to infer parameter semantics.

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

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

Schema description coverage is 0%, requiring the description to compensate. While it implies the 'clientId' parameter by mentioning 'for a client', it fails to document 'orgSlug' (critical for multi-tenant organization scoping) or 'apiKey' (authentication), leaving significant gaps in parameter understanding.

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

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

The description clearly states the tool retrieves a 'complete financial balance' and enumerates specific components (sales, charges, payments, debt, credits), which distinguishes it from sibling list tools like finance_list_payments. However, it does not explicitly differentiate when to use this aggregated view versus querying specific transactions.

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

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

The description provides no guidance on when to use this tool versus alternatives like finance_aging or finance_list_payments, nor does it mention prerequisites such as requiring valid clientId and orgSlug identifiers.

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 but discloses minimal behavioral traits. It does not explain whether creating a cobro triggers immediate billing, generates an invoice, utilizes the idempotencyKey, or what the mutation returns.

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. The first sentence front-loads the core action; the second provides critical sibling differentiation. 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?

For a financial mutation tool with 8 parameters, zero schema documentation, no annotations, and no output schema, the description is insufficient. It lacks critical details on side effects, error conditions, return values, and comprehensive parameter guidance needed for safe 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?

Schema description coverage is 0%, requiring the description to compensate. While 'client' hints at clientId and 'charge' implies monto/descripcion, it fails to explain tipo, fecha, orgSlug, apiKey, or idempotencyKey semantics, leaving 5 of 8 parameters undocumented.

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 ('Create') and resource ('manual charge/cobro') and explicitly distinguishes from siblings by stating it is 'Not linked to a sale/venta', clearly differentiating it from finance_create_venta.

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

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

The description provides a negative constraint ('Not linked to a sale/venta') implying when not to use it, but fails to explicitly name the alternative tool (finance_create_venta) or provide positive guidance on specific use cases for manual charges.

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 full disclosure burden but only reveals one side effect (auto-charge creation) and one requirement (confirm). It fails to explain auth requirements (apiKey), the semantic difference between the estado enum values, idempotency, or what 'org configuration' controls.

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 compact with two efficient sentences and no redundancy. However, given the high parameter count and zero schema coverage, the extreme brevity becomes a liability rather than a virtue, forcing critical details into an overly dense format.

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 financial mutation tool with 10 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It lacks return value documentation, enum semantics, and parameter relationships necessary for safe invocation of a create operation in a finance domain.

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 0%, requiring the description to compensate for 10 undocumented parameters. It explicitly mentions only 'confirm', while implying client and service context. It completely omits explanation of critical parameters like estado (realizado/proyectado), proveedorId, fechaRef, cantidad, and precio, leaving their semantics and formats undefined.

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 creates a 'service sale (venta)' with specific verbs and resources. It distinguishes itself from sibling finance_create_cobro by noting that this tool 'auto-creates a charge (cobro)' conditionally, clarifying the relationship between the two entities.

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 context by noting the optional auto-creation of charges depending on org configuration, but lacks explicit guidance on when to use this versus finance_create_cobro or when to set estado to 'realizado' vs 'proyectado'. The confirm requirement is stated as a constraint rather than workflow 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, the description carries the full burden. It adds value by disclosing that associated payments are included in the response (behavioral trait). However, it lacks explicit read-only declaration, error handling details, or rate limit warnings despite the safety-critical financial 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?

Single sentence with no wasted words. Front-loaded with the action verb and immediately specifies the resource and included sub-resources.

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

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

For a 3-parameter tool with zero schema descriptions and no annotations, the description is insufficient. While it hints at return structure ('associated payments'), it fails to document critical parameters needed for invocation, leaving the agent to guess at orgSlug and apiKey purposes.

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 0%, so the description must compensate. It implicitly references 'cobroId' through 'specific charge,' but provides no semantics for 'orgSlug' (organization scoping) or 'apiKey' (authentication), leaving two of three parameters undocumented.

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 ('Get details') and resource ('specific charge/cobro'), and distinguishes this from list operations by emphasizing 'specific.' It also clarifies scope by mentioning 'including all associated payments,' which distinguishes it from a basic charge lookup.

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 provided on when to use this versus siblings like `finance_list_cobros` (list vs. detail view) or `finance_list_payments` (direct payment lookup). No prerequisites mentioned despite required orgSlug/cobroId parameters.

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 disclosure burden. It successfully notes the presence of 'summary totals' in the response, which compensates partially for the missing output schema. However, it fails to describe pagination behavior despite cursor and limit parameters being present, and omits any mention of rate limits 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?

Extremely efficient at approximately 15 words across two sentences. Information is front-loaded with the core action first, followed by filtering capabilities and output characteristics. No redundancy or filler content.

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

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

Adequate for a list operation with 8 parameters and no output schema. Covers the primary filtering dimensions and mentions aggregate output features, but leaves significant gaps regarding pagination workflow, parameter validation rules, and the specific composition of the 'summary totals'.

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?

Given 0% schema description coverage, the description partially compensates by mapping functional concepts (client, status, date range) to the parameter set. However, it leaves critical parameters unexplained: 'apiKey' (purpose/format), 'cursor' (pagination mechanism), and 'limit' (pagination size). It also fails to clarify valid values for 'estado' or date string formats.

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 (List) and resource (charges/cobros), clarifying this is a bulk retrieval operation. The parenthetical translation of 'cobros' helps distinguish it from sibling tools like finance_list_payments or finance_list_ventas, though it doesn't explicitly articulate the business difference between these financial entities.

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?

Describes filtering capabilities (client, status, date range) but provides no explicit guidance on when to use this versus finance_get_cobro (single retrieval) or finance_list_payments. No prerequisites or exclusion criteria 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 provided, the description carries the full disclosure burden. It clarifies the scope (pending_confirmation state, four possible status values) and implies read-only behavior via 'List', but omits mention of pagination, return format, or authorization requirements beyond the apiKey parameter.

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 efficient sentences with zero redundancy: purpose declaration, domain scoping, and filter capabilities. 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?

Given zero schema coverage and no output schema, the description adequately covers the tool's domain purpose but remains incomplete regarding parameter specifics (especially orgSlug) and return behavior (absent output schema).

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

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

Schema coverage is 0%, requiring the description to fully compensate. The text explains the 'status' parameter (listing all four enum values) and implies 'clientId' ('Filter by client'), but fails to document the required 'orgSlug' or the 'apiKey' parameter, leaving critical inputs undocumented.

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 'pending charge confirmations and their status' (specific verb + resource). It adds domain context by specifying 'cobros in pending_confirmation state' and mentions the exact filterable states. However, it could better distinguish from sibling 'finance_list_cobros' by explicitly contrasting general listing vs confirmation-specific listing.

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 contexts ('Shows cobros...that await client verification'), suggesting when to use it, but lacks explicit guidance on when to prefer this over 'finance_list_cobros' or prerequisites like needing valid client/org identifiers.

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 disclosure burden. It adds value by noting the output 'includes summary by payment type,' but fails to indicate read-only safety, pagination behavior (despite cursor/limit params), or date range constraints.

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 at two sentences with the core action front-loaded. However, given the complexity (8 undocumented parameters), this brevity crosses into underspecification rather than efficient communication.

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?

Inadequate for a financial tool with 8 parameters and zero schema documentation. While it mentions the payment type summary, it omits critical context: pagination mechanics, date range formats, required orgSlug, and the apiKey authentication pattern.

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 has 0% description coverage across 8 parameters. The description mentions 'with filters' generically but fails to compensate by explaining specific filter semantics (dateFrom/dateTo range, clientId filtering, 'tipo' values) or pagination (cursor/limit). Only the 'tipo' parameter meaning is weakly implied via 'payment type.'

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