Coordinalo — Service Business Operations

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

Discloses key behaviors: auto-discoverable by default, auto-assignment logic, blocking condition (unassigned services block admin_toggle_discoverable), and authentication requirement (X-Org-Api-Key header). No annotations provided, so description carries full burden.

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?

Concise single paragraph with efficient use of sentences: prerequisite, default behavior, edge case, alternative, next step, and requirement. No redundant or vague language.

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?

Provides thorough behavioral context and workflow integration, but lacks parameter explanations given 0% schema coverage and 8 parameters. Omits details like return value (no output schema) but that is acceptable per guidelines.

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 description should add meaning to parameters. It only mentions the apiKey parameter implicitly via header requirement. Does not explain other parameters like name, price, duration_minutes, etc., which are left to schema defaults.

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 'Add a bookable service to an organization.' Provides context: use after admin_create_organization. Distinguishes from sibling service_create by specifying admin-specific behavior like auto-discoverable and auto-assignment.

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 (after admin_create_organization), when not to use (auto-assignment only for single provider orgs), alternatives (service_assign_provider for multiple providers), and next steps (admin_set_availability). Also mentions required header.

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 requirement for X-Org-Api-Key header and auto-provisioning behavior. No annotations provided to contradict. Listing operation implies read-only, but not explicitly stated.

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, front-loaded with purpose, each sentence adds value without 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?

For a simple list tool, description covers usage context, prerequisites, and a behavioral note (auto-provisioning). No output schema so return values are not described, but completeness is adequate for the complexity.

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

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

Schema has 2 parameters (apiKey, orgSlug) with 0% description coverage. Description mentions header requirement (X-Org-Api-Key) but does not explain orgSlug or apiKey parameter roles, leaving meaning unclear.

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

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

Description clearly states 'List active providers (professionals) for an organization.' with specific verb and resource, and distinguishes from sibling admin_set_availability by mentioning it as a prerequisite.

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 instructs 'Use this to get providerId before calling admin_set_availability.' Also notes org owner auto-provisioning, providing clear context and when to use.

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

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

No annotations provided, so description carries burden. It clearly states the overwrite behavior (not additive). But lacks details on success/failure responses or side effects beyond overwriting.

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, no filler. Key information is front-loaded: purpose, behavior, prerequisite, format, and auth requirement.

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 necessary context (prerequisite, format, auth) but lacks output description or error handling. Since no output schema exists, some return info would be helpful.

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 description must compensate. It explains providerId source and schedule format (day names, HH:MM). But does not mention orgSlug or apiKey explicitly beyond header requirement.

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 (replace), the resource (weekly availability schedule), and scope (for a provider). It distinguishes from sibling tools like availability_get_provider_schedule by emphasizing it overwrites.

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 prerequisite: 'Get providerId from admin_list_providers first.' Also mentions required header. However, it does not specify when to use this tool versus alternatives.

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

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

No annotations provided, so description carries full burden. It discloses that without consent, the tool flips local flags but does not publish due to cron skipping the org. It also mentions the required X-Org-Api-Key header, providing full transparency on behavioral traits.

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 paragraph that efficiently conveys purpose and warnings. It is front-loaded with purpose, then important caveats. There is no wasted text, but it could benefit from slightly more structured formatting (e.g., bullet points for prerequisites).

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 no annotations, the description covers purpose, prerequisites, consequences, and authentication requirements. It provides enough context for an AI agent to decide when and how to use the tool correctly.

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

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

Schema description coverage is 0%, but the description adds meaning by explaining the effect of discoverable flag and the need for orgSlug (implied). However, it does not explicitly describe each parameter, and the apiKey parameter is mentioned indirectly via header requirement, leaving some ambiguity. Scores 3 because it compensates somewhat but not fully.

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 toggles the LIFECYCLE flags isPublic and servicialoPublished, which is a specific verb+resource combination. It distinguishes from siblings like admin_create_service and admin_list_providers, which have different purposes.

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

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

The description explicitly warns that the tool does not grant public discovery consent, details the prerequisite Organization.discoveryConsent=true set by human owner, and explains the consequences of calling without consent. It also mentions required authentication header, providing excellent when-to-use and when-not-to-use guidance.

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

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

No annotations provided, and description lacks details on idempotency, error handling (e.g., duplicate slug), authentication requirements, or rate limits. Only mentions the resulting public URL.

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

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

Two sentences, front-loaded with purpose, but the second sentence is slightly verbose. Could be streamlined while retaining key context.

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 28 parameters, no output schema, and no annotations, the description leaves out essential details on parameter meanings and expected results, making it incomplete for complex use cases.

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%; description does not explain any of the 28 parameters. Many parameter names are self-explanatory, but enums and advanced options lack clarification.

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 public agenda for client self-booking, distinguishing it from siblings like agendas_list or agendas_delete.

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 context that creation should happen after services and availability are configured, and contrasts with booking via API/dashboard. Does not explicitly compare with other agenda 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?

Discloses key behavioral traits: permanent deletion, cascading effects on sessions, comments, and service configs, and the requirement for confirmation ('Cannot be undone'). With no annotations, description fully covers the behavioral implications beyond the action itself.

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

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

Two efficient sentences with no redundant information. First sentence states the main action, second adds critical behavioral details and constraints. 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 delete tool with no output schema, description adequately covers the effect and key constraints. However, it does not explain what the response looks like or address the meaning of all parameters beyond confirm, which is a minor gap.

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

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

Schema description coverage is 0%, so description must add meaning to parameters. Only 'confirm' is partially explained (must be true). Other parameters (apiKey, orgSlug, agendaId) are not described at all, leaving their purpose and constraints unclear.

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 'Delete a public agenda permanently', specifying the verb and resource. Differentiates from sibling tools like agendas_update, agendas_get, agendas_list, and agendas_create by explicitly being the deletion operation.

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

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

Explicitly states 'Requires confirm: true' to indicate a precondition for use. Implicitly guides when to use (when deletion is intended) but does not explicitly mention when not to use or compare with siblings, though context from sibling names provides differentiation.

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 bears full burden. It lists what is returned, implying a read operation, but doesn't explicitly guarantee no side effects or mention auth/rate limits.

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

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

Two concise sentences – the first states purpose and output, the second provides actionable usage guidance. No unnecessary 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?

No output schema, so description must describe output. It enumerates major config fields (booking flow, policies, etc.), which is detailed. However, 'including' implies non-exhaustive.

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

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

Schema has 0% description coverage; description only hints at agendaId by mentioning 'by ID' but does not explain apiKey or orgSlug. Adds minimal value over parameter 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?

The description clearly states the tool retrieves complete details of a public agenda by ID, listing key config categories. It distinguishes from siblings by explicitly recommending use before 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?

