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

With no annotations, the description carries the burden and does well: it discloses the required API-key scope, explains that downloadPath is authed, and states the MCP boundary for fetching bytes. Missing pagination/limit semantics for 'recent', which is the main gap.

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

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

Two tight sentences with the payload shape front-loaded and the critical constraint (download via API/CLI, not MCP) at the end. Every clause earns its place.

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

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

For a zero-param, no-output-schema, unannotated tool, the description supplies both the return shape and the scope requirement. It leaves 'recent' undefined (how many runs, any window or cap), which is the only material 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?

Zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly spends its words on output semantics instead of inventing input params.

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

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

Specific verb+resource (list scheduled account-export runs) with useful scope detail: per-file metadata fields and downloadPath for completed files. It does not explicitly distinguish itself from nearby siblings like conduyt_scheduled_export_get_settings or conduyt_export_contacts, so it stops short of a 5.

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?

Gives real operating context: requires the explicit 'account-exports' API-key scope, and explicitly directs downloading CSV bytes via API/CLI rather than MCP. No exclusion relative to sibling export/settings tools, so not a full 5.

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

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

With no annotations, the description carries the full burden, and it only discloses the 500-contact cap. It says nothing about whether duplicate memberships are silently skipped, what happens on partial success, required permissions, or reversibility of the mutation.

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 with the action and followed by the hard limit. Nothing wasted.

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

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

For an unannotated bulk mutation with no output schema, an agent still cannot tell what a mixed result looks like, whether the call is idempotent, or how to recover from a 500-limit violation. The size limit alone is too thin a behavioral contract.

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

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

Schema coverage is 100% and both parameters are documented in the schema, so the baseline is 3. The description's 500 limit restates a constraint already present in the contactIds schema description, adding little beyond what the structured field provides.

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

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

Names a specific verb (add) and resource (contacts → smart list), so the operation is unambiguous. It does not distinguish itself from siblings like conduyt_get_smart_list_contacts or conduyt_add_tags, so it stops short of a 5.

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 word "static" hints that the target must be a static smart list, but there is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as conduyt_list_smart_lists to find an ID or conduyt_get_smart_list_contacts to verify.

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 usefully discloses validation dependencies (kind-to-style pairings, required target/pivot/group-by), but says nothing about permissions, whether tile placement/ordering is affected, or whether adding is idempotent.

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

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

Two dense, front-loaded sentences with the core action first and constraints after; telegraphic shorthand ('kind kpi …', 'size s / m / l') is efficient though slightly cryptic for an uninitiated reader.

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 7-parameter mutation with no annotations and no output schema, the description covers the critical conditional logic but omits permissions, return behavior, and what happens to existing tile layout—gaps an agent would want filled.

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

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

Schema coverage is only 43%, and the description compensates well by explaining the kind enum, the size grid ('s / m / l on a six-column grid'), and the conditional requirements tying style/target/pivot to kind. It leaves id, title, and savedReportId largely to 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?

States a specific verb and resource: 'Pin a saved report to a dashboard.' An agent can immediately grasp the effect, though it doesn't name the related siblings (update_dashboard_tile, remove_dashboard_tile) that could be confused with it.

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

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

Provides concrete preconditions: a goal KPI needs a target, a chart needs a group by, a pivot needs a pivot, plus valid style pairings per kind. It does not, however, say when to choose this over updating or removing an existing tile.

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 carry the full behavioural burden; it does disclose the key precondition that tag references must be pre-existing and that nothing is created. However, it does not say whether tags are appended to or replace the deal's current tags, what happens when a deal already carries the tag, or what permissions/errors apply. For an unannotated write tool this is a meaningful gap.

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

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

Four short sentences, front-loaded with the core action and followed by the prerequisite and then usage. There is mild redundancy in restating 'Tags must already exist' and 'this does NOT create tags', but nothing is wasted 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?

For a two-parameter tool with full schema coverage, no output schema and no annotations, the description covers purpose, prerequisite, and invocation pattern sufficiently. The remaining gap — append-vs-replace semantics and duplicate handling — is the only thing an agent could still get wrong.

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

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

Schema description coverage is 100%, so both dealId and tagIds are already documented in the schema, establishing a baseline of 3. The description reinforces 'by tag UUID' and 'non-empty', but adds no format, batching semantics, or limits beyond what the schema states.

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

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

Names a specific verb (tag) and resource (deal) plus the constraint 'by tag UUID', so the agent knows exactly what happens. It explicitly rules out creation by pointing at conduyt_create_tag, though it never names conduyt_add_tags as the contact-scoped counterpart, leaving that differentiation implicit in 'Deals support tags just like contacts'.

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?

Gives a concrete use case ('segment high-value or priority deals'), a hard prerequisite (tags must already exist, create them with conduyt_create_tag), and an explicit exclusion ('this does NOT create tags'). It also sets the multi-deal pattern ('call this once per deal'), which is valuable guidance, but offers no alternative for bulk tagging.

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 present, the description carries the burden and delivers meaningful behavior: phone entries block the NUMBER account-wide across dialer and SMS, scope and admin restrictions apply. It does not disclose what happens on duplicate entries, reversibility, or the response shape, leaving some gaps for a compliance-sensitive mutation.

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 packs the action, both entity modes, the target lists, the operational effect, and the scope/admin constraints, with an inline example. No sentence is redundant.

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 4-parameter, annotation-free mutation with no output schema, the description covers consequences, authorization and list tiers adequately. It omits duplicate-entry behavior and confirmation of the result, which an agent would want before calling.

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

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

Schema coverage is 100%, so tier, phone, reason and contactId are already documented with formats and defaults. The description reinforces the phone-vs-contact distinction and the account-wide effect of phone entries, but adds little beyond the schema's own text. Baseline 3 applies.

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

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

States a specific verb and resource ('Add a phone number (or a contact) to the Do-Not-Call or litigator list') and covers both input modes. An agent can distinguish this from siblings like conduyt_remove_dnc, conduyt_list_dnc and conduyt_bulk_dnc_contacts without opening any schema.

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

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

Provides a concrete trigger utterance ('add this number to the do not call list') plus the two governing conditions: the 'dnc' API-key scope is required, and the litigator tier is admin-only. It stops short of naming alternatives such as the bulk-DNC sibling for multi-contact additions, so the routing is clear but not complete.

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 behavioral burden. It discloses the key precondition (tags must pre-exist) and clarifies the non-creating side effect, which is genuinely useful, but it says nothing about idempotency when a tag is already applied, error behavior for invalid UUIDs, permission requirements, or the response shape.

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

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

Two short sentences with zero waste; the core action comes first and the disqualifying condition ('this does NOT create tags') is front-loaded rather than buried.

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 two-parameter mutation with fully documented schema and no output schema, the description covers the action and the critical prerequisite. The remaining gap is error and idempotency behavior, which matters more given there are no annotations, but it is not enough to make the definition inadequate.

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

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

Schema description coverage is 100% and both parameters are documented inline, so the baseline is 3. The description reinforces that tagging is done by tag UUID and that the IDs must reference existing tags, but adds no format, count limits, or ordering semantics 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?

Uses a specific verb+resource (add existing tags to a contact) and names the tag UUID as the identifier, so the operation is unambiguous. It explicitly distinguishes itself from conduyt_create_tag, but does not distinguish itself from the closest sibling, conduyt_bulk_tag_contacts, or from conduyt_add_deal_tags, leaving some ambiguity for an agent choosing among tagging tools.

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

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

States a clear precondition: tags must already exist and must be created with conduyt_create_tag first. It does not cover the single-vs-bulk choice or when to prefer conduyt_bulk_tag_contacts, so an exclusion is missing, but the primary usage context is 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?

With no annotations, the description carries the burden and does well: it discloses target proration rules (daily once per day, weekly per 7, monthly per 30.4375), the 366-day span clamp, the max 10 userIds compare cap, and that the definition is returned as `definition`. It never states read-only/side-effect profile or permission requirements, which remains a gap.

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

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

Front-loaded with what the tool produces, then constraints. It is a dense single paragraph with colons/semicolons but nearly every clause carries substantive information; a slightly more structured layout would improve scanability.

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

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

For a read-only report with no annotations and no output schema, the description covers the returned metrics, per-rep score, team row, and `definition` field, plus window and span constraints. Permission requirements and result volume/pagination are the only notable omissions.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning: userIds is the compare set (vs. default all active reps), the date pair can both be omitted for a 366-day default, and the proration math explains how targets relate to the window. This is useful semantics beyond the schema's terse 'ISO start'/'ISO end'.

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 states a specific verb+resource (agent performance report) and enumerates the metrics produced plus the target-proration and per-rep scoring logic, so the agent knows exactly what comes back. It does not explicitly distinguish itself from overlapping siblings like conduyt_call_performance_report or conduyt_appointment_report, which also surface calls and appointments.

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 gives implicit invocation guidance: userIds defines the compare set, omitting it covers every active member, and omitting both dates yields the last 366 days with spans clamped to 366 days. However, there is no explicit when-to-use-this-vs-alternatives guidance relative to the other performance/report tools.

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

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

With no annotations supplied, the description carries the full burden and mostly does: it declares 'Read-only' (safety profile), states that every visibility and opt-out rule is applied, notes the tenant timezone for calendar items, and discloses the AI-budget/fallback behaviour of the brief. It does not cover response size, pagination or limits, so gaps remain but the important behaviour is disclosed.

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?

