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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write-but-not-destructive nature is structurally known. The description adds the account-level scope and the list of allowed types, but it does not disclose side effects, duplicate-name behavior, limits, or response behavior. It is consistent with annotations and adds minor context, but not rich behavioral detail.

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 short and front-loaded with the core action, and the second sentence usefully enumerates supported types. The first sentence largely restates the tool name/title, but the overall length is appropriate 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 simple creation tool with full schema coverage and non-conflicting annotations, the description is minimally sufficient to identify the operation and the allowed type values. However, it omits any mention of what a successful creation returns, whether names must be unique, and when to prefer this over sibling tools. No output schema exists, so a little more context about the operation's result would improve completeness.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description's mention of types ('text, number, date, datetime, boolean') duplicates the enum in the schema without adding format details, constraints, or examples. This is the baseline score for a fully covered 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: 'Create a new custom field in the ManyChat account.' It is clear that this tool is for creating field definitions rather than, for example, tagging subscribers or setting field values. However, it does not explicitly distinguish itself from sibling tools like manychat_set_field, so it stops just short of perfect clarity.

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

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

The description gives no guidance on when to use this tool versus alternatives such as manychat_create_tag or manychat_set_field. There is no mention of prerequisites, exclusions, or scenarios where a sibling tool would be more appropriate. Usage context is left entirely 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?

Annotations already indicate this is a mutating operation (readOnlyHint=false) but not destructive. The description adds that a new tag is persisted and that the response includes the tag with its ID. It does not mention duplicate-name behavior or permissions, but for a simple create operation, the description provides adequate 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 one clear sentence that states the action and the return value with no filler. The essential behavior is front-loaded and every word contributes.

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 create tool with annotations already covering the mutation profile, the description is largely complete: it specifies the resource, the input, and the output. It could add a note about duplicate tag names or error conditions, but these are minor gaps for this simple 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%, with the single 'name' parameter already documented as 'Tag name to create'. The description repeats this same meaning without adding extra format, uniqueness, or validation details. Baseline 3 is appropriate here.

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

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

The description uses a specific verb ('Create') with a clear resource ('a new tag in the ManyChat account') and states the result includes the created tag's ID. This clearly distinguishes it from sibling tools like list_tags (retrieval) and tag_subscriber (association).

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 verb 'Create' implies usage when a new tag is needed, but there is no explicit guidance about when to prefer this tool over alternatives, such as manychat_list_tags for existing tags or manychat_create_custom_field for fields. Usage context is implied rather than 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?

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds that it 'returns matching subscribers' but does not disclose matching semantics such as exact vs. partial matching or result limits, which would add useful behavioral context.

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

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

The description is two short, direct sentences with no filler. It front-loads the purpose and immediately states the expected result.

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

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

For a simple two-parameter read-only lookup, the description plus fully documented schema and readOnlyHint is mostly sufficient. It states that matching subscribers are returned, though it does not specify response shape or pagination; these are minor gaps given the tool's simplicity.

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

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

Schema description coverage is 100%, with both field_name and field_value already documented. The description adds no further meaning about parameter behavior, so the baseline score of 3 is appropriate.

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

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

The description states a specific action ('search') on a specific resource ('subscribers') and the distinguishing criterion ('custom field value'). This clearly separates it from sibling tools like manychat_find_subscriber or manychat_get_subscriber.

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 usage context is implied: use this when you need to find subscribers by a custom field value. However, it does not explicitly state when not to use it or name alternatives such as manychat_find_subscriber.

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

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

The annotation readOnlyHint=true already covers the safety profile, so the description does not need to restate that this is a read operation. The description adds that matching subscribers and their IDs are returned, but it does not disclose match semantics, result limits, pagination, or exact-vs-partial matching 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 two short, focused sentences. It front-loads the action and immediately specifies what the caller gets back, with no filler, repetition, or unnecessary schema duplication.

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 lookup with no output schema, the description provides enough information to call the tool and understand the high-level result. It could be more complete by clarifying exact-match versus partial-match behavior and any result limits, but those gaps are relatively minor given the tool's simplicity.

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

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