It advises using before agendas_update, providing clear context. No explicit when-not or alternatives, but the sibling set and simple use case make guidance adequate.

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 must carry full behavioral disclosure. It only states 'list public agendas' and returns counts, but lacks info on pagination, filtering, ordering, or any side effects. Authentication via apiKey is implied but not explained.

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 is concise and front-loads purpose. Could add more context without becoming verbose, but current structure is efficient.

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

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

No output schema, so return format is partially described (agendas with counts). Lacks pagination, ordering, and error handling info. Given low complexity (2 params, no nested objects), it is adequate but has gaps in safety and completeness.

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

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

Schema description coverage is 0%, so description should compensate. It mentions 'for an organization' hinting at orgSlug, but does not explain apiKey or add meaning beyond the schema. No parameter details are provided.

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 public agendas for an organization and specifies the returned data (provider, service, session counts). The verb 'List' and resource 'public agendas' are explicit, and it differentiates from siblings like agendas_get (single) and agendas_create.

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

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

No guidance on when to use this tool versus alternatives (e.g., agendas_get for a specific agenda). No conditions or exclusions 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?

No annotations are provided, so the description carries full burden. It discloses partial update behavior and auto-linking of services when a provider is assigned. However, it lacks details on authorization requirements, error conditions, or side effects beyond the listed fields.

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 relatively long but efficiently packed with information. It starts with the main purpose, then lists supported modifications. Could benefit from more structured formatting like bullet points, but it is still clear and front-loaded.

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

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

Given 32 parameters with no output schema and no annotations, the description covers key behavioral aspects and parameter categories. However, it lacks details on validation, conflict handling, and response format, making it incomplete for a complex tool with many configuration options.

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

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

Schema description coverage is 0%, so the description compensates well. It explains the meaning of many parameters like booking flow order, assignment strategy, booking policies, cancellation policies, privacy flags, prepayment, and provider/service linking. However, some parameters (e.g., slug, apiKey, expiresAt, allowComments) are not individually explained.

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

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

The description clearly states 'Update a public agenda’s configuration' and specifies it's a partial update. It distinguishes from sibling tools like agendas_create, agendas_delete, agendas_get, and agendas_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?

The description implies usage for updating an existing agenda, with the note 'Partial update — only provided fields are changed'. It does not explicitly mention when not to use or alternatives, but it is contextually clear given sibling tool names.

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 full burden for behavioral transparency. It clearly indicates a read-only operation ('Get the configured ... schedule') and clarifies that it returns base configuration, not free slots. This is sufficient for a non-destructive tool, though more detail on auth or rate limits could improve it.

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

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

The description is concise, using a single sentence to convey the main purpose plus an additional sentence for modification guidance. No unnecessary words, but could be slightly more structured with parameter context.

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

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

The tool is simple, but given the lack of output schema, the description does not specify the return format or structure of the weekly availability schedule. This leaves the agent uncertain about what information will be received.

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

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

The input schema has 0% description coverage, meaning no parameter descriptions are provided. The tool description also fails to explain the purpose or format of any of the three parameters (apiKey, orgSlug, providerId). This is a significant gap that hampers correct invocation.

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 the resource 'configured weekly availability schedule for a provider'. It explicitly distinguishes from free slots, which avoids confusion with the sibling tool availability_get_slots. This provides high purpose clarity.

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 directs users to admin_set_availability for modification, which provides guidance on when to use this tool versus alternatives. It does not explicitly state when not to use it or list prerequisites, but the context is clear enough for a simple read operation.

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

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

With no annotations provided, the description carries full weight for behavioral transparency. It explains agenda-awareness, titular provider resolution, and the hiding of provider details in modes 1-3. It lacks details on auth requirements and error handling but provides substantial behavioral insight.

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 front-loaded with the main purpose and then systematically lists the five modes. It ends with a usage recommendation. While detailed, it remains structured and does not contain superfluous information.

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

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

Given 11 parameters and no output schema, the description is incomplete. It covers the modes and key parameters but omits details on return format and several parameters. For a complex tool, more completeness 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%, so the description must add meaning. It explains the roles of orgSlug, clientId, agendaId, serviceId, and providerId in the context of the five modes. However, parameters like apiKey, date, dateTo, dateFrom, duration, and timezone are not described, leaving gaps.

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

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

The description clearly states the tool's purpose: 'Query available time slots within a date range.' It then elaborates on agenda-aware behavior and distinguishes five distinct modes of operation, differentiating it from sibling tools like 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?

The description provides usage context by explaining when to use each of the five modes based on parameters like orgSlug, clientId, agendaId, serviceId, and providerId. It explicitly advises 'Use before booking_create.' However, it does not mention alternatives or when not to use this tool.

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

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

In the absence of annotations, the description fully discloses the default cancellation policy application, penalty transaction generation, and the option to waive charges. This provides clear behavioral expectations.

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

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

Three concise sentences with no fluff. The most important information (cancellation, policy, waiver, confirm requirement) 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?

No output schema and no annotations. The description covers core cancellation behavior but lacks details on return values, error states, prerequisites (e.g., session existence), and the purpose of the 'reason' parameter. Slightly incomplete for a 7-param 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 description coverage is 0%, so the description must add meaning. It explains applyCancellationPolicy and confirm, but other required parameters like reason, orgSlug, sessionId are not described. This leaves gaps.

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

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

The description clearly states it cancels an existing session. It distinguishes from sibling tools like booking_create or booking_reschedule by specifying 'cancel' as the action.

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

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

The description implies usage for cancellation without explicitly comparing to other cancellation-related tools (e.g., public_booking_cancel, scheduling_cancel). However, it does provide guidance on when to use cancel vs reschedule indirectly.

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

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

With no annotations, the description fully discloses key behaviors: auto-assignment of provider with strategy, titular provider preference, default agenda, retroactive behavior (skips validation, sets status, tags provenance), auto-charge, past date detection, and max 365 days in the past. No contradictions.

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 efficiently structured, starting with the main purpose, then conditional behaviors, then preconditions. It is somewhat lengthy due to complexity, but every sentence adds value. Could be slightly more concise by omitting redundant details.

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 14 parameters, 4 required, and no output schema, the description covers core behavior, preconditions, and many parameter nuances. It lacks return value description and fails to mention idempotencyKey, but overall provides sufficient context for correct use.

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 explains providerId (optional, auto-assign), publicAgendaId (default if omitted), serviceId/clientId preconditions, retroactive and autoCharge effects, and auto-detection of past dates. It does not explain notes, apiKey, duration, modalidad, or idempotencyKey explicitly, but covers the most critical parameters with useful context.

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 'Create a new session/appointment for a client.' It uses a specific verb and resource. The tool is distinguished from siblings like booking_cancel and booking_create_recurring by focusing on single-session creation.

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

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