One front-loaded sentence names the deliverable first, then the em-dash clause enumerates contents, then two short trailing clauses cover the brief and read-only status. The list is long but every item is a distinct agenda category the caller must know; nothing is 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?

With no output schema and no annotations, the description is the only source of truth, and it adequately covers what is returned (categorised items plus a summary brief, with counts available from the categories) and the per-user scoping. Missing only return-shape specifics such as ordering, caps or whether empty categories appear.

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

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

Schema description coverage is 100%, so the schema already explains both userId (admin/owner, defaults to authenticated user) and narrative (skip AI brief, spends no AI budget). The description reinforces the narrative semantics via the 'AI engine when available, otherwise deterministic' sentence but adds no format, constraint or edge-case detail 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?

States a specific verb+resource (build the copilot's Today agenda for a user) and then enumerates the concrete item types included: calendar, promised callbacks, awaiting-reply messages, overdue/due-today tasks, untouched leads, follow-ups, quiet deals. That is far more specific than a generic 'get agenda', but it never names a sibling, and close ones (conduyt_ai_daily_brief, conduyt_ai_next_actions, conduyt_dashboard) are left for the agent to disambiguate on its own.

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?

Usage is implied by the 'Today agenda' framing and by 'Read-only', and the visibility/opt-out note signals it is a per-user daily view rather than a raw list endpoint. However, there is no explicit when-to-use versus when-not, no condition selecting it over conduyt_ai_daily_brief or conduyt_ai_feed, and the admin/owner restriction on userId lives only in the schema.

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

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

With no annotations, the description carries the full burden and does so well: the HTTP 202/pending:true polling contract, the fact that a pending answer costs nothing, that no disposition is applied, the recorded-vs-unrecorded fallback behavior, and the dialer:view permission requirement. These are exactly the behavioral traits an agent needs and none are in 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?

Front-loaded with the core purpose, then the two regimes, then the safety/permission facts. It is dense with parenthetical asides and long clauses but essentially every sentence carries a distinct fact; only minor tightening would help.

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 enumerates the return payload (summary, disposition with confidence, deal stage move, follow-up), covers the pending/202 state and its polling remedy, and states the permission prerequisite. An agent has everything needed to call and interpret 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 coverage is 100% and the single callId parameter is already documented as the call UUID. The description references 'the call's details' but adds no syntax, format, or validation nuance beyond what the schema provides, so baseline 3 applies.

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

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

States a specific resource (AI-suggested call disposition) and describes exactly what the answer is in two distinct regimes: recorded calls yield the post-call copilot's grounded insight, unrecorded calls fall back to a metadata classifier. An agent can tell this differs from raw insight retrieval, though it never names the close sibling conduyt_get_post_call_insight explicitly.

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?

Gives clear conditions: for recorded calls the insight exists once the transcription worker has built it (poll again when 202/pending:true), otherwise a classifier proposes from call details. It states polling is cost-free when pending and that nothing is applied. It stops short of naming an alternative tool to use instead, so it is not a full when/when-not routing guide.

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

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

No annotations are provided, so the description carries the full burden. It mentions multi-turn messages, optional record pinning, and that a reply is returned, but it does not disclose whether the operation is read-only, whether chats are persisted, what pinning changes on the record, or any auth/rate/cost behavior.

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

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

Three tightly written sentences with no filler. The purpose is front-loaded, followed by the key input behavior and return value.

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

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

The nested parameter schema is richly documented, no output schema exists, and the description states that the assistant's reply is returned. But with no annotations and no sibling usage guidance, the definition leaves important behavioral and routing context thin.

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

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

Schema description coverage is 100%, and the schema already explains messages, section, and context in detail. The description adds only a high-level note about the multi-turn thread and record pinning, so it meets the baseline for fully covered parameters without adding much 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 states a clear verb and resource: send a multi-turn message thread to a CRM-grounded conversational AI assistant and get a reply. It also clarifies the optional record pinning behavior, but it does not explicitly distinguish this from sibling AI tools such as conduyt_ai_insights or conduyt_ai_compose_email.

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 general CRM-grounded conversation and optional record-specific context via pinning. However, it gives no explicit when-to-use or when-not-to-use guidance and names no alternatives among the many AI 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?

No annotations exist, so the description carries the full burden. It correctly signals that the tool drafts rather than sends, but says nothing about cost/latency of an AI call, whether results are persisted, how the 'previousMessages' cap is enforced, or whether the draft is returned only (no output schema). For a non-annotated AI mutation-adjacent tool this is thin.

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 tight sentences with the core capability and its driving inputs front-loaded; nothing is redundant. It is simply short enough that it leaves gaps rather than waste.

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

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

For a 12-parameter AI generation tool with no annotations and no output schema, the description names the three returned artifacts, which is helpful, but omits whether the email is sent, what happens with missing optional context, and how the draft should be handed off. Adequate, not complete.

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

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

Schema description coverage is 100% across all 12 parameters, so the schema documents tone enum, dealStage, previousMessages limits, etc. The description adds only light framing ('based on contact context, deal stage, and desired tone'), which is baseline 3 territory.

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

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

Specific verb ('Generates') plus concrete outputs (subject, body, HTML) and the contextual inputs that drive them. It implicitly separates itself from conduyt_send_email and conduyt_ai_improve_email by being a fresh composition step, though it never names those siblings.

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

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

The framing implies this is the drafting step before conduyt_send_email, but there is no explicit when-to-use, no exclusions, and no pointer to conduyt_ai_improve_email for refining an existing draft. The agent must infer the workflow.

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 behavioral burden and does not meet it. It does not say whether this triggers a fresh AI run or reads cached results, whether it is costly or slow, whether it is idempotent, or what happens when the transcript is missing.

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

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

Two sentences, front-loaded with purpose and then the return contents, with zero filler. Nothing in it is redundant or misplaced.

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?

There is no output schema, so the enumeration of returned fields is genuinely necessary and well done. However, gaps remain around latency, cost, freshness/caching, and failure behavior for a call without a transcript, which matter for an AI-processing 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 100% and the single callId parameter is already documented with the transcript prerequisite, so the description cannot add parameter meaning. Baseline 3 applies for a high-coverage 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?

States a specific verb (AI analysis) and resource (recorded/transcribed call), and enumerates the outputs produced: summary, sentiment, topics, objections, follow-ups. It does not distinguish itself from near-siblings such as conduyt_get_post_call_insight or conduyt_ai_call_disposition, which an agent could easily confuse with this tool.

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 never says when to choose this over conduyt_get_call, conduyt_get_post_call_insight or conduyt_ai_call_disposition. The only precondition (a transcript must exist) lives in the schema, not the description, so there is essentially no routing 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 present, so the description must carry the behavioral burden. It discloses the brief's contents and that it is for the current user, but it does not state that it is read-only, whether it incurs AI processing cost, or how fresh/complete the output is.

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 tight sentences are front-loaded and waste-free. The list of priority categories is efficient and useful.

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 zero-parameter, no-output-schema tool, the description gives enough to know it returns a brief of today's priority categories. It still lacks usage routing and operational details, but the core call context is present.

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

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

There are no parameters, so the schema baseline is 4. The description adds no parameter semantics because none exist.

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

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

The description gives a clear verb/resource: an AI-generated daily brief for the current user, and names the kinds of priorities it covers. It is more specific than the name alone, though it does not differentiate itself from sibling AI tools such as ai_agenda or ai_next_actions.

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

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

It implies the use case—getting today's priorities—but never states when to choose this over sibling AI tools or when not to use it. No explicit prerequisites, exclusions, or alternatives are provided.

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

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

No annotations exist, so the description carries full burden. It usefully discloses that the analysis is derived from the deal's stage, activity, and history, implying a read-only, computed result, but it says nothing about latency, cost/quota consumption, caching, or what happens when a deal lacks history.

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 tight sentences with the core purpose front-loaded and the return values listed immediately after; no filler or redundancy.

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

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

With no output schema, the description appropriately names the three return categories, but it leaves the agent unable to choose between this and the many sibling AI tools, and offers no guidance on preconditions such as whether the deal must have activity.

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

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

Only one parameter (dealId) with 100% schema coverage, so the schema already tells the agent what to pass. The description adds that stage, activity, and history are the inputs of interest, which is marginal context rather than parameter-level detail.

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

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

States a specific verb+resource ('AI analysis of a single deal') and enumerates what the analysis produces: risk signals, momentum, recommended next actions. It does not distinguish itself from sibling AI tools such as conduyt_ai_insights or conduyt_ai_next_actions, which is the missing ingredient for a 5.

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?

There is no statement of when to call this versus conduyt_get_deal, conduyt_ai_insights, or conduyt_ai_next_actions, despite heavy overlap in the sibling list. Usage must be inferred entirely from the description's output list.

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 behavioral burden. It says what enriched fields may be returned, but does not disclose whether the tool mutates the contact record, where data comes from, whether it costs credits or has rate limits, or what permissions are needed.

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 and efficient: it states the capability, explains the basis, and names example returns in three short sentences. Nothing is notably wasted, though it could be slightly tighter.

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

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

For an AI enrichment tool with no annotations and no output schema, the description is thin on operational behavior, data sourcing, side effects, and privacy or permission implications. It gives some return-field examples but not enough for an agent to invoke it confidently in consequential workflows.

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

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

Schema description coverage is 100%, so all six optional parameters are already documented in the schema. The description adds only that enrichment is based on 'available details' and lists example return fields, which is useful context but does not clarify parameter combinations or whether at least one identifier is required.

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 states a specific resource and action: enriching a person/contact with additional information, and names example output fields like LinkedIn and Twitter. It is clearly distinguishable from generic contact CRUD siblings, though it does not explicitly differentiate itself from adjacent AI tools such as conduyt_ai_summarize_contact.

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 implies usage ('based on available details') but gives no explicit when-to-use, when-not-to-use, or alternative guidance. With siblings like conduyt_get_contact and conduyt_ai_summarize_contact, an agent gets no routing help.

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 exist, so the description carries full burden and does: permissions/tenant scope/visibility/audit all apply, token is single-use, expires in 5 minutes, is bound to caller and exact action set, any edit is refused, drafts are not sent, and resending a token replays rather than re-runs (replayed:true). This is unusually complete disclosure of side effects and idempotency semantics.

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

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

Front-loaded with the APPLY purpose and packed with operative detail in a compact block; nearly every clause carries decision-relevant information. Slightly dense as a single paragraph, but no sentence is 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 mutation tool with no annotations and no output schema, the description supplies what is missing: execution semantics, token lifecycle, idempotency/replay behavior, and the shape of key return signals (per-action result, replayed:true, inFlight:true). Nothing an agent needs to call it safely is absent.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema's token one-liner: single-use, 5-minute expiry, bound to caller and exact set, and that replay is safe. selectedIds widening prohibition and resume ordering are also reinforced in prose.

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

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

States a specific verb (execute/apply) and resource (the ready actions from a conduyt_ai_plan_actions result), and explicitly names the sibling that produces its input. An agent can distinguish this APPLY step from the planning tool without inspecting either schema.

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

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

Explicitly says when to use (after a plan, send the actions array plus token), how to narrow (selectedIds), how to resume (resumeIds after inFlight:true, only past resumableAt), and what not to do (never re-run automatically). The preconditions for resume are spelled out, not left to inference.

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 behavioral burden. It implies a read-only chronological feed, but does not explicitly state that it is read-only, whether results are paginated, how results are ordered beyond 'chronological,' what event types appear, or any permission requirements.

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

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

The description is a single, efficient sentence with the core concept front-loaded. It earns its place but could be marginally improved by fronting an explicit action verb rather than the nominal phrase 'AI activity feed.'

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

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

For a simple two-parameter read tool with complete schema coverage, the description is adequate. However, because there is no output schema and no annotations, it could do more to describe the returned event/insight shape and clarify the tool's relationship to the many AI-related sibling tools.

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

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

Schema description coverage is 100%, so both the 'limit' and 'since' parameters are already fully documented in the input schema. The description adds no parameter-specific detail beyond what the schema provides, which makes the baseline score of 3 appropriate.

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

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

The description clearly identifies a specific resource: an AI activity feed of AI-surfaced events and insights across the account. It is distinguishable from generic activity tools, though it never states an explicit action verb such as 'list' or 'retrieve' and does not name any sibling alternative.

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?

There is no explicit guidance on when to use this tool versus siblings such as conduyt_ai_insights, conduyt_ai_deal_insights, conduyt_ai_daily_brief, or conduyt_list_activities. The only usage signal is the tool name and the phrase 'AI activity feed,' leaving the agent to infer the appropriate context.

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

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

With no annotations provided, the description carries the full behavioral burden, and it does disclose meaningful traits: the 1000-contact ceiling, dedup on email/phone/both, and side effects on other resources (tagging, smart list creation, automation enrollment). It leaves out whether the operation is synchronous or batch, what happens when skipDuplicates is false, partial-failure semantics, and required permissions — all material for a bulk write.

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, front-loaded with the operation and the capacity limit, then the optional behaviors, then dedup. 'AI-powered' is the only filler; everything else maps to a callable capability.

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 nested-parameter bulk mutation with zero annotations and no output schema, the description covers purpose, limit, and dedup strategy but is thin on outcome semantics — the agent cannot predict what a partially failed import returns or what happens to duplicates when skipping is disabled. Adequate to start a call, not enough to predict its effects.

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

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

Schema coverage is 100%, so the nested options and contact fields are already documented in structured form, establishing a baseline of 3. The description adds a little meaning by calling out auto-tagging, smart list creation, automation enrollment, and the dedup strategy in prose, but contributes no syntax, format, or default detail beyond what the schema states.

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

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

States a specific verb and resource ('bulk contact import') plus a hard capacity limit, which separates it from conduyt_create_contact (single record) and conduyt_bulk_edit_contacts (mutation of existing records). It never names a sibling explicitly, so an agent must infer routing from the verb, but the intent 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 never says when to use this instead of conduyt_create_contact, conduyt_import_deals, or conduyt_bulk_edit_contacts, and it omits any prerequisite such as running conduyt_import_preflight first. The 1000-contact cap reads as a constraint, not usage guidance, so the agent gets no explicit when/when-not signal.

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 disclosure burden, and it omits the key behavioral facts: whether this only returns text or mutates a stored draft, whether anything is sent, and whether the result is persisted anywhere. It does convey the transformation scope (body rewritten, subject conditionally), but for an AI generation tool with zero annotation coverage that is thin.

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, front-loaded with the action and with zero filler. Slight redundancy between the opening sentence and the rewrite description, and the inaccurate 'optionally the subject' phrasing costs a point.

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

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

For an AI text-transform tool with no annotations and no output schema, the description should state what comes back (rewritten body only, or body plus subject) and whether the original draft is touched. Neither is covered, and the required-subject mismatch leaves the contract ambiguous.

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

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

Schema description coverage is 100%, so the baseline is 3; the one extra note, 'Pass instructions to steer the rewrite', reinforces the instructions parameter but adds nothing the schema example doesn't already convey. The description actively muddies things by calling the subject 'optional' while the schema lists it as required.

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?

A specific verb plus resource ('Improve an email draft', 'Rewrites the body ... for clarity, tone, and persuasiveness') tells an agent exactly what it does. It never distinguishes itself from the nearby siblings conduyt_ai_compose_email and conduyt_reply_suggestion, which also produce email text, so the agent must infer the boundary.

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?

'Improve an email draft' implies the usage condition—an existing draft rather than a blank compose—but the description never says so explicitly and offers no when-not guidance. With conduyt_ai_compose_email, conduyt_send_email, and conduyt_reply_suggestion in the same family, the routing decision is left to inference.

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 disclosure burden. It partially meets it by describing the shape of results per query type ('rows, total, metric, chart data, pivot'), which is genuinely useful. It never states that the tool is read-only, what permissions/API-key scope it needs (only hinted via 'this key can run'), or whether large reports are bounded — gaps that matter for a no-annotation 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 purpose is front-loaded in the first sentence and the enum enumeration follows, so the agent can stop reading once it finds its query type. The second sentence is a dense ~150-word run-on, but given 11 distinct query types there is little fat — each parenthetical carries real disambiguating content.

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

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

For a tool with 11 modes, nested objects, and no output schema or annotations, the description does substantial work: every query type is named with its output content, and windowing/paging behavior is called out. Remaining gaps are the read-only/safety profile and error behavior (the 409 on ambiguous report names lives only in the schema), which keep it from a 5.

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

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

Schema coverage is 100%, so all six parameters including nested report/dashboard/filters objects are already documented in the schema. The description reinforces the mapping (period/dateRange for saved_report and dashboard, page/perPage for saved_report, reps and sources) but largely restates what the schema's per-property descriptions already say. Baseline 3 applies.

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

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

States a specific verb ('Query') and resource ('AI-powered CRM insights') and then enumerates all 11 query types with parenthetical detail on what each returns. The purpose is unambiguous. It stops short of differentiating itself from overlapping siblings such as conduyt_run_report and conduyt_run_dashboard, so an agent cannot tell which tool to prefer when both could answer a 'run this saved report' request.

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?

Usage is implied by the query-type list — the agent can infer which enum value handles 'stale deals' or 'open/click rates' — and it names the optional windowing/paging for saved_report. But there is no explicit when-to-use-this-vs-alternative guidance despite heavy sibling overlap (conduyt_run_report, conduyt_run_dashboard, conduyt_agent_performance_report, conduyt_ai_deal_insights), and no 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?

No annotations exist, so the description carries the full behavioral burden. It does usefully imply a non-mutating read (it 'returns a prioritized list of suggested actions'), which matters given the sibling conduyt_ai_execute_actions, but it omits cost/latency of AI ranking, whether results are cached, whether the list is bounded, and any permission requirements.

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

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

Two short sentences, front-loaded with the core concept, with a parenthetical that usefully enumerates action types. The opening fragment 'AI-ranked next actions' largely repeats the tool name and could be folded into the substantive sentence.

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

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

For a single-optional-parameter read tool this is close to adequate, but with no output schema the description should say more about the returned list's shape (fields per action, ordering, length). As written, an agent knows the gist but not what it will actually receive.

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 one parameter and 100% schema description coverage, the schema already documents userId and its default to the authenticated user. The phrase 'for a user' in the description duplicates rather than extends that, adding no format or scoping detail 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?

States a concrete output: a prioritized list of suggested actions, with three illustrative categories (replies, deals, tasks). This is more than a restatement of the name. However, it never distinguishes itself from nearby AI siblings such as conduyt_ai_agenda, conduyt_ai_plan_actions, conduyt_ai_feed, or conduyt_reply_suggestion, so an agent cannot route confidently among them from this text alone.

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?

There is no when-to-use guidance, no exclusion of alternatives, and no stated relationship to conduyt_ai_execute_actions or conduyt_ai_plan_actions. The agent must infer that these are read-only suggestions rather than executable actions.

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 and does so: it declares the call is non-mutating, that resolution is scoped to records the caller can see, that results may come back with issues such as an ambiguous name, that the confirmationToken is single-use and bound to that exact action set, and that the actions array must be returned unmodified. This is exactly the behavioral context an agent needs to avoid corrupting the token contract.

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

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

Front-loaded with the verb and resource, and the safety/token contract follows immediately. It is a dense single flow with one long parenthetical list of action types; every clause earns its place, but the packing slightly hurts scanability.

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, so the description must explain returns and it does: resolved actions marked ready or with an issue, plus a single-use confirmationToken bound to that set. Combined with the three-parameter, fully documented schema, an agent has everything needed to call it correctly and to chain into execute_actions.

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

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

Schema description coverage is 100%, so dealId and contactId are already documented in the schema, and the description adds little param-specific detail beyond noting resolution is limited to visible records. It does effectively characterize `message` as free-form rep language via the quoted examples, but that is largely illustrative of purpose rather than parameter semantics. Baseline 3 is appropriate.

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

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

Specific verb+resource: turns a natural-language request into a preview of concrete CRM actions, with the exact action types enumerated (tasks, callbacks, notes, appointments, tags, stage moves, SMS/email drafts). The parenthetical example requests make the input domain unmistakable, and it is clearly distinct from conduyt_ai_execute_actions, which applies the plan.

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 it (plan/preview) and names the follow-up tool and the exact condition for using it: pass the unmodified actions array plus the single-use token to conduyt_ai_execute_actions. It also states a negative constraint (nothing is written here, drafts are never sent), leaving nothing to inference.

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 disclosure burden. It does add real behavioral context by describing the generated content (sentiment, key topics, recommended next steps), which tells the agent what to expect back. However, it omits the operation's nature (it is clearly a read/analysis call, but that is only inferred), whether it consumes AI credits, latency, and what happens if the contact has no interaction history.

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 compact sentences with no filler, and the substantive detail (analyzed sources and output fields) follows immediately. The leading phrase 'AI-powered contact summary' mildly restates the name, but the rest of the 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 single-input, no-output-schema analysis tool, the description covers the essentials: what it reads, what it returns, and by implication that it is non-mutating. Only minor gaps remain (credit cost, behavior on empty history), which are not fatal given the simple shape of the 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?

There is a single parameter and the schema description coverage is 100% ('Contact UUID to summarize'), so the schema already fully documents it. The description adds no format or sourcing guidance for contactId beyond what the schema supplies, which is the expected baseline-3 outcome when the schema does the work.

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 names a specific verb (summarize) and resource (contact) and enumerates the inputs it consumes (interactions, deals, activities) plus the output shape (sentiment, key topics, next steps). It is clear, but it doesn't explicitly distinguish itself from adjacent AI tools such as conduyt_ai_enrich_contact or conduyt_ai_insights, which an agent could easily confuse it with.

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?

Usage is only implied: 'analyzes all interactions, deals, and activities to generate a summary' suggests you call it when a synthesized view of a contact is needed. There is no statement of when to prefer this over conduyt_get_contact or the other AI insight tools, and no prerequisites or exclusions are given.

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

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

With no annotations, the description carries the full burden and does so: it discloses that nothing is persisted, that the response enumerates counts, matches, and warnings, and that execution is gated to human sessions and unavailable to API-key callers. These are exactly the traits an agent cannot derive from the schema and needs before calling.

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, front-loaded with the PREVIEW ONLY marker, then what it does, then what it returns, then the access restriction. Every sentence adds distinct information with no filler or repetition of schema content.

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

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

There is no output schema, and the description compensates by describing the return payload as counts, matches, and warnings. Combined with the non-persistence and access-restriction disclosures, an agent has everything needed to decide whether to call it and interpret the result.

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

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

Schema description coverage is 100%, so every parameter (contacts, tagIds, automationId, smartListId) is already documented in the schema, including the 1-500 contact bound. The description restates the same concepts (tagging, enrollment, smart list) at a high level without adding syntax, format, or failure semantics. Baseline 3 is appropriate when the schema does the work.

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 states a specific verb and resource: preview a bulk import of contacts with optional tagging, automation enrollment, and smart-list addition. It is unambiguous about being a preview rather than a mutation, which implicitly separates it from conduyt_ai_import_contacts. It never names that or any other sibling explicitly, so it stops short of full differentiation.

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 clearly states the operating context: agent/API-key callers can only preview, and actual execution requires a human session in the app. That tells the caller exactly what this tool can and cannot accomplish for them. It does not point to alternative tools (e.g. conduyt_import_preflight or conduyt_ai_import_contacts) for related needs, leaving that inference to the agent.

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 behavioral burden and does so well: it discloses that nothing is persisted, that the tool returns stale deals and what WOULD happen, and that mutating execution is restricted to human sessions. This is exactly the safety and side-effect context an agent needs before calling a preview 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 three sentences, front-loads the critical PREVIEW ONLY constraint, and wastes no words. It efficiently covers purpose, behavior, and restriction.

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 five-parameter preview tool with no annotations and no output schema, the description covers the essential non-schema details: no persistence, preview-only return content, and the restriction that agents cannot execute mutations. The schema fully covers parameter semantics, so no critical context is missing for correct invocation.

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

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

Schema description coverage is 100%, so the input schema already documents pipelineId, action, staleDays, tagId, and targetStageId. The description adds only high-level action context and does not provide parameter-level meaning beyond the schema, making the baseline 3 appropriate.

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

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

The description states a specific verb and resource: preview finding stale deals in a pipeline, with tagging, moving, notifying, or reporting actions. It clearly establishes the PREVIEW ONLY scope, which separates it from mutating siblings, though it does not explicitly name an alternative tool.

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

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

The description gives clear usage context: this is for previewing stale-deal cleanup, and executing a mutating action is intentionally restricted to a human session. It also states that agent/API-key callers can only preview, which is a strong when-not constraint. It does not explicitly direct users to sibling alternatives for related tasks.

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 behavioral burden and does well: it discloses that the operation is non-persistent, returns the matched count and what WOULD change, and that execution is restricted to human sessions. It stops short of describing all response details or error conditions, but the key safety and persistence behavior is explicit.

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 'PREVIEW ONLY' and three sentences cover purpose, return behavior, and execution restriction without waste. Every sentence contributes to correct tool selection or behavior understanding.

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?

There is no output schema, so the description must explain return behavior, which it does by stating it returns the matched count and what would change without persisting. It could say more about preview response shape or limit interaction, but the core preview semantics are complete for safe invocation.

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

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

Schema description coverage is 100%, so the schema already documents filter fields, action variants, and the limit parameter in detail. The description summarizes the action types (add/remove tag, assign user, update field) but adds no substantive meaning beyond the schema, which meets the baseline of 3 when schema coverage is high.

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 states a specific verb and resource: previewing contact segmentation by filter plus applying an action to the whole segment. It clearly frames the tool as PREVIEW ONLY and lists action categories, but it does not explicitly differentiate itself from sibling AI task tools such as conduyt_ai_task_import_and_enroll or conduyt_ai_task_pipeline_cleanup.

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 when the tool can be used by agents: preview only. It also states when execution is not allowed: 'Executing this is intentionally restricted to a human session in the app; agent/API-key callers can only preview.' This is a clear when-to-use and when-not-to-use boundary.

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 and does disclose the key operational fact: an owner/admin API key is required and other roles receive a 403. It also reveals the rolling-window semantics of the report. It stops short of stating rate limits, cost of the call itself, or whether the data is cached/delayed.

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: what it is, what it returns, what it needs. Zero filler and the access constraint is placed where it will be read before calling.

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 one-parameter read-only report with no output schema, the description covers purpose, returned content, window semantics, and auth failure mode — enough to call it correctly. Missing only response shape detail and pagination/limit notes.

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

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

Schema coverage is 100% — the only parameter (range enum 7/30/90 with a documented 30 fallback) is fully described in the schema. The description's 'rolling window' phrase adds only mild framing beyond that, so the baseline 3 is right.

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

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

States a specific resource and verb: an AI usage and budget report for the account, returning request counts and budget consumption. That contrasts well with the reporting/dashboard siblings (conduyt_dashboard, conduyt_get_user_stats), though it doesn't name any sibling explicitly.

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?

Use is implied (check AI request volume or remaining budget) but never stated as a trigger, and no alternatives or exclusions are offered. An agent can infer when it fits, but nothing directs it away from overlapping reporting tools.

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

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

With no annotations, the description carries the burden well: it discloses that the response contains exact current endpoint counts, that the catalog is the full REST surface, and that not every endpoint has an MCP tool. It stops short of explicitly stating read-only behavior, auth requirements, or response size/pagination, but the discovery framing implies a safe 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?

Three efficiently ordered sentences: purpose first, usage cue second, and the important coverage caveat/alternative last. No sentence is wasted.

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 zero-parameter, annotation-free discovery tool with no output schema, the description provides the key context an agent needs: call it first, expect endpoint counts and schemas, understand it covers the full REST surface, and know where to check MCP callability.

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

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

The tool has zero parameters, so parameter semantics is essentially N/A and the baseline is 4; the description correctly does not invent parameter details.

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 states a specific verb and resource ('Discover all Conduyt CRM API endpoints'), scopes it to 90+ domains with request/response schemas, and distinguishes it from the coverage sibling by noting the catalog covers the full REST surface while conduyt_mcp_coverage maps callable endpoints.

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

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

It explicitly says to 'Call this first' to learn what the CRM can do, and names the alternative (conduyt_mcp_coverage) for the precise question of which endpoints are callable through MCP tools versus API-only.

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 behavioral burden and discloses the key non-obvious effect: moving the contact's most recently updated open deal according to appointmentOutcomeStages. It also enumerates failure reasons (no_contact, no_deal, no_mapping, already_there, stage_move_failed), which is strong transparency. It does not mention permission requirements or reversibility, keeping it from a 5.

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

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

The description is front-loaded with the action and side effects, then the return shape and reason codes. It is dense but every clause adds useful information; it could be split for readability, but there is 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?

There is no output schema, so the description appropriately explains the return object and reason codes. It gives enough to call the tool correctly and interpret partial failures. Missing details such as permission requirements or explicit undo routing are minor for this complexity level.

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

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

Schema coverage is 100%, so the schema fully documents id, outcome, startTime, and endTime, including the rescheduled semantics. The description repeats the common outcome values but omits 'rescheduled' from its list, while the schema includes it; this is a minor inconsistency rather than an error, and the schema does the heavy lifting. Baseline 3 is appropriate.

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

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

The description states a specific verb (record), resource (appointment outcome), and the full side-effect chain: updating status plus moving the contact's most recently updated open deal to a mapped stage. The 'in one action' framing distinguishes this from generic update or multi-step alternatives, so an agent can identify it without opening siblings.

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

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

Clear context for when to use it: recording an outcome (completed, no_show, cancelled) with automatic deal-stage movement. It does not explicitly name when to avoid it or point to alternatives such as conduyt_appointment_outcome_undo or conduyt_update_appointment, but the combined-action framing gives sufficient selection guidance.

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

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

With no annotations, the description carries the full behavioral burden and does it well: it discloses the mutation's effects on both appointment status and deal stage, the critical guard that a manually changed stage is left alone, and that the response surfaces stageRestored and reason. It stops short of covering permission requirements or the error case where no outcome exists to undo.

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 with zero filler; the em-dash parenthetical carries the guard condition and response fields compactly. Every clause conveys operational information.

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

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

For a one-parameter undo mutation with no annotations and no output schema, the description covers the restored state, the conditional skip, and the response fields an agent needs to interpret. It leaves only minor gaps around permissions and the no-prior-outcome error path.

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

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

Only one parameter (id, 'Appointment UUID') with 100% schema coverage, so the schema fully documents it. The description adds no syntax or format detail for the id, so baseline 3 applies.

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

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

States a specific verb and resource — undo the last outcome recorded on an appointment — and spells out the concrete effects (status reverts, deal stage reverts). An agent can tell this apart from the forward conduyt_appointment_outcome without opening either schema.

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

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

The word 'Undo' plus 'the last outcome recorded' establishes when this applies: after an outcome was written to an appointment. It does not explicitly name conduyt_appointment_outcome as the alternative or spell out when-not to use it, but the context is clear and unambiguous.

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 behavioral burden and does substantial work: it discloses the 366-day span clamp, the start-vs-booked basis semantics, how reschedules are counted (attendee, in-app user, synced calendar), and notes that the report definition is returned as `definition`. It omits the read-only/safety profile and any indication of result size or rate limits, which is why it falls short of a 5.

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

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

It is front-loaded with the core definition and contains almost no filler, but it is effectively one very long semicolon-chained sentence, which makes the midpoint hard to parse. Slightly more structure (or splitting the breakdown enumeration out) would improve scanability without losing content.

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

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

There is no output schema, yet the description specifies the returned content well: status buckets, held/no-show outcome and show rate, cancellations, reschedules, upcoming, and all breakdown axes, plus the echoed `definition`. Remaining gaps are output volume/pagination and permissions, which matter for a report tool but are not addressed.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: it explains that basis=start is the default and what each mode means for the window, and that channel/lead-source groupings exist. The 366-day clamping behavior attached to from/to is not in the schema and is useful, though the `sources` filter values are left to 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?

It names a specific resource and mode ('Appointment report: every appointment whose time ... falls in the window') and enumerates the aggregation dimensions returned (status, assigned user, calendar/booking page, lead source, channel, day), which implicitly separates it from conduyt_list_appointments. It never names a sibling outright, so an agent must infer the reporting-vs-listing distinction, but the verb+resource 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?

Usage is only implied: the presence of a window, a dual 'basis' mode, and the 366-day clamp signal it is the analytics path, but there is no explicit 'use this when you want aggregates, use list_appointments when you want rows' or any prerequisite/auth guidance. An agent can infer the context but is given no exclusions or alternatives.

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

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

With no annotations, the description carries the full burden and mostly delivers: it discloses that date spans clamp to 366 days and that the applied definition is returned in a `definition` field. It does not mention permission requirements or cost/performance characteristics, but for a read-only report the disclosed constraints are the ones that matter.

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?

It is front-loaded with the core definition, but the middle parenthetical about passing an `attribution` object with utm_source/utm_medium/etc. describes how contacts are written by a different operation, not anything this tool accepts — with additionalProperties:false on the schema that risks steering an agent to supply parameters this report rejects.

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?

There is no output schema, and the description compensates by describing the return contents (per-group appointments booked, deals won, revenue so far) plus the definition echo and the 366-day limit. Combined with full schema coverage of the four inputs, an agent has enough to call 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 coverage is 100%, so the enum descriptions already define `group` and `touch`. The description reinforces the meaning by listing the touch fields (UTM source, medium, campaign, content, term, channel, landing page, referrer) and stating the first-vs-latest semantics, but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

The description names a specific resource (attribution of new contacts in a window) and states exactly what is computed: contacts grouped by first/latest touch and followed through to appointments, deals won and revenue. An agent can tell this apart from conduyt_funnel_report or conduyt_appointment_report without opening any schema.

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

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

Usage is implied by the content ('new contacts in the window', default last 366 days when both dates are omitted), but there is no explicit statement of when to choose this over the funnel, appointment or speed-to-lead reports in the sibling list. No prerequisites or exclusions are given.

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

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

Annotations are absent, so the description carries the full disclosure burden. It says 'all active enrollments' (scope) but says nothing about reversibility, what state paused enrollments enter, whether in-flight sends are affected, permission needs, or result of passing both IDs. For a batch mutation this is a substantial gap.

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

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

A single front-loaded sentence with no filler, correctly leading with the mutation and its scope. It is under-specified rather than bloated, so brevity is not the weakness here.

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

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

With no annotations, no output schema, two optional parameters, and two directly competing sibling tools, this description leaves too much unresolved for correct invocation. At minimum it should clarify pause-vs-stop semantics and the campaign-or-list targeting requirement.

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

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

Schema description coverage is 100% and both parameters are documented inline, so the schema does the heavy lifting and a baseline 3 applies. The description adds only that each ID scopes the pause to a campaign or smart list, with no guidance on precedence when both are provided or on omitting both.

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

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

States a specific verb and resource ('Pause all active enrollments') plus a scope ('for a campaign or smart list'), which is clear on its own. It does not distinguish itself from the near-identical siblings conduyt_batch_resume_enrollments and conduyt_batch_stop_enrollments, so an agent cannot tell from the text alone how 'pause' differs from 'stop'.

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 statement of when to pause versus resume or stop an enrollment, and no indication of prerequisites or scope limits. With zero required parameters, the description also never says that at least one of campaignId/smartListId must be supplied, leaving the invocation condition unstated.

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 behavioral burden. It indicates a state-changing operation ('resume paused enrollments') but does not disclose permissions, effects on already active enrollments, reversibility, or batch 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 a single front-loaded sentence with zero wasted words. It immediately states the verb, resource, and scope.

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

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

For a low-complexity batch mutation tool with two well-documented parameters, the description covers the core action and targeting. However, with no annotations and no output schema, it should ideally clarify mutation side effects, permission needs, or the expected result.

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

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

Schema description coverage is 100%, so both parameters are already documented in the input schema. The description reinforces the campaign-or-smart-list targeting but does not clarify whether exactly one of the two optional parameters is required or add constraints beyond the schema.

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

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

The description uses a specific verb, 'Resume,' with a clear resource, 'paused enrollments,' and scopes it to a campaign or smart list. It is easily distinguishable from sibling tools such as conduyt_batch_pause_enrollments and conduyt_batch_stop_enrollments.

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 that this tool is used when paused enrollments should be resumed, and it distinguishes campaign vs. smart list targeting. However, it does not explicitly state when to use this instead of pause/stop tools or what prerequisites must be met.

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 exist, so the description carries the full burden. It does disclose the single most important trait — irreversibility ('Cannot be undone') — which is real added value, but it says nothing about what happens to contacts mid-sequence, whether any prerequisite permissions or IDs are needed, or what the call reports back.

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, no filler, with the destructive nature front-loaded and the irreversibility warning immediately after. Nothing redundant with the tool name is repeated at length.

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

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

For an irreversible bulk mutation with zero annotations and no output schema, the description covers the safety warning but is thin on operational detail: no requiredness guidance for campaignId vs smartListId, no note on partial-failure semantics, and no indication of how to observe the result.

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

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

Schema description coverage is 100%, so the three parameters are already documented, including the 'reason' default. The description reinforces that scope is either a campaign or a smart list, but never states that one of the two identifiers is effectively required despite the schema listing zero required parameters — the one gap the description could have closed.

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

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

States a specific verb (stop) and resource (enrollments) plus the two scoping modes: campaign or smart list. The word 'Permanently' implicitly separates it from the sibling batch_pause_enrollments, but no sibling is named explicitly, so an agent must infer the distinction.

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 it (when enrollments must be ended for good rather than paused) but never states the alternative or exclusion explicitly. With siblings like conduyt_batch_pause_enrollments and conduyt_unenroll_from_sequence present, a routing sentence would have been cheap and valuable.

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 usefully discloses that deletion is "soft" and requires contacts:delete, but it omits batch-size limits, partial-failure behavior, recoverability details, and what the operation returns.

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

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

Two short sentences, front-loaded with the core action and followed by the permission requirement. There is no wasted prose.

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 one-parameter bulk mutation with no output schema and no annotations, the description is minimally adequate: it names the operation, soft-delete semantics, and required permission. It nonetheless leaves out important operational context such as batch limits, failure handling, and differentiation from the matching-based bulk delete sibling.

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

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

Schema description coverage is 100%, and the single parameter is already documented as "Contact UUIDs to delete." The description adds no syntax, formatting, or batching detail beyond the schema baseline.

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 states a specific verb and resource: "Soft-delete many contacts in a single call." It clearly indicates bulk deletion, but does not distinguish this ids-based operation from the sibling conduyt_bulk_delete_contacts_matching or the single conduyt_delete_contact tool.

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 only usage-related information is the permission prerequisite "Requires contacts:delete." There is no explicit guidance on when to use this tool versus deleting one contact or using the matching/filter-based bulk delete sibling.

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 and delivers: 409 expected_total_mismatch and 409 not_all_editable refusal conditions, 50,000/422 cap, keptWithAppointments retention, token binding and 2-hour expiry (403 continuation_*), and required contacts:delete permission plus active subscription.

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

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

Purpose is front-loaded and the dense continuation/error protocol is well-ordered. Length is justified by the multi-phase operation, though the filter/expectedTotal re-explanation overlaps with schema text.

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

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

For a complex, two-phase bulk mutation with no output schema, the description still documents return signals (done, remainingIds, continuation, busy, keptWithAppointments) and error codes, leaving nothing an agent needs to call 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 coverage is 100% and the field descriptions already label ids/continuation as 'Continuation' and filter/expectedTotal as 'First call'. The description adds sequencing context (filter must equal what conduyt_list_contacts would take; expectedTotal equals meta.total) but largely restates the schema, so baseline 3 applies.

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

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

States a specific verb (soft-delete), resource (every contact a list filter matches), and scope (across pages), and anchors it to the concrete UI action 'Select all N matching'. An agent can immediately tell this apart from id-based conduyt_bulk_delete_contacts.

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 two-phase flow is spelled out precisely: FILTER CALL with filter+expectedTotal, then continuation with ids+token, plus busy/true/403 handling. It does not explicitly compare against the sibling conduyt_bulk_delete_contacts (id-based delete), so the alternative routing is only implied.

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

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

With no annotations, the description carries the burden and does so unusually well: it discloses the required 'dnc' scope, that an unrestricted key does not imply it, the exact 403 failure mode, and contact-ownership limits for restricted keys. It does not cover bulk-specific behavior such as batch size caps, partial-failure semantics, or whether a removal fully restores dialability, so it stops short of a 5.

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

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

Three sentences, front-loaded with the verb and resource, then permissions, then the read alternative — a sensible decision-ordering for an agent. The long scope sentence is dense but every clause (explicit, admin-granted, unrestricted key insufficient, 403) prevents a distinct failure.

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 4-parameter bulk mutation with no annotations and no output schema, the description covers purpose, permission gate, and alternative well enough to call it safely. The remaining gap is the absence of any indication of the response shape (counts of applied vs skipped contacts), which matters for a bulk operation with no output schema.

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

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

Schema coverage is 100%, so tier, action, reason, and contactIds are already documented in the schema, including the enum meanings and the skip-without-phone rule. The description adds only the framing that contactIds is plural and the marks come in two tiers, which is baseline value.

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

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

States a specific verb pair (add/remove), the exact resource (Do-Not-Contact / litigator mark), and the scope (many contacts), which separates it from single-record DNC siblings purely by the word 'many'. It also labels the operation's nature as a compliance action, so an agent knows the stakes before reading the schema.

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

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

Gives an explicit when-to-use and an explicit when-NOT-to-use with the named alternative: checking whether a number is already blocked should go to conduyt_get_contact or the dnc-status read. That is exactly the routing decision an agent needs, and the ownership caveat adds a second precondition.

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 and does disclose the key behavioral facts: it is a mutation, it fans a single updates object across all ids, and it needs contacts:edit. However, it says nothing about atomicity, partial-failure behavior when some ids are invalid, or the size limit on the ids array – material concerns for a bulk write 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 compact sentences with zero filler; the core behavior is front-loaded, followed by the alternative-tool routing and the permission requirement. 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 two-parameter tool with complete schema coverage and no output schema, the description covers purpose, alternative, and auth. The remaining gap is bulk-write edge behavior (partial failures, id limits), which keeps it from a 5.

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

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

Schema coverage is 100% and both parameters are fully described in the schema, including the customFields merge rule. The description's 'one updates object → all ids' reinforces the same-value semantics but adds no syntax, limits, or field-level detail beyond what the schema already provides, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('Apply the SAME field changes to many contacts at once') and makes the payload semantics explicit ('one updates object → all ids'). It also names the sibling tool that handles the contrasting case, so an agent can distinguish it from conduyt_bulk_update_contacts without opening either schema.

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

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

Explicit when-to-use (identical changes across many contacts) and when-not-to-use (different values per contact), routing the agent to conduyt_bulk_update_contacts. It also adds the prerequisite 'Requires contacts:edit', so the agent knows the auth gate before calling.

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 behavioral-disclosure burden. It usefully states that this is a bulk mutation and requires deals:edit, but it does not explain overwrite semantics, partial-failure behavior, reversibility, or what the response contains.

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 front-load the core behavior, then immediately provide the sibling alternative and permission requirement. Every sentence contributes directly to correct tool selection or invocation.

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 two-parameter bulk mutation tool with a fully described schema, the description supplies the key usage distinction, an example, and the required permission. It is nearly complete, but without annotations or an output schema it still leaves return behavior and partial-failure handling unmentioned.

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

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

Schema description coverage is 100%, so both ids and updates are already documented in the input schema, including an example for updates. The description reinforces that one updates object is applied to all ids, but adds little syntax or constraint detail 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 states a specific verb and resource: bulk-edit deals by applying the same field changes to many deals at once. It also distinguishes this tool from the sibling conduyt_bulk_update_deals, which is for different values per deal, so an agent can identify the correct bulk operation without opening the schemas.

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

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

It explicitly says when to use this tool: when the SAME field changes apply to many deals, e.g. reassigning a set of deals to one user. It also names the alternative for different per-deal values and states the required permission, giving clear selection guidance.

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

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

With no annotations, the description must carry the behavioral burden, and it does disclose the required scope (contacts:edit) and that the operation is batched into one call. However, it says nothing about idempotency (what happens if a contact already has the tag), partial-failure semantics, or whether the operation is reversible.

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

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

Two short sentences, scope constraint front-loaded, prerequisite trailing. No wasted words and nothing buried.

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 two-parameter bulk mutation with a fully described schema and no output schema, the definition covers purpose and auth adequately. The remaining gap is failure/idempotency behavior, which matters for a bulk write but is a smaller omission than missing parameter or scope information.

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

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

Schema description coverage is 100% and both required parameters are documented in the schema, so the baseline is 3. The description's phrase 'one tag ... many contacts' correctly signals tagId is singular while contactIds is plural, adding slight clarity but no format or constraint detail 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?

States a specific verb+resource+scope: add ONE tag to MANY contacts in a single call. This implicitly separates it from conduyt_add_tags (non-bulk) and conduyt_add_deal_tags (deals), but no sibling is named explicitly, so differentiation still requires inference.

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?

Usage context is only implied by 'bulk' and 'single call'; there is no explicit when-to-use versus conduyt_add_tags or conduyt_bulk_untag_contacts, and no guidance on batch-size limits. The permission prerequisite ('Requires contacts:edit') is the one concrete usage gate provided.

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

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

No annotations are supplied, so the description carries the full burden. It does add real context: this is a bulk mutation gated by the contacts:edit permission. But it does not disclose what happens if a contact lacks the tag (idempotent vs error), whether partial failures are reported, or any batch-size limit.

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 action and followed by the permission prerequisite. 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 two-parameter bulk mutation with no annotations and no output schema, the description covers purpose and permission but leaves the agent guessing on error/partial-failure semantics and any batch limits — gaps that matter for a destructive multi-record write.

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

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

Schema coverage is 100%, so both parameters are already documented in-schema. The description only implies the cardinality ('one tag', 'many contacts'), adding virtually nothing beyond the schema's own 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?

States a specific verb+resource+scope: 'Remove one tag from many contacts in a single call.' The 'one tag / many contacts' framing cleanly separates it from conduyt_bulk_tag_contacts (add) and conduyt_add_tags.

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 'Requires contacts:edit' line is a useful prerequisite, but the description never routes the agent to alternatives — it does not point to conduyt_bulk_tag_contacts for the inverse, or to single-contact tooling for narrower cases. Usage is only implied by the scope wording.

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 usefully discloses the required permission scope (contacts:edit) and the per-row id requirement, but says nothing about partial-failure semantics, atomicity, size limits, or what the call returns — meaningful gaps for a bulk mutation.

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 plus a permission clause, with the differentiating scope front-loaded and zero filler. Every clause earns its place.

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

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

For a bulk mutation tool with no annotations and no output schema, the definition covers what it does, when to use it, and the auth requirement. It stops short of describing result/error behavior, which an agent executing many per-row updates would benefit from knowing.

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

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

Schema coverage is 100% and the single 'updates' parameter is already documented down to the example shape in the schema. The description restates the per-row id+fields idea, adding emphasis but no new syntax or constraints beyond the structured field.

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

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

States a specific verb (apply), resource (field changes per contact), and the distinguishing scope (DIFFERENT changes per row in one call). This contrasts directly with conduyt_bulk_edit_contacts, so an agent can tell the two bulk tools apart without reading either schema.

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

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

Explicitly names the alternative (conduyt_bulk_edit_contacts) and the condition that selects it ('same change across many'). Routing is unambiguous.

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 behavioral burden alone. It usefully discloses that this is a per-row bulk mutation requiring deals:edit and that each row must carry its own id and fields, but it does not explain partial-failure behavior, validation rules, atomicity, or what the response contains.

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 waste. The core distinction and permission requirement are front-loaded, and the alternative is mentioned only where it helps route the agent correctly.

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 bulk mutation tool with no annotations and no output schema, the description covers the essential model (per-row id plus fields), the permission requirement, and the sibling alternative. However, it leaves important operational context unstated, such as how failures are handled when only some rows succeed and whether updates are transactional.

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

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

Schema description coverage is 100%, and the schema already documents that updates is an array of per-deal objects requiring id plus fields, including an example. The description reinforces the same meaning by emphasizing different changes per row, but adds little parameter-specific detail 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 states a specific verb and resource: applying DIFFERENT field changes per deal in one call, with each row carrying its own id plus fields. It directly contrasts with conduyt_bulk_edit_deals for the same change across many, so an agent can distinguish the two tools without opening either schema.

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

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

It explicitly names the alternative (conduyt_bulk_edit_deals) and the condition that selects it: when the same change applies across many deals. It also states the required permission deals:edit, giving a clear precondition for invocation.

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 disclosure burden. 'Get' implies a read-only operation, and 'live availability' adds useful behavioral context that the data is current/real-time. It does not mention permissions, rate limits, or return shape, but for a zero-parameter read tool the description provides moderate transparency.

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

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

The description is a single efficient sentence with the core action front-loaded ('Get the routing roster'). Every clause contributes useful detail about contents and purpose, 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 zero-parameter read tool with no output schema, the description is largely complete: it explains what the roster includes and its role in call-flow/ring-group configuration. It could be slightly more complete by noting whether the result is a list, pagination behavior, or whether DIDs are always present, but the core operational need is covered.

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

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

The tool has zero input parameters, so per the scoring baseline this dimension defaults to 4. The description correctly adds no parameter detail because none exist.

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

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

States a specific verb and resource: 'Get the routing roster'. It adds distinguishing detail that the roster contains 'members with DIDs and their live availability' and is specifically for 'call-flow and ring-group steps'. This helps separate it from generic user/contact listing tools, though it does not explicitly name a sibling alternative.

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?

Usage is implied by the phrase 'the people call-flow and ring-group steps can ring', which signals the context in which this roster is relevant. However, there is no explicit when-to-use guidance versus related tools such as conduyt_list_users or conduyt_list_ring_groups, and no 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?

With no annotations, the description carries the full burden. It usefully discloses a real behavioral constraint ('Spans clamp to 366 days'), the default when dates are omitted, and that a `definition` object accompanies the result. It omits permission/auth requirements, whether results are paginated or row-limited, and how heavy the response can be for a 366-day window across five breakdown dimensions.

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 defining scope ('every call in the window, whatever carried it') followed by the metric/dimension inventory; the 366-day clamp and `definition` return are stated compactly at the end. The dense metric list is information the agent needs to judge relevance, not 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?

With no output schema, the description does the work of explaining what comes back by enumerating the metrics and noting the `definition` field. For a five-parameter, multi-dimension analytics tool the coverage is strong; only response shape/size and auth expectations are left unaddressed.

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 already 80%, so baseline is 3, and the description adds genuine meaning on top: it maps 'transport' values to real systems (in-app dialer over Twilio, click-to-call Twilio, Project Blue), clarifies the direction split, and pins day/hour bucketing to the account's timezone. It adds nothing further on `userId` or the ISO date formats beyond what the schema states.

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

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

The description names the resource precisely ('Unified call report: every call in the window') and scopes it across all transports, then enumerates the exact metrics and breakdown dimensions returned. A reader knows exactly what this produces, though it never names the sibling it competes with (e.g., conduyt_list_calls for individual call records or conduyt_agent_performance_report).

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

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

Implicit guidance comes from 'with the dialer analytics' definitions' and the metric list, which signals this is the aggregated analytics view. But there is no explicit when-to-use/when-not, no mention of which sibling to pick when the agent wants raw calls (conduyt_list_calls) or per-agent breakdowns (conduyt_agent_performance_report).

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

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

With no annotations, the description does substantial work: it states that processed contacts are irreversible and claimed-but-unprocessed contacts return to pending. That is valuable side-effect disclosure, though it does not mention permissions, rate limits, or response 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?

Two tight sentences, front-loaded with the action and followed by the critical side effects. Every sentence adds necessary information without waste.

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

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

Given no annotations and no output schema, the description covers the most important operational behavior: partial cancellation semantics and lack of undo. It could say more about what the response looks like, but an agent can call it correctly from this.

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

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

The single parameter is fully documented by the schema as the run id, and the description adds no further semantics. Baseline 3 is appropriate when schema coverage is 100%.

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 states a specific verb (Stop) and resource (a queued or running Run Batch), making the tool's action clear. It does not explicitly differentiate from sibling tools like conduyt_create_batch_operation or conduyt_list_batch_operations, but the core purpose is unambiguous.

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

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

It implies usage for queued or running batches, but gives no explicit when-not conditions or alternatives such as how this differs from stopping enrollments. The context is adequate but not directive.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses the destructive effect on parked/queued/failed webhook logs, the edge case of no log existing, the barrier standing without resolution, the duplicate SMS risk with 'resend' and its guard (acknowledgeDuplicateRisk), and the full set of HTTP error conditions. This is rich behavioral context beyond what any structured field provides.

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 dense paragraph with front-loaded purpose and scoping, followed by resolution semantics and error code handling. Every sentence contributes information, though the length and semicolon-heavy structure could be slightly harder to scan than a bulleted form.

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 (mutation with error branching and duplicate risk), no output schema, and complete parameter coverage in the schema, the description is complete: it covers permissions, behavior, resolutions, edge cases, error codes, and response fields. An agent has everything needed to invoke 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 100%, so the input schema already documents all three parameters including the resolution enum and the duplicate-risk flag. The description largely repeats that information (e.g., 'omitted = cancel only', 'skip = assume delivered, advance', 'resend needs acknowledgeDuplicateRisk') without adding new semantic detail about parameter formatting or interplay. Baseline 3 is appropriate when the schema does the heavy lifting.

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 states a specific verb (cancel), resource (drip enrollment's send barrier), and scope (whole barrier including webhook logs), and distinguishes it from other enrollment operations by describing exactly what gets cancelled. An agent can tell this is a targeted mutation for a stuck send barrier.

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

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

It explicitly specifies when to use the tool (cancelling a barrier), how to use it with and without a resolution, what each resolution does, and how to handle error responses (e.g., 409 step_already_sent → use 'skip'). It also notes permissions (admin or owner, drip-enrollments scope). This is clear when/when-not guidance.

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

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

With no annotations, the description carries the full burden and discloses the critical behaviors: the barrier stands without a resolution, 'skip' advances without sending, 'resend' may duplicate an SMS and requires acknowledgement, and the endpoint requires admin/owner auth with the webhooks scope. It also lists specific error conditions (404, 409 in-flight, not-cancellable, step-already-sent) and response fields, which is unusually 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?

The description is front-loaded with the purpose and scope, and the dense detail is largely necessary for a destructive tool with nuanced resolution modes. It is longer than ideal but every sentence (error codes, response fields, auth requirements) serves a distinct decision or behavioral point.

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?

Even without an output schema or annotations, the description explicitly lists the returned fields (resolution, resendScheduled, advanceScheduled, handedBack, markersResolved, barrierStanding), covers auth and error handling, and explains barrier semantics. An agent has everything needed to invoke and interpret 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 coverage is 100% and the schema already explains the id source, resolution enum meanings, and acknowledgeDuplicateRisk requirement. The description reinforces the consequences of each resolution choice but adds little parameter-level semantics beyond what is already documented in the schema.

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

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

The description states a specific verb (cancel), a precise resource (webhook log), and a narrow scope (ONE parked/queued/failed log of a drip send whose outcome was unconfirmed). It distinguishes this from generic webhook management and from barrier cancellation, making the purpose immediately clear.

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

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

It gives explicit guidance on when to omit resolution versus use 'skip' or 'resend', including consequences for the barrier and duplicate risk. It does not name alternative sibling tools, but the behavioral decision tree is clear enough that an agent knows how to choose among the resolution modes.

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

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

No annotations are provided, so the description must carry the behavioral burden. It usefully discloses the categories of information returned (tier, scopes, rate limits, usage stats) and implies read-only inspection via "Check," but it does not explicitly confirm that the operation is non-mutating or describe authentication requirements beyond using the current API key.

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

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

The description is a single front-loaded sentence with zero wasted words. The dash-separated list efficiently identifies the main return categories without unnecessary elaboration.

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

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

For a parameterless read-only diagnostic tool with no output schema, the description is complete enough: it tells the agent what the tool reports and that it operates against the current API key. No further schema or annotation detail is required to call 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?

The tool takes zero parameters, and the schema is empty. The baseline for zero-parameter tools is 4, and no additional parameter semantics are needed.

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

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

The description uses a specific verb ("Check") and a clearly scoped resource ("what the current API key can do"), then enumerates exactly what is reported: tier, scopes, rate limits, and usage stats. No sibling tool performs permission introspection, so the agent can easily identify this as the diagnostic/authorization tool.

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 states what the tool does but gives no explicit guidance on when to invoke it versus alternatives, nor does it mention prerequisites or common scenarios such as troubleshooting before attempting mutations. The usage is only implied by the purpose.

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 and does well: it discloses the resulting status value, that the server stamps completedAt, that task.completed automations/webhooks fire, and the required permission. It doesn't state behavior when the task is already done or whether the action is reversible.

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

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

Two compact sentences, front-loaded with the action and immediately followed by side effects and permission requirement. 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?

Covers mutation semantics, side effects, and auth for a one-parameter tool, which is more than adequate. The only gap is that no output schema exists and the description doesn't say what is returned on success.

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?

Single required 'id' parameter with 100% schema description coverage; the schema already explains it's the task UUID to mark done. The description adds nothing beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource ('Mark a task done') and adds the disambiguating note that this is the idiomatic 'complete' action, distinguishing it from a generic update_task with a status field.

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?

Calling it 'the idiomatic complete action' implicitly routes the agent here instead of update_task, and the required scope (tasks:edit) is stated. No explicit when-not or sibling name is given, so it falls short of a 5.

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

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

No annotations are provided, so the description carries full burden. It does not state permission requirements, whether the activity is immediately visible, side effects, or what the response contains — significant gaps for a mutation tool.

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

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

Two short, front-loaded sentences with no waste; however, the second sentence adds little beyond what the schema already states.

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 mutation tool with no annotations and no output schema, the description is minimal — it covers purpose but omits return behavior, permissions, and the meaning of the required vs optional parameters, though the rich schema compensates for the latter.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description only adds the vague note that it 'can be linked to a contact,' which the schema covers more precisely.

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

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

States a specific verb ('Log') and resource ('activity') and enumerates concrete variants (call, meeting, note, custom event), distinguishing it from the sibling list_activities.

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?

Implicitly conveys that this is the tool for creating a new activity entry, but gives no explicit when-to-use versus list_activities or guidance on when linking to a contact is appropriate.

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 of behavioral disclosure. It only states the creation action and a time format constraint, but omits what happens on success (return value), required permissions, side effects, or idempotency. This leaves significant behavioral gaps.

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

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

Two sentences with zero waste: the first states the action, the second provides a critical constraint. Information is front-loaded and appropriately sized.

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

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

For a tool with 10 parameters, no annotations, and no output schema, the description is too sparse. It fails to explain return values, permissions, or other context needed to invoke the tool confidently. The schema covers parameters, but behavioral completeness is lacking.

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

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

Schema description coverage is 100%, so the schema already documents all 10 parameters. The description only repeats the timezone offset requirement for startTime/endTime, which is already in the schema, adding no new semantic 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 states a specific verb and resource: 'Create a new appointment.' This clearly distinguishes it from sibling tools like list, get, update, and outcome. No ambiguity about 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 offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or how it relates to other appointment tools (e.g., update, list). Only the tool name implies its purpose.

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 at all, the description carries the full burden, yet it discloses almost no behavior beyond required fields. It doesn't say whether the created automation is a draft requiring publish_automation, what permissions are needed, what happens to invalid trigger conditions, or what the response contains. Only the resolve_names hint adds workflow 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?

Three short, front-loaded sentences with no filler: creation statement, prerequisites, and the resolve_names workflow hint. Every sentence carries actionable 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?

The rich parameter schema compensates for the thin description on inputs, but the tool has no annotations and no output schema. For a create tool in a family that includes publish_automation, the agent is left unsure whether the result is a live automation or a draft and what creation returns, which is a material 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 100%, so the schema itself documents all 11 parameters, including enums and conditional requirements. The description only restates the two required fields and adds a helper pointer for actions, so the baseline 3 is appropriate.

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

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

The description states a specific verb and resource ("Create a new automation"), clearly identifying the create operation among siblings like update_automation, publish_automation, and list_automations. It doesn't explicitly differentiate itself from those siblings, so it falls just short of a 5.

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 names the required fields (name and trigger event) and explicitly directs the agent to use conduyt_resolve_names before building actions, which is concrete usage guidance. It does not state when to prefer this over update_automation or publish_automation, keeping it at a 4 rather than 5.

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

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

With no annotations provided, the description carries the full behavioral burden and does so richly: no undo, background processing with progress and cancel, admin/owner role and active subscription requirements, 409 expected_total_mismatch on moved sets, id freezing, and task-specific side effects like source overwrite and skipping inactive reps. This is unusually complete for a destructive batch 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 dense but front-loaded and every clause carries useful information. The long parenthetical task mapping is efficient but makes it harder to scan than a short structured list would be.

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 9-parameter asynchronous batch tool with no output schema and no annotations, the description covers the critical context: task semantics, contact selection modes, limits, polling, authorization, and a specific error condition. Nothing essential for correct invocation appears 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 coverage is 100%, so the baseline would be 3, but the description adds substantial meaning beyond the schema: it maps each operation to its params, explains round-robin userIds constraints and inactive-rep skipping, clarifies set_source overwrites and set_status preserves won-deal status, and defines expectedTotal against meta.total from conduyt_list_contacts. This materially improves invocation correctness.

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 states a specific verb and resource ('Queue a Run Batch') and enumerates the exact tasks supported, so the tool's purpose is unmistakable. It does not explicitly differentiate itself from sibling bulk tools such as conduyt_bulk_tag_contacts or conduyt_bulk_edit_contacts, which keeps it from a 5.

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 gives clear operational guidance: choose contacts via contactIds, filterPayload, or filter+expectedTotal, and poll conduyt_get_batch_operation because the run is backgrounded. It also names required roles and subscription. However, it does not explicitly say when to use this tool rather than a sibling bulk 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, the description carries the behavioral burden and does disclose the required calendar:edit permission and the Zoom-specific side effect (one Zoom meeting per booking requiring conduyt_zoom_connect). It does not describe the response, slug uniqueness, error behavior, or other mutation consequences an agent might need.

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 dense sentence but front-loads the action, required fields, and optional notable fields. For a 17-parameter tool it is compact and contains little waste, though its semicolon-heavy list is less scannable than it could be.

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

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

The description covers the essential invocation details: required fields, key optional capabilities, and the permission requirement. Given the high parameter count, no annotations, and no output schema, it leaves gaps around return values and several optional parameters, making it adequate rather than complete.

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

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

Schema description coverage is 65%, so many parameters are already explained in the schema. The description adds some meaning by identifying title/slug/userId/durationMinutes as required and labeling userId as the host, but it also largely repeats schema-documented concepts and omits several optional parameters.

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

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

The description gives a specific verb and resource ("Create a booking page") plus the endpoint POST /api/v1/booking-pages. It clearly distinguishes creation from the sibling list/get/update booking-page tools by naming the required create fields.

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 states the minimum required fields and the calendar:edit permission, which gives useful invocation context. However, it does not explicitly say when to use this vs. update_booking_page or get_booking_page, nor does it name alternatives for editing an existing page.

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