The schema already fully documents the single 'name' parameter with type, minLength, and a description. The tool description's 'by name' only restates what the schema already says, adding no new parameter-level 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 uses a specific verb ('search') and resource ('subscribers') and clearly states the search criterion ('by name') along with the key result (matching subscriber IDs). It does not explicitly contrast with siblings like manychat_get_subscriber or manychat_find_by_field, so sibling differentiation is implicit rather than explicit.

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

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

No guidance is given about when to use this tool versus alternatives, and no exclusions or prerequisites are mentioned. An agent must infer from the tool name and sibling names that this is the name-based search option.

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

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

The readOnlyHint annotation already signals a safe read operation. The description adds useful context by specifying what the response contains: tags, custom fields, and channel data. This is especially valuable because no output schema is provided.

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

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

The description is one concise sentence that front-loads the main action and includes relevant response details with no filler. Every phrase earns its place.

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

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

For a single-parameter read-only lookup tool, the description covers what the tool does, how it is identified, and what the response will include. There is no output schema, so the explicit mention of included subscriber data is sufficient for an agent to call this 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 only parameter, subscriber_id, is fully described in the schema as 'ManyChat subscriber ID'. The description restates that lookup is 'by ID' but does not add any new meaning beyond the schema, 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 uses a specific verb-resource pairing: 'Get full subscriber info by ID'. It also names key data included (tags, custom fields, channel data), making the tool's purpose distinct from sibling lookup tools like manychat_find_subscriber.

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 phrase 'by ID' clearly indicates this is the correct tool when a subscriber ID is already known, and it implies alternatives like find_subscriber or find_by_field are for locating subscribers without an ID. However, it does not explicitly state when not to use this tool or name an alternative.

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

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

The readOnlyHint annotation already establishes this is a safe read operation. The description adds useful context about the account-wide scope and the fields returned, but does not mention pagination, response envelope, or any potential rate-limit 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?

A single, focused sentence states the action, scope, and expected return fields without any filler. The key information is front-loaded.

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

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

For a simple parameterless list operation with a readOnlyHint and no output schema, the description provides enough information: the resource, scope, and expected fields. No additional context is 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?

The tool has zero parameters and the schema is empty, so the description cannot meaningfully add parameter semantics. This matches the baseline of 4 for parameterless tools.

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 and resource: 'List all custom fields in the ManyChat account' and names the returned data (IDs, names, types). This clearly distinguishes it from sibling list tools like manychat_list_tags and manychat_list_flows.

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

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

No guidance is given on when to use this tool versus alternatives such as manychat_create_custom_field or manychat_set_field. The read-only nature is only implicit in the verb 'List' and the readOnlyHint annotation, not explained in the description.

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

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

The readOnlyHint annotation already covers the safety profile, so the description does not need to restate it. The description adds the account-wide scope and output fields, but does not disclose potential pagination, rate limits, or ordering behavior, which would add value beyond the annotation.

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, well-structured sentence clearly states the action, scope, and returned fields without any filler. Every part 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?

With zero parameters and a read-only annotation, the description provides everything needed to select and invoke the tool correctly: what it lists, at what scope, and what fields are returned. No output schema is needed because the description names the key output attributes.

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 zero parameters, so the baseline is 4. The description sensibly focuses on output rather than parameter details, since there is nothing for the agent to configure.

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

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

The description uses a specific verb ('List') and resource ('automation flows in the ManyChat account') and specifies the returned fields (IDs, names, statuses). This clearly distinguishes it from sibling list tools like manychat_list_tags and manychat_list_custom_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?

The description implies usage when a user needs automation flows and their basic metadata, but it does not explicitly mention when not to use it or point to alternatives. Sibling names provide context, but the description itself lacks direct 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?

The readOnlyHint annotation already establishes this as a safe read operation. The description adds useful scoping by listing the categories included, but it does not mention response format, pagination, or any other behavioral details. Given the annotation coverage, this is acceptable but not exceptional.

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

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