The description gives explicit preconditions (service must exist, client must exist), recommends using availability_get_slots first, and explains conditional behaviors (retroactive, auto-assign). It does not explicitly contrast with booking_create_recurring, but provides clear context for when to use this tool.

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

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

No annotations are provided, so the description must fully disclose behavior. It mentions that multiple sessions are generated and linked by a recurrence series ID and a maximum of 52 occurrences, but omits other important behaviors such as required permissions, handling of conflicts, cancellation behavior, or rate limits. More detail is needed for safe invocation.

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

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

The description is two sentences long, front-loading the primary action and key constraint (max occurrences). It is efficient and avoids redundancy, though it could be slightly more structured with parameter highlights.

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

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

Given the complexity (10 parameters, nested objects, no output schema, no annotations), the description is incomplete. It does not explain return values, error conditions, authorization, or how to handle the recurrence series ID. The single detail about max occurrences is useful but insufficient for a fully autonomous agent.

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%, and the description adds minimal parameter context beyond mentioning 'recurrence' and the max occurrence limit. With 10 parameters (6 required) and nested objects, the description should explain key parameters like confirm, skipConflicts, and recurrence properties. The current description is insufficient for correct parameter selection.

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'), identifies the resource ('recurring sessions'), gives an example ('e.g. weekly therapy'), and specifies a key behavior ('Generates multiple individual sessions linked by a recurrence series ID') and a limit ('Max 52 occurrences'). This clearly distinguishes it from sibling tools like booking_create.

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

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

The description implies when to use (for recurring sessions) but does not explicitly state when not to use it or provide alternatives. Given siblings like booking_create (single session) and booking_reschedule, explicit guidance would improve selection.

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 must disclose behaviors. It only says 'get', implying read-only, but does not confirm lack of side effects, authorization needs, error handling, or rate limits. Users cannot infer safety or 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?

Single sentence front-loads the key action and output scope. No redundant words; every phrase adds value. Excellent conciseness.

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

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

No output schema, so description should outline return structure. It lists categories but lacks detail on hierarchy or field names. For a simple get tool, it's borderline adequate but leaves room for ambiguity about exact returned fields.

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

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

Schema has 0% description coverage, so description must explain parameters. It only mentions 'by its ID' for sessionId, but does not describe apiKey or orgSlug. No parameter formats, examples, or validation rules are provided.

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, listing specific categories (client, provider, service, financial, delivery proof). This differentiates it from sibling tools like booking_list (which lists) and booking_cancel (which cancels).

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

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

The description implies use when needing full details of a specific session, but lacks explicit guidance on when not to use or comparisons to alternatives (e.g., booking_list for summaries). No prerequisites or context for when this tool is appropriate over others.

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?

Mentions cursor-based pagination, but lacks details on authentication (apiKey parameter) and error behavior. No annotations provided, so description carries full burden; it is moderately transparent but incomplete.

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

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

Two sentences, front-loaded, no extraneous information. Every sentence adds value.

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

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

Given 11 parameters with no schema descriptions and no output schema, the description is too brief. It does not cover response format, default ordering, or cursor usage details, leaving significant 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%, so description must compensate. It explains filters (provider, client, service, status, date range) but omits meaning for key parameters like apiKey, cursor, orderBy, and limit.

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 sessions with specific filters and pagination. It distinguishes from siblings like booking_get (single session) and booking_list_requests (requests) but does not explicitly contrast with them.

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

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

Implies usage when retrieving multiple sessions with filters, but provides no guidance on when not to use it or alternatives such as booking_get for single sessions.

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, but the description discloses read-only behavior, cursor pagination, and the return fields (proposed slot, current session state, who proposed it). It also mentions the includePendingCount option for sidebar badge. While it could mention rate limits or auth requirements, the description is sufficiently transparent for a read operation.

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

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

The description is three sentences, front-loaded with the tool's purpose, then details filters and return values. Every sentence adds value with no redundancy or 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?

Given no output schema, the description covers return values (proposed slot, session state, proposer) and pagination. It mentions the includePendingCount feature and provides a use case. Could optionally mention error responses or auth, but it is complete enough for an AI agent to invoke the tool correctly.

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

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

With 0% schema description coverage, the description fully compensates by explaining the status enum (pending|all|resolved, default pending), the use of sessionId and clientId filters, cursor pagination, and the function of includePendingCount (powers the sidebar badge). This adds significant meaning beyond the bare schema.

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

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

The description clearly states it lists reschedule requests (SessionRequest) for an organization, specifying the verb 'List' and resource 'reschedule requests'. It distinguishes from siblings like booking_resolve_request and booking_reschedule by describing the bilateral coordination loop and providing filtering options (status, sessionId, clientId).

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

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

The description explicitly states when to use this tool (to list reschedule requests from the organization side) and provides an alternative: 'Use booking_resolve_request to approve or reject one.' It also explains filter parameters and default behavior, giving clear context for agent decision-making.

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

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

With no annotations, the description carries the burden. It discloses that the tool cancels the original and creates a new one, and requires confirm: true. However, it omits side effects like notifications, permission requirements, or reversibility.

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 no wasted words. The purpose is front-loaded, and the critical constraint is stated concisely.

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 (4 required), no output schema, and no annotations, the description is incomplete. It does not explain essential parameters like orgSlug, sessionId, or newScheduledAt, nor behavior when confirm is false.

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

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

Schema description coverage is 0%, so the description must add meaning. Only confirm is explained (must be true). The purpose hints at newScheduledAt and sessionId, but no details on format, required fields like orgSlug, or optional newProviderId.

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

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

The description explicitly states the tool reschedules a session by canceling the original and creating a new one, clearly distinguishing it from sibling tools like booking_cancel and booking_create.

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

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

The description implies usage for changing a session's time but does not provide explicit when-to-use or when-not-to-use guidance relative to alternatives. It mentions 'Requires confirm: true' but no context on when to use this vs. separate cancel/create steps.

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 atomicity for approval, reason constraint for rejection, idempotency behavior, and emission of session lifecycle events. It does not mention auth requirements or exact response format, but provides substantial insight.

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

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

The description is three sentences with no wasted words. It front-loads the core purpose and efficiently packs crucial details about behavior, constraints, and 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 and no annotations, the description is fairly complete. It covers purpose, outcomes, constraints, idempotency, and lifecycle events. A minor gap is the lack of detail on the response format or what data is returned.

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 description must compensate. It explains 'outcome' (approved/rejected) and 'reason' (min 10 chars for rejection). 'requestId' and 'orgSlug' are implied by the context. 'apiKey' is not explained, but overall the description adds significant meaning beyond the schema.

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

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

The description clearly states the tool's purpose: 'Approve or reject a pending reschedule request (SessionRequest) that a client proposed from the portal'. It specifies the action (approve/reject) and the resource type, and distinguishes from siblings like 'booking_reschedule' and 'portal_propose_reschedule'.

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

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

The description explains when to use each outcome: 'approved' applies atomically, 'rejected' requires a reason of 10+ characters. It also notes idempotency (returns conflict if already resolved). While it doesn't explicitly state when not to use the tool, the context makes it clear it's for responding to client-proposed reschedules.

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 discloses that the 'deliver' action is unavailable due to MCP authentication limitations. However, it lacks details on other behavioral traits such as side effects (e.g., whether status changes are reversible), required permissions, rate limits, or what happens on invalid state transitions. This is insufficient for a mutation tool with no annotation support.

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

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

The description is two sentences: the first delivers the primary purpose, the second adds a critical exclusion and workaround. It is front-loaded, every sentence is essential, and there is no redundancy. Highly concise for the amount of guidance provided.

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

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

Given the tool's complexity (7 parameters, no output schema) and absence of annotations, the description is adequate but incomplete. It explains the main actions and an exclusion, but does not cover return values, error conditions, prerequisites (e.g., session must exist), or behavior for invalid state transitions. The sibling list hints at similar tools but no cross-references are made.

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 but only partially does. It adds context by listing the valid actions and explaining the 'deliver' exclusion. However, it does not explain the meaning of other parameters like orgSlug, sessionId, notes, apiKey, noShowType, or deliveryType. The schema has 7 parameters, many left unexplained, so the description adds limited semantic value beyond the action enumeration.

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

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

The description clearly states the tool's purpose: advancing a session through the Servicialo lifecycle with specific actions (confirm, start, complete, no_show). It uses a specific verb ('advance') and resource ('session lifecycle'), and distinguishes itself from siblings by explicitly excluding the 'deliver' action and directing to a REST endpoint.

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

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

The description provides clear guidance on when to use the tool (to transition through lifecycle states) and explicitly states when not to use it (for 'deliver', due to authentication limitations). It also directs to an alternative REST endpoint for the excluded action. However, it does not mention potential alternatives among siblings for other status transitions (e.g., cancellation may be handled by booking_cancel).

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 that it freezes the period and requires confirmation. Does not mention reversibility or error handling, but adequate for a close action.

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

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

Three short sentences, each adding distinct value. Purpose first, then prerequisites. 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?

Covers key prerequisites and a behavioral requirement. Lacks description of output or error states, but for a closing operation this is sufficient given typical expectations.

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%; description only explains the 'confirm' parameter requirement ('Requires confirm: true'). Does not describe 'orgSlug', 'periodo', or 'apiKey', though names are self-explanatory. Adds minimal value beyond schema.

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

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

Clearly states the action: 'Close the organizational period' and 'Freezes the period.' Verb+resource is specific and distinct from sibling tools like 'cierre_crear_cliente'.

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 precondition: 'Requires ALL active clients with historialCompleto=true to be closed first.' Also notes 'Requires confirm: true.' Lacks alternatives or when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses immutability and constraints, but does not mention side effects, return value, authentication needs, or error handling.

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

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

The description is concise (two sentences) and front-loaded with purpose, but lacks structured detail that could help in understanding parameter dependencies.

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 parameter count (6), no output schema, and no annotations, the description is incomplete. It does not fully enable correct invocation without external knowledge.

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 should explain parameters. It only partially explains 'confirm' and implies 'clientId' and 'periodo' from context, but leaves out 'orgSlug', 'apiKey', and 'notas'.

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

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

The description clearly states it creates a client monthly closing (immutable financial snapshot), with specific prerequisites and constraints, distinguishing it from sibling tools like cierre_eliminar_cliente or cierre_preview_cliente.

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 prerequisites (historialCompleto=true, confirm=true) and a constraint (one per client per period), but does not explicitly state when not to use or provide alternatives among sibling 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 side effects (freezes current and prior open periods) and required confirmation, which is crucial for a financial mutation. No annotations exist, so description carries full burden.

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

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

Two sentences: first covers purpose and side effect, second covers prerequisites. No wasted words, 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?

No output schema or return behavior described. Lacks details on what happens after distribution, error states, or required authorization beyond confirmation.

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%, but description only adds meaning for 'confirm' and implicitly for 'montoDistribuido'. Other parameters like orgSlug, periodo, apiKey are left 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 'Distribute profits for a closed period' with additional context on freezing periods and prerequisites. Distinct from sibling tools like cierre_listar_utilidades.

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 prerequisites (period must be organizationally closed, confirm: true) but does not explicitly suggest when to use this versus alternatives like cierre_evaluar_org or cierre_cerrar_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?

With no annotations, the description must disclose behavioral traits. It mentions the destructive nature (delete/reopen) and a prerequisite and confirm flag, but fails to describe side effects, permissions needed, or what happens to the client after deletion. This is insufficient for safe usage.

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 very short (two sentences) and concise, but it lacks structure. For a tool with multiple parameters and conditions, a slightly longer description with organized information would be more helpful. It front-loads key info but is under-informative.

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 parameter descriptions, the description is incomplete. It does not mention return values, provide examples, or elaborate on the conditions. The tool requires 3 required params, but the description covers none of them adequately.

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% and the description does not explain any parameter meanings (apiKey, orgSlug, cierreId, confirm). It only mentions that confirm must be true, but no semantic context is added for the other parameters. This is a major 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 deletes/reopens a client closing, with 'delete' as the verb and 'client closing' as the resource. It distinguishes from sibling tools like cierre_crear_cliente and cierre_listar_clientes. However, it could better explain what a 'client closing' is.

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 conditions ('Only allowed if the organizational period is not frozen') and a requirement ('Requires confirm: true'), giving some guidance on when to use. But it lacks explicit mention of when to prefer this over alternatives like cierre_cerrar_org or cierre_preview_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?

Lists return fields, giving insight into output. However, no annotations exist, and the description does not state whether the operation is read-only, whether it modifies data, or any permission requirements. Adequate but not thorough.

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

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

Two sentences: first states purpose, second lists outputs. Front-loaded and concise with no filler.

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

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

For a tool with no output schema, listing return values helps. But no annotations, no parameter descriptions, and missing usage context make it incomplete for an agent to use confidently.

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 compensates only partially: 'periodo' is implied by 'for a period', but 'apiKey' and 'orgSlug' are not explained. Missing parameter meaning reduces effectiveness.

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 evaluates organizational closing readiness and lists specific return values (active clients, closed count, excluded count, pending count, percentage, possibility). It effectively distinguishes from sibling 'cierre_cerrar_org' which performs the actual close.

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

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

No guidance on when to use this tool vs alternatives like 'cierre_preview_cliente' or prerequisites for the period parameter. Missing context for decision-making.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It only states a basic listing action without any details about pagination, data sensitivity, authentication, or side effects. This is insufficient for an agent to understand the tool's full 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 description is concise (one sentence), but it lacks structure and does not front-load critical information. It could be expanded to cover essential context without being verbose.

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

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