A single, front-loaded sentence that states the action, resource, scope, and included categories without any filler. Every word earns its place.

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

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

For a parameterless, read-only list tool with a clear scope, the description is complete. There are no parameters to document, the readOnlyHint covers safety, and the sibling tools provide enough context for distinguishing use cases.

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

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

The tool has zero parameters and the schema coverage is 100%, so no parameter documentation is needed. The description appropriately focuses on the resource being listed rather than on 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 uses a specific verb ('List') and a clear resource ('growth tools'), and even enumerates what counts as growth tools: widgets, comment triggers, ads JSON. This distinguishes it from sibling list tools like manychat_list_flows and manychat_list_custom_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?

The description makes clear this is the tool for retrieving all growth tools in the ManyChat account. It does not explicitly name alternatives or exclusions, but the resource name and the sibling tool names make the appropriate usage context obvious.

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

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

The annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds account-level scope and the output fields, which is useful context, but it does not disclose pagination, rate limits, or authorization requirements. This is acceptable for a simple zero-parameter list tool but not exceptional.

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

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

The description is a single, front-loaded sentence with no filler. It states the action, scope, and output in a compact form, making it easy for an agent to parse quickly.

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-only list tool, the description covers what an agent needs to know: what is listed, at what scope, and what fields are returned. With no output schema present, the explicit mention of 'IDs and names' fills the key gap. No critical information 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?

There are no parameters, so the schema provides no meaningful constraints. Because the tool takes zero inputs, the description does not need to explain parameter semantics; the baseline of 4 applies and the description accurately clarifies the output focus.

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

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

The description clearly states a specific action ('List all tags') and identifies the resource ('ManyChat account') plus the returned fields (IDs and names). This distinguishes it from sibling read tools like manychat_list_custom_fields and mutation tools like manychat_create_tag.

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: call this tool when you need the full set of tags and their identifiers. However, it does not explicitly say when not to use it or how it relates to alternatives such as manychat_create_tag or manychat_tag_subscriber, leaving routing 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?

The readOnlyHint annotation already communicates non-mutating behavior, and the description's 'Get' wording aligns with it. The description does not add extra behavioral context such as auth requirements, rate limits, or data freshness, though that is less critical for a simple read-only info 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 a single concise sentence with the action front-loaded and no redundant words. Every part 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 parameterless read-only tool, the description is complete: it states the action, resource, and key output fields. The readOnlyHint annotation covers the safety profile, and no output schema is needed to understand what the tool returns.

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

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

The tool has zero parameters and 100% schema coverage, so there is no parameter ambiguity. Per the 0-param baseline, the description does not need to add parameter details; mentioning the returned fields adds minor extra clarity.

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

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

The description uses a specific verb ('Get') and a clear resource ('ManyChat account/page info'), then lists the included content (name, status, connected channels). No sibling tool covers page-level metadata, so it is easily distinguished from the list, subscriber, and send 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?

The description implies usage when account/page-level information is needed, but it provides no explicit guidance about when to prefer this over alternatives or any exclusions. For such a self-contained tool, the implied context is adequate but not fully 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?

Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries the behavioral burden. It usefully discloses the 10-message cap, the 24-hour messaging window for Instagram/WhatsApp, and the side-effect capabilities such as tag/field actions and external callbacks. It stops short of describing permissions, rate limits, or error behavior, but these are not critical 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?

Three sentences with no wasted words. The core purpose and content capabilities are front-loaded, followed by channel support, the message cap, and the 24-hour window caveat. Every sentence carries useful 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 tool with a complex nested schema, the description provides the key operational context: rich content types, supported channels, the 10-message limit, and the important 24-hour messaging window. A minor gap is the lack of any mention of return values or error semantics, since no output schema exists, but the schema covers all parameter details.

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

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

Schema description coverage is 100%, so the input schema already documents every parameter thoroughly. The description does not add parameter-level meaning beyond what the schema provides; it only summarizes the message types at a high level, which is the correct baseline for full schema coverage.

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

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