Given the tool has 4 parameters, no output schema, and no annotations, the description is too minimal to be complete. It omits important details such as response format, pagination, and authentication requirements, which an agent needs 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?

The schema has 0% description coverage, so the description must compensate. It partially does by indicating that 'periodo' and 'clientId' are filters, but 'apiKey' and 'orgSlug' remain unexplained. The description adds some value but is not comprehensive.

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 client closings for an organization and mentions filtering. It distinguishes from related tools like 'cierre_cerrar_org' and 'cierre_crear_cliente'. However, the term 'client closings' is not explained, which could cause ambiguity.

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

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

The description implies usage by mentioning filtering options (period and client), but it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or prerequisites.

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

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

With no annotations, the description carries full burden. It discloses that the tool reads and returns per-period records with specific fields, but does not mention authentication needs, error handling, or potential side effects. It adds some context beyond the basic read operation.

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

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

The description is a single, focused sentence followed by a clarifying list of return fields. It is concise, front-loaded, and every word adds value.

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

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

For a simple list tool with no output schema or annotations, the description covers purpose and return content adequately. However, missing details on permissions or error cases prevent a perfect score.

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

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

The input schema has 0% description coverage, and the description does not explain the parameters (apiKey, orgSlug). The value of orgSlug is implied by 'for an organization', but apiKey is undocumented. This is a significant 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 a specific verb ('list') and resource ('retained earnings for an organization'), and distinguishes from sibling tools like 'cierre_distribuir_utilidades' (distribution) and 'cierre_cerrar_org' (closing org).

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 (listing retained earnings for an organization) but provides no explicit guidance on when to use vs alternatives or when not to use.

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 correctly declares that no side effects occur (preview only) and lists what is returned. Lacks details on permissions or rate limits, but the read-only nature is clear.

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 high information density: purpose, key behavior (no creation), and return content. No unnecessary 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?

Despite good outlines, missing details like period format, response structure, ordering, or integration with other closing tools. Agent may struggle to use correctly without additional context.

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

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

Schema description coverage is 0%, so description should compensate, but it does not explain any parameters beyond their names. No guidance on format or meaning of 'periodo', for example.

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

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

Description clearly states it previews a financial snapshot without creating a closing, and specifies the returned totals (ventas, cobros, pagos, sessions). The tool name and sibling context (other cierre_ tools) reinforce this purpose.

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 says 'WITHOUT creating the closing', guiding the agent to use this when only previewing is needed. However, it does not explicitly name alternatives or state when not to use it.

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

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

No annotations are present, so the description must fully disclose behavioral traits. It only reveals the linking behavior for email duplicates. It omits whether the tool is idempotent, required permissions, return values, error handling, or side effects like linking to existing Persons.

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

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

The description is extremely concise (two sentences) with no redundant information. It front-loads the core purpose and immediately follows with a key behavioral note, wasting no 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 complexity (12 parameters, no output schema, linking behavior), the description is highly incomplete. It lacks parameter explanations, output details, error scenarios, and preconditions. The tool is under-described for safe agent use.

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 12 parameters, the description provides almost no parameter-level guidance. Only 'email' is indirectly mentioned in the linking behavior. Critical parameters like orgSlug, name, and lastName are 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 ('Create a new client') and the target resource ('in the organization'), and distinguishes from sibling tools like client_update and client_list by noting the linking behavior for email duplicates.

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

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

The description implies usage for creating clients but does not provide explicit guidance on when not to use the tool or alternatives (e.g., when to use client_update for existing clients). The linking behavior is mentioned but no prerequisites or exclusions are stated.

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

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

No annotations are provided, so the description must fully convey behavioral traits. It indicates the operation is a 'Get' (presumably read-only) and lists included data, but fails to disclose auth requirements, rate limits, side effects, or any destructive implications. For a mutation tool this would be critical; for a read tool it is somewhat acceptable but still lacks depth.

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

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

The description is a single sentence that front-loads the purpose and includes scope details. Every word is necessary; there is no redundancy or 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?

Given five parameters (two required), no output schema, and no annotations, the description is too sparse. It does not explain what 'complete details' encompasses, return format, error conditions, or how parameters like includeHistory affect the result. A read tool with this complexity needs more context.

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

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

Schema description coverage is 0% and the description does not explain any of the five parameters (apiKey, orgSlug, clientId, includeHistory, includeFinancials). The description hints at financial and session data but does not map these to the boolean parameters. With no parameter documentation, the description adds no value beyond the schema.

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

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

The description clearly states the verb 'Get' and resource 'client details', specifying 'complete details' and listing included data like financial summary and recent sessions. This clearly distinguishes it from sibling tools such as client_create, client_list, and client_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?

No explicit guidance is provided on when to use this tool vs alternatives. The description implies it is for retrieving full client details, but it does not mention when not to use it or suggest alternative tools for different needs.

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 is minimal. Does not disclose idempotence, auth requirements (apiKey), pagination behavior, or output format.

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

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

Two short sentences, front-loaded main purpose. No unnecessary 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 7 parameters, no annotations, no output schema, the description is too brief. Lacks details on return format, pagination mechanism, and error cases.

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 meaning for search, pagination, providerId, hasDebt but omits orgSlug (required) and apiKey. With 0% schema description coverage, this is insufficient.

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 clients with search and pagination, and can filter by provider or debt. However, does not differentiate from sibling cierre_listar_clientes.

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 for listing clients with filters but no explicit guidance on when to use this vs other client listing tools, nor exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that email cannot be changed, which is a useful constraint, but it fails to mention idempotency, partial update behavior, auth requirements, or any side effects. The description is too sparse to inform safe invocation.

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

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

The description is a single sentence that efficiently conveys the core purpose and a key constraint. It is front-loaded and contains no filler. However, it sacrifices completeness for brevity, which is acceptable for conciseness but not ideal overall.

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 11 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain required vs. optional fields, return behavior, error conditions, or typical usage patterns. The tool requires much more context to be usable by an agent.

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

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

Schema description coverage is 0%, so the description must explain parameter meanings. However, it does not describe any of the 11 parameters beyond implicitly mentioning the absence of an 'email' parameter (which is itself confusing since email is not in the schema). No context or formatting is provided for any field, making the description nearly useless for 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 ('Update') and resource ('existing client's personal data'), which matches the tool name. It adds specificity by noting that email cannot be changed, distinguishing it from a general update. Among sibling tools (e.g., client_create, client_get), it is unambiguous.

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

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

The description does not provide guidance on when to use this tool versus alternatives (e.g., using client_create for new clients or client_get for reading). No exclusion criteria or prerequisites are mentioned. The only hint is the 'Update' verb, but explicit when-to-use instructions are absent.

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 auto-UTM tagging, legal footer appending, draft status, and confirm requirement. With no annotations, it carries the burden well, but omits auth and error handling.

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

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

Single dense paragraph with front-loaded purpose. Every sentence adds value; could use structuring for readability but is efficient.

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 main aspects but lacks full parameter coverage, return format details, and error handling. With no output schema and 10 params, more completeness would help.

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

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

Schema description coverage is 0%, so the description compensates by explaining name, emailBody, audienceType, audienceId, adHocFilters, confirm, and variable substitution. Misses type, apiKey, orgSlug, and emailSubject.

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 an email campaign with HTML body to a segmented audience, specifies variable substitution, and distinguishes from siblings like comms_send_campaign.

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

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

Provides clear context on when to use the tool and how to specify audience (predefined vs adhoc), and mentions using comms_send_campaign to send. Lacks explicit exclusions for non-email types.

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 the optional inclusion of delivery logs, indicating a read operation. However, no details on authentication, error behavior, or rate limits are given.

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?

A single sentence that is concise and front-loaded with purpose. No redundant information; every word contributes to understanding the tool's core function.

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

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

With 5 parameters, no output schema, and no annotations, the description lacks detail on what 'details' encompass, how logs are returned, or parameter dependencies. Significant gaps remain for an agent to use it correctly.

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

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

Schema description coverage is 0%, requiring the description to compensate. It only hints at the 'includeLogs' parameter via 'optional delivery logs,' but fails to explain apiKey, orgSlug, campaignId, or logLimit. Parameters are left to be inferred from 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?

The description clearly states the action ('Get details') and the resource ('campaign'), with additional nuance about optional delivery logs. It effectively distinguishes from sibling tools like comms_list_campaigns and comms_send_campaign.

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 vs. alternatives, but the context of sibling tool names (list, create, send) implies it is for retrieving a single campaign's details. Lacks when-not or prerequisite information.

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

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

No annotations provided; description only says 'Get' implying read-only, but does not disclose required permissions, rate limits, or any other behavioral traits. Carries the burden of transparency but provides minimal info.

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, no wasted words, but too brief to be effective. Could include more detail without sacrificing conciseness.

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

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

No output schema exists, but description does not clarify what is returned beyond 'channels and messages'. Lacks details on return format, pagination, or error handling. Incomplete for a simple read 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%, and the description does not explain the parameters (apiKey, orgSlug) at all. It adds no meaning beyond the 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?

Clearly states the verb 'get' and the resource 'communication preferences for an organization', with specific examples (WhatsApp, email, confirmation, reminder channels and messages). However, it does not differentiate from sibling tools like comms_update_preferences or comms_send_message.

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

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

No guidance on when to use this tool versus alternatives. No mention of prerequisites, when to avoid, or typical use cases.

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 declares the tool is read-only, explains the effect of optional parameters, and describes output fields. It could mention pagination or rate limits but is sufficient.

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

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

The description is three sentences: purpose, parameter details, usage advice. No redundant information, every sentence adds value.

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

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

For a listing tool with no output schema, the description covers what the response includes (filter definition, usage count, optionally client count) and gives usage guidance. Missing pagination or error info but overall complete.

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

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

Schema coverage is 0%, so description must compensate. It explains includeCount and includePredefined well but does not describe apiKey or orgSlug. orgSlug is implied by context, but apiKey is left 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 saved audiences/segments for campaign targeting, specifying that each includes filter definition and usage count. This distinguishes it from sibling tools like comms_list_campaigns or comms_send_message.

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

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

The description explicitly says to use before comms_create_campaign to pick a target audience, and notes it is read-only. It provides clear context but does not mention alternatives or when not to use it.

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 only mentions listing and filtering, no disclosure about read-only nature, pagination, rate limits, or authentication. Significant behavioral gaps remain.

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

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

The description is a single sentence, which is concise. However, it is too minimal and lacks structure, as it could benefit from additional sentences to cover key aspects.

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 5 parameters, no output schema, and no annotations, the description is insufficient. It does not address pagination through 'cursor' and 'limit', or authentication via 'apiKey'. The agent is left without enough context to use the tool correctly.

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

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

The input schema has 5 parameters with 0% description coverage. The tool description only hints at the 'status' parameter via 'Filter by status'. It provides no explanation for 'limit', 'cursor', 'apiKey', or 'orgSlug', leaving the agent without essential parameter 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?

The description clearly states the tool lists communication campaigns, specifies the types (WhatsApp/email), and mentions filtering by status. This distinguishes it from sibling tools like comms_create_campaign, comms_get_campaign, etc.

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

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

The description implies usage for listing campaigns filtered by status, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions. Usage is implied rather than explicit.

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

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

No annotations are provided, so the description bears full burden. It mentions the send action sends via WhatsApp, but fails to disclose required permissions, rate limits, idempotency, or side effects. The basic behavioral context is minimal.

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

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

The description is three sentences long, front-loaded with the core purpose, and efficiently covers templates and actions without unnecessary detail.

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

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

Given the tool's complexity (9 parameters, nested objects, multiple actions) and lack of output schema, the description leaves gaps: return values for actions, prerequisites, and detailed data requirements are 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?

Schema description coverage is 0%. The description adds meaning for the 'template' parameter (listing possible values) and hints at the 'data' object fields (clientName, providerName, etc.), but does not explain other parameters like width, apiKey, clientId, whatsappTo, or whatsappBody.

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

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

Description clearly states the tool renders communication templates as PNG images, lists available templates, and explains the two actions (preview and send). This is specific and distinguishes it from sibling tools like comms_send_message.

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

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

The description explains when to use actions (preview for image URL, send for rendering and WhatsApp sending), but does not provide explicit guidance on when not to use or alternatives among sibling 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 asynchronous execution, skipping of recipients with opt-out or bounced addresses (logged), immediate return, and that tracking is done via comms_get_campaign. No annotations exist, so description carries full burden and fulfills it well.

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?

Description is concise, well-structured, and front-loaded with the main action. Every sentence adds necessary context without redundancy.

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

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

Given no output schema, the description explains the asynchronous nature and how to track progress. It lacks details on the return value and error scenarios, but for a fire-and-forget tool, it is largely sufficient.

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

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

Schema coverage is 0%, and the description only adds meaning for the 'confirm' parameter by stating 'Requires confirm: true'. It does not describe orgSlug, campaignId, or apiKey beyond their names, which are self-explanatory but not enriched.

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 executes a draft or scheduled campaign, sending messages asynchronously. The verb 'Execute' and resource 'draft or scheduled campaign' are specific, and it distinguishes itself from sibling tools like comms_get_campaign (tracking) and comms_create_campaign (creation).

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 preconditions: campaign must be in draft or scheduled status, and requires confirm: true. Does not explicitly mention when to use alternatives, but the context of sibling tools provides some implicit 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 are provided, so the description carries the full burden. It does not disclose side effects (message is sent), required permissions, rate limits, or error handling. The only behavioral hint is 'confirm: true', which is insufficient for a communication tool.

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

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

The description is very concise (two sentences) and front-loaded with key info. However, it sacrifices essential details for brevity. Every sentence serves a purpose but there is room to add more without losing conciseness.

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

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

With 8 parameters, no output schema, and no annotations, the description is incomplete. It does not explain how to use the variables object, the purpose of confirm, the format of customMessage (maxLength is in schema but not described), or what the tool returns.

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 descriptions in schema). The description explains templateKey and customMessage but ignores other parameters like variables, apiKey, orgSlug, clientId, and channel. The variables object is not explained, and confirm is mentioned only as a requirement without meaning.

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), the resource (a message), and the channels (WhatsApp or email). It mentions using templateKey or customMessage, which distinguishes this single-message tool from sibling campaign tools like comms_create_campaign and comms_send_campaign.

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 says 'Requires confirm: true' but does not explicitly guide when to use this tool versus alternatives. It implies that confirm must be set to true but omits when to use templateKey vs customMessage or when to avoid this tool.

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

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