The description states a clear action and resource: 'Send rich messages to a subscriber' and immediately enumerates the supported content types (text, images, videos, audio, files, gallery cards, buttons, quick replies, actions, external callbacks). This makes the tool's purpose specific and distinguishes it from siblings like manychat_send_text, manychat_send_flow, and manychat_send_sequence.

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

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

The description gives clear context for when to use this tool: for rich, multi-format messages with full control, up to 10 messages per call, across Instagram, WhatsApp, and Messenger. It does not explicitly name alternatives or say 'use manychat_send_text for simple text only,' so exclusions are missing, but the intended use case is clearly 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?

Annotations already indicate this is not read-only and not destructive. The description adds the flow-triggering behavior and the prerequisite to list flows first, but does not disclose side effects such as actually delivering content or starting an automation chain. This is adequate but leaves room for more behavioral context.

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

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

Two short sentences with no filler. The main action is front-loaded, and the prerequisite is stated clearly in the second sentence. 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 tool with only two required, fully documented parameters and annotations covering the read/destructive profile, the description is largely sufficient. It tells the agent what action to take and how to obtain the required flow ID. Lacking is any note on return behavior or side effects, but the low complexity and schema coverage make this a minor gap.

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

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

Schema description coverage is 100%, with both subscriber_id and flow_ns already documented. The description's 'from manychat_list_flows' instruction adds procedural context, but it mostly repeats what the flow_ns parameter description already states, so there is little extra semantic value beyond the schema.

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

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

The description clearly states a specific action—'Trigger a specific flow for a subscriber'—making the tool's purpose unambiguous. It identifies the flow resource and subscriber target, and the mention of manychat_list_flows helps orient the agent, though it does not explicitly contrast this with the send_text/send_content/send_sequence siblings.

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

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

The description gives a useful prerequisite: 'Use manychat_list_flows to get flow IDs first.' This implies when this tool is needed (after fetching flow IDs) but does not explicitly state when to prefer this over the other send_* tools or provide exclusion criteria.

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

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

The description adds useful behavioral context beyond the annotations: steps are sent in order, each step can contain messages, actions, quick replies, and delays. However, it does not explicitly state that this sends live messages to a real subscriber or that tag/field actions mutate subscriber data, and the annotations only say the operation is not read-only and not destructive.

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

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

Three sentences with no fluff: the first states the primary action, the second summarizes step composition, and the third gives a concrete use case. It is front-loaded and every sentence earns its place.

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

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

The tool is complex, but the rich input schema already covers parameter constraints and structure. The description provides a sufficient high-level model of how the sequence behaves. It could mention response/error behavior, but since there is no output schema, the absence is not a critical gap for correct invocation.

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

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

The input schema has full 100% description coverage, so the schema already documents all parameters and their meanings. The description mentions messages, actions, quick replies, and delay at a high level, which aligns with the schema but does not add new parameter-level detail. Baseline 3 is appropriate.

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

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

The description clearly states the action ('Send a multi-step message sequence to a subscriber') and names the main resource (subscriber and steps). It communicates the tool's purpose well and sets it apart from simpler send tools by emphasizing multi-step composition, but it does not explicitly name sibling alternatives like manychat_send_flow or manychat_send_content.

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

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

It says 'Use this to create automated conversation flows programmatically,' which gives a clear when-to-use context. It does not provide explicit exclusions or compare itself to sibling tools, but the use case is specific enough for an agent to route to this tool.

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

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

Annotations only indicate this is not read-only and not destructive. The description adds that it can optionally include buttons, quick replies, and auto-tag, which is useful. However, it does not mention constraints like messaging windows, rate limits, or what the API returns, so behavioral transparency is adequate but not rich.

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

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

The description is only two sentences long, front-loads the core action, and contains no filler. Every sentence contributes either a functional summary or routing guidance.

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

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

For a simple send tool, the description plus 100% schema coverage covers the call mechanics well. However, there is no output schema and the description does not explain return values or messaging-window implications, leaving some context gaps for an agent deciding whether this tool is appropriate.

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

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