With no annotations, the description carries the full burden. It discloses partial update and auto-creation behavior, which is helpful. However, it does not mention authorization requirements, side effects (e.g., whether updates are reversible), or any other behavioral traits like idempotency or error conditions.

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

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

Two sentences, front-loaded with the core purpose and key behavior (partial update and creation). No unnecessary words or repetition. Every sentence adds value.

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

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

With 13 parameters and no output schema, the description is relatively sparse. It does not explain return values or response structure. For a complex update tool, more context about which fields are commonly updated together or examples would improve completeness.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'communication channels and features' but does not explain individual parameters like emailEnabled, phoneRequired, or primaryChannel. The parameter names are somewhat self-explanatory, but without descriptions, the agent may not know the semantics of boolean settings or the 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?

The description clearly states the tool enables or disables communication channels and features, with a specific verb ('Enable or disable') and resource ('communication channels and features for an organization'). It also specifies partial update behavior and auto-creation, distinguishing it from sibling tools like comms_get_preferences (read) and comms_create_campaign (create).

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

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

The description implies usage for updating preferences, but does not explicitly state when not to use it or provide alternatives. The sibling tools include comms_get_preferences, so the distinction from reading is clear, but no guidance is given for when to use this over other update or creation 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 provided, so description carries burden. It discloses return fields (flags, timestamps, hasEvidence) and explicitly states it never returns evidence summary content. This gives clear behavioral insight beyond the 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?

The description is moderately long but every sentence adds value, explaining the resource, filter options, and output. Well-structured with the main action upfront.

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 adequately specifies return fields and filtering capabilities. It covers the key aspects needed to use the tool, though could briefly mention pagination parameters.

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 explaining state enum and sessionId use. However, it does not describe page, limit, apiKey, or orgSlug, leaving gaps in parameter meaning.

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 specifies the tool lists the delivery-confirmation ledger for organization sessions, with detailed explanation of the overlay and states. It uniquely identifies the resource and action, distinguishing it from siblings like booking_list by focusing on confirmation 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?

Provides explicit guidance on filter states (awaiting_client, confirmed, provider_pending) and the ability to look up by sessionId. However, it does not mention when not to use this tool or compare against siblings, so misses full alternatives 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 are provided, so the description must fully disclose behavioral traits. It mentions filtering and return content but omits important details such as pagination behavior, ordering, rate limits, or the fact that it is a read-only operation. The description partially covers behavior but is insufficient for a tool with no annotations.

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

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

The description consists of two succinct sentences that convey the core purpose, filtering capability, and return content without extraneous information. Every sentence adds value.

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

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

Given the tool has 6 parameters, no output schema, and no annotations, the description is too brief. It does not cover required parameters, pagination details, or the structure of returned data. It lacks completeness for effective use.

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

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

The input schema has 6 parameters with 0% description coverage in the schema itself. The description explains only 'status' and 'type' as filters, leaving required parameter 'orgSlug' and others like 'page', 'limit', and 'apiKey' unexplained. This fails to compensate for the absence 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?

The description clearly states the verb 'List', the resource 'disputes', and the scope 'for an organization'. It also specifies filtering by status or type and the return content includes client and provider info. This differentiates it from sibling list tools like booking_list or finance_list_invoices.

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

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

The description implies usage for listing disputes with optional filtering but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it or give criteria for selecting this tool over others. Among siblings, there is no other disputes list tool, so context is minimal.

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 discloses the partial update behavior ('only provided fields are updated, rest stays unchanged'), which is key. However, it does not disclose authentication requirements, rate limits, or potential side effects. Adequate but not exhaustive.

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, no redundancy. First sentence states purpose, second explains key behavior. Every sentence earns its place.

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

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

Given no annotations, no output schema, and 5 parameters, the description is brief. It covers the update semantics but omits return value expectations, validation rules, or error scenarios. Could be more complete for a configuration mutator.

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 description must compensate. While it notes the partial update behavior, it does not describe individual parameters or their allowed values. The schema itself is clear, but description adds minimal value beyond stating that optional fields are optional.

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

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

Description clearly states 'Update dunning (payment recovery) configuration for an organization.' The verb 'update' and resource 'payment recovery configuration' are specific. It also distinguishes from the sibling 'dunning_get_config' by implying the update role.

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 vs. alternatives. The description implies usage for updating configuration, but does not mention when to avoid or provide contrast with sibling 'dunning_get_config'.

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 indicates a safe read operation but does not disclose authorization requirements, rate limits, or whether the API key needs specific permissions. The description is adequate but lacks depth in behavioral context.

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

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

The description is a single sentence of 20 words, perfectly front-loaded with the purpose. No extraneous words—every part adds value.

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

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

Given the tool's simplicity and lack of output schema, the description provides a useful summary of returned fields (enabled, grace period, etc.). It could mention the response format or any additional fields, but is largely complete for its purpose.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It mentions 'for an organization' which refers to 'organizationSlug', but does not explain 'apiKey'. A description of both parameters is missing, leaving ambiguity for the agent.

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

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

The description clearly states the action ('Get') and the resource ('current dunning configuration for an organization'), along with specific fields returned (enabled, grace period, etc.). It effectively distinguishes from the sibling tool 'dunning_configure' which presumably updates the configuration.

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

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

The description implies a read operation but does not explicitly state when to use versus alternatives like dunning_configure. The context of sibling tools suggests the agent can infer, but explicit guidance on when not to use or prerequisites would improve clarity.

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 explicitly states the deletion is performed on both Resend and the database, and that the org reverts to a default address. This provides reasonable transparency for a destructive action, though it avoids details like error handling or reversibility.

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

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

The description is extremely concise: three sentences that convey the action, scope, consequence, and a key requirement. No filler or redundant information. It is front-loaded and easy to parse.

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

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

Given the simple nature of the tool (a deletion action) and the absence of an output schema, the description covers the essential intent and effects. However, it omits what happens on failure, whether the tool is idempotent, or any return value. For a destructive tool, a bit more completeness would be ideal.

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

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

The schema provides 3 parameters with 0% description coverage. The description adds semantic value only for the 'confirm' parameter by stating its requirement. The 'apiKey' and 'orgSlug' parameters are not explained at all, leaving unclear how they are used or obtained. The description does not compensate for the lack of 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?

The description clearly states the action ('Remove the configured email sending domain'), identifies the resources affected (both Resend and the database), and distinguishes this tool from siblings like email_domain_get, email_domain_register, and email_domain_verify. It directly tells the agent what the tool does.

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 includes the requirement 'Requires confirm: true', which guides proper usage. However, it does not explicitly state when to use this tool versus alternatives (e.g., email_domain_get to inspect current domain), nor does it mention any prerequisites or caution against misuse. The guidance is minimal.

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 the return values (statuses and null) sufficiently for a read operation. No annotations provided, but description covers the main behavioral aspect: it retrieves without side effects. Could mention no modification.

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?

Very concise: two sentences that pack essential information. First sentence states purpose and return values; second adds null case and sibling tool reference. 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?

Adequately covers main functionality and return values, but lacks explanation of parameters and does not describe the full response structure (no output schema). Could be more complete with error handling or parameter details.

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 does not explain the parameters (orgSlug, apiKey). The orgSlug is implied but not detailed; apiKey is not mentioned at all. Fails to add value beyond the schema.

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

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

Clearly states the tool retrieves the email sending domain and its verification status for an organization. Mentions return value null if not configured. Differentiates from sibling by directing to email_domain_register for 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?

Explicitly suggests using email_domain_register as an alternative when no domain is configured. Provides enough context for when to use this tool, though does not explicitly state when not to use it.

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 that the tool replaces any previously configured domain (destructive behavior) and that it returns DNS records. With no annotations, this adds value. However, it does not clarify the role of the optional apiKey parameter or potential 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 sentences, each adding distinct value: purpose, replacement behavior, and follow-up action. No fluff; all information is front-loaded and concise.

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

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

Covers essential steps (register, get DNS, verify) but lacks details on return format of DNS records and error handling. Without an output schema, more specifics would improve completeness.

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

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

Schema has 0% parameter description coverage, so the description must compensate. It implies the purpose of 'domain' and 'orgSlug' but does not explain 'apiKey' or provide detailed syntax for any parameter. The context is helpful but insufficient for full 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?

Clearly states it registers a custom email sending domain and returns DNS records. Differentiates from sibling tools like email_domain_verify and email_domain_delete by specifying the registration action and the follow-up verification step.

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

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

Provides explicit next steps: configure DNS records then call email_domain_verify. Mention of replacement of previous domain warns about overwrite behavior. However, no explicit exclusion or alternative usage is stated, though sibling names provide 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. Reveals action (DNS verification) and return statuses, but lacks details on whether retriggering is safe, if it is asynchronous, or if rate limits apply. Adequate but not exhaustive for a mutation-like tool.

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

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

Two sentences, no filler. First sentence states action, second adds precondition and return values. Highly efficient and front-loaded with key information.

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

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

Given no output schema and simple parameter set, the description covers action, precondition, and return statuses. Lacks parameter explanations but is otherwise sufficient for a straightforward verification trigger 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 description coverage is 0% and description mentions no parameters. Both apiKey and orgSlug are left unexplained, forcing reliance on naming conventions. The description should at least clarify that orgSlug identifies the organization or list other required inputs.

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 describes the action 'trigger DNS verification' for the email domain and lists possible return statuses (VERIFIED, PENDING, FAILED). Distinct from siblings like email_domain_register (domain setup) or email_domain_get (status check). Highly specific and unambiguous.

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

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

Explicitly states precondition: 'Call this after the organization has added the required DNS records.' Provides clear context for when to invoke, though does not mention alternatives or when not to use (e.g., if already verified). Still, the guidance is direct and actionable.

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

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

No annotations are provided, so the description must disclose behavior. It implies a read-only report generation. However, it does not mention pagination, response format, or any side effects. The description is adequate but lacks depth.

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

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

The description is two sentences long, front-loading the purpose and usage. Every word adds value; no redundancy or unnecessary detail.

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

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

Considering the tool has 4 parameters, no output schema, and no annotations, the description is insufficient. It provides high-level purpose but omits critical details about parameters and expected output, making it hard for an agent to invoke correctly without additional context.

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

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

The input schema has 4 parameters with 0% description coverage in the schema. The description does not explain any of these parameters (limit, apiKey, cursor, orgSlug). The agent receives no guidance on how to fill required or optional 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 clearly states the tool retrieves an accounts receivable aging report with specific age buckets. It uses a specific verb ('Get') and resource ('aging report'), and distinguishes itself from sibling finance tools by detailing the grouping by age.

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

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

The description explicitly guides when to use this tool: to answer 'who owes money' or 'old debts' questions. It does not provide exclusions or alternative tools, but the context is clear and applicable.

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 indicates a read operation returning balance components, but does not disclose permissions, mutability, or other behaviors beyond the return data.

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?

A single, front-loaded sentence that efficiently communicates both purpose and scope with no redundant words.

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

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

For a simple tool with 3 parameters and no output schema, the description adequately explains what the tool returns. However, it could clarify return format (single object vs list) or pagination.

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

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

The input schema has 0% description coverage, but the description does not explain any parameters. While clientId and orgSlug are self-evident, apiKey's purpose and format are not clarified.

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

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

The description clearly states the action ('Get') and the resource ('complete financial balance for a client'), listing key components (total sales, charges, etc.). It distinguishes from sibling finance tools that focus on individual transaction 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 implies when to use (when a full balance is needed) but lacks explicit guidance on when not to use or comparisons with alternatives like finance_list_payments or finance_list_ventas.

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 need for confirm: true, implying a confirmation step. However, it does not mention other behaviors such as idempotency (via idempotencyKey), irreversibility, or error handling. The disclosure is minimal but not misleading.

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

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

The description is extremely concise with two sentences. It front-loads the core purpose and key requirement. No wasted words; every sentence adds value.

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

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

Given 9 parameters, no schema descriptions, no output schema, and no annotations, the description is insufficient for complete understanding. It does not explain return values, error states, or how parameters like idempotencyKey affect behavior. Agents lack necessary context to invoke the tool correctly.

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