The input schema already provides descriptions for 100% of the 7 parameters. The description's mention of 'buttons, quick replies, and auto-tag' maps to parameters but adds no new semantic detail beyond what the schema already states, 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?

The description uses a specific verb ('send') and names a clear resource ('a text message to a subscriber'). It also explicitly contrasts itself with manychat_send_content, so an agent can distinguish this tool from its 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?

It frames itself as a 'quick shortcut' for simple text messages and directly instructs agents to use manychat_send_content 'for more complex messages.' This provides explicit when-to-use guidance with a named alternative.

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

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

Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds a meaningful behavioral constraint beyond annotations: the target field must already exist, implying failure if it does not. It does not detail overwrite semantics or error behavior, but for a simple setter this is adequate.

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, the first front-loads the core purpose and the second adds the key constraint. There is no redundant wording or 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 simple three-parameter mutation with no nested objects and no output schema, the description covers the essential precondition (existing field) and the schema covers parameter meanings. It does not state what happens on error or what the response contains, but this is a minor gap for such a straightforward 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%, with each parameter already documented ('Custom field name', 'Value to set for the field', 'ManyChat subscriber ID'). The description adds no additional semantic detail beyond mapping the action to those parameters, so the baseline of 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?

Description states a specific action ('Set a custom field value') on a specific resource ('for a subscriber') with a precise method ('by field name'). The phrase 'The field must already exist' clearly distinguishes this from the sibling create_custom_field 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 sentence 'The field must already exist' provides a clear precondition and implies this tool is not for creating fields, which differentiates it from create_custom_field. However, it does not explicitly name alternatives or state when not to use this tool, so it stops 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?

Annotations already convey that this is a non-read-only, non-destructive operation, and the description adds the precondition but doesn't cover error cases, duplicate-tag behavior, or response effects. This is adequate but not rich behavioral disclosure.

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

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

Two short sentences with no filler; the main action is front-loaded and the precondition earns its place. Nothing extraneous.

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 mutation with basic annotations, the description plus schema covers the essentials needed to call the tool. It stops short of stating what happens if the tag doesn't exist or whether the operation is idempotent, which would make it fully complete.

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

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

The schema already documents both parameters with 100% coverage. The description adds meaning by clarifying that tag_name must reference an already-existing tag, which is useful semantic context beyond the raw schema.

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

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

The description clearly states the action: add a tag to a subscriber by tag name. It also gives the key precondition that the tag must already exist, which helps distinguish it from related siblings like manychat_create_tag and manychat_untag_subscriber.

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 communicates when the tool is valid by requiring an existing tag, and thus implicitly suggests creating the tag first if needed. It doesn't explicitly name sibling tools or state when not to use it, so it falls just 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?

The readOnlyHint=false annotation already indicates mutation, and destructiveHint=false indicates non-destructive behavior. The description restates the removal action but adds no extra behavioral context such as idempotency, behavior when the tag is not assigned, or side effects.

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

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

The description is a single, compact sentence with no filler. It leads with the action and includes the key targeting detail, so every word earns its place.

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

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

For a two-parameter mutation with full schema coverage and annotations declaring non-read-only/non-destructive behavior, the description is sufficient for basic invocation. It lacks alternative routing and edge-case behavior, but those are already reflected in the usage guidance and behavioral transparency scores.

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

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

The schema provides 100% parameter coverage, so the description does not need to compensate. 'By tag name' modestly reinforces the tag_name parameter but adds no formatting, constraints, or semantic details beyond the schema.

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

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

The description uses a specific verb ('Remove') and identifies the resource ('tag from a subscriber'), with 'by tag name' clarifying what identifies the tag. It clearly conveys an untag operation, though it does not explicitly distinguish it from the sibling manychat_tag_subscriber 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?

No guidance is provided on when to use this tool versus alternatives such as manychat_tag_subscriber or manychat_list_tags. The intended use is implied by the verb, but there are no explicit exclusions, prerequisites, or routing conditions.

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