Nitrosend

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

Adds real disclosure beyond the annotations: it tells the agent the tool never sends despite destructiveHint=true, and — critically — that replace clears omitted audience/schedule while patch preserves them. That is exactly the kind of irreversible-effect warning an agent needs before calling a destructive 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?

Front-loaded and free of filler; every clause carries routing or mutation information. The telegraphic style ('follow exact next_call', 'patch preserves omissions') is efficient but requires the agent to already know the surrounding mode model.

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 35-parameter nested-object tool with no output schema and 49% schema coverage, the description is thin. It covers routing and the destructive replace semantics but omits the intent/next_call loop, idempotency and versioning expectations, and what a draft response looks like.

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

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

Schema description coverage is only 49% across 35 parameters, so the description does need to compensate. It clarifies composition_mode=intent, the patch/replace contract (campaign_id, confirm), and audience/schedule clearing, but says nothing about body, goal, sections, theme, idempotency_key, validate_only, or if_version beyond what the schema already 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?

Opens with a specific verb+resource+scope: 'Draft email/SMS broadcasts; never sends.' That single clause separates it from nitro_send_message and nitro_compose_flow, which are named explicitly. It stops short of stating what the create/patch/replace modes do as a whole, leaving the full purpose of a 35-param composer partly implicit.

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

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

Explicitly routes three sibling cases: automation to nitro_compose_flow, transactional to nitro_send_message, creative email to composition_mode=intent with 'follow exact next_call'. It also states patch-vs-replace conditions (patch preserves omissions; replace needs campaign_id+confirm). It gives no guidance on the remaining composition_mode values or when to choose create over draft/validate.

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 destructiveHint and openWorldHint, while the description adds that replace affects the whole graph and patch preserves other nodes. It does not explain confirmation effects, irreversibility, or the side effects of publishing a live/paused flow.

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 short and mostly front-loaded, but telegraphic fragments like 'Live/paused flow saves publish' are ambiguous and reduce clarity. There is little wasted text, yet the structure is note-like rather than explanatory.

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

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

For a destructive 24-parameter nested flow composer with no output schema, the description omits most invocation details and return/publish semantics. It provides critical mode hints but is not complete enough for confident 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 description maps composition_mode=intent, replace's flow_id/confirm/draft revision requirement, and patch behavior, which is useful. But with 24 parameters at 46% schema coverage, most inputs such as goal, facts, steps, trigger, source_text, and lifecycle_key remain unclarified, so the description does not compensate for the low 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 fragments imply flow saves/publish and creative email use, but never clearly state whether the tool creates, replaces, or patches a flow. Sibling differentiation exists through 'Go live: nitro_control_delivery', yet the overall purpose remains inferential.

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 conditional guidance for creative email, replace, and patch, and names nitro_control_delivery for go-live. However, it does not explain when to choose create vs replace vs patch, nor when to use this tool over siblings such as nitro_compose_campaign.

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 mutability, idempotency, and non-destructiveness, so the description adds the real value: from_email must be an authorized, ready, brand-owned identity, and test_email_recipients of [] clears the list. Still missing is what happens with omitted parameters (partial update vs reset) and what reading returns, which matters for a tool that claims to 'read' despite readOnlyHint=false.

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 action and the sibling routing rule front-loaded; no filler. Slight cost is the 'Read or configure' hedge at the start, which could be sharpened.

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, all-optional mutation tool with no output schema, the description covers routing and identity constraints but omits update semantics (are unspecified fields preserved?), what a read invocation returns, and any error/validation behavior around unready identities. Adequate but with clear gaps.

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

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

Schema coverage is 75%, and the description adds a genuine constraint on from_email beyond the schema text: it selects an authorized, ready, brand-owned sending identity. It reinforces the clearing semantics of test_email_recipients, though it says nothing about the undocumented reply_to parameter.

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

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

Names a specific verb and resource: reading/configuring sender defaults and test recipients, and points at nitro_get_status for readiness. It distinguishes itself from the status sibling but not from other configuration siblings like nitro_configure_providers or nitro_set_brand_kit, and 'Read or configure' leaves the tool's primary mode slightly ambiguous.

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 one useful routing rule ('Use nitro_get_status for readiness') and one selection rule for from_email. It does not say when to use this tool versus nitro_configure_providers, nitro_select_brand, or nitro_select_account, nor when calling it purely to read defaults 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?

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds essentially nothing beyond them: it does not warn that reconfiguring may overwrite existing BYO credentials, does not say the tool is credential-scoped, and does not reconcile the read-only 'status' mode with a tool flagged 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?

A single tight sentence with the primary action front-loaded, which is appropriate sizing for a 5-parameter tool. The trailing 'or check connection status' is slightly compressed but wastes no words.

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

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

There is no output schema, so the description could have said what configure confirms or what a status check returns; it does neither. With full schema coverage and rich annotations the gap is survivable, but the description is thinner than the tool's mutation semantics warrant.

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%, including enums for operation and provider, so the schema already documents every parameter. The description contributes no syntax, format, or conditional-requirement detail (e.g. when region vs. api_secret is needed), 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 and resource ('Configure API-key email providers') and names the two operating modes (configure vs. status). It is distinguishable from most siblings, but it never explicitly differentiates itself from the nearby nitro_configure_account or nitro_get_status, so it falls 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 phrase 'or check connection status' implies the two usage modes, and the operation enum mirrors that split, but there is no explicit guidance on when to choose this tool over nitro_configure_account, nitro_manage_domains, or nitro_get_status. Usage 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 establish destructiveHint=true, readOnlyHint=false, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The description usefully adds that restarting a paused flow forces a choice about contacts already in progress and that revision_id asserts the current draft, but it stays silent on the irreversibility of delete/cancel 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?

Three short sentences, front-loaded with the core approve/control action and followed by caveats. Nothing is padded, though the brevity comes at some cost to coverage.

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

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

For a 10-parameter, multi-operation destructive tool with no output schema, the description is thin: it omits the operation set and the consequences of destructive branches (delete, cancel). Annotations cover the safety dimension and the schema covers parameters, so it is serviceable, but not fully adequate for this complexity.

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

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

With schema coverage at 80% and rich enum descriptions (operation, resume_mode, idempotency_key, confirm), the schema carries most of the load, so 3 is the baseline. The description adds marginal value by tying resume_mode to 'a choice for contacts already in progress' and revision_id to the draft assertion, but does not clarify the remaining 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 partial verb+resource ('Approve or control delivery') but only names the approve path, leaving the other nine operations (reject, live, schedule, pause, resume, cancel, archive, restore, delete) unstated. 'After review' loosely positions it relative to nitro_review_delivery, but 'control delivery' is broad enough that an agent cannot tell from the prose alone what the tool actually covers.

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?

Implied sequencing is present ('after review', and the paused-flow restart caveat), which suggests when the tool is invoked in the delivery lifecycle. However, there is no explicit statement of when NOT to use it, nor a routing hint toward siblings like nitro_review_delivery or nitro_send_message, so selectability rests on 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 declare it non-read-only but idempotent and non-destructive; the description adds the crucial behavioural fact that the default is a dry-run preview and that persistence requires explicitly setting preview_only=false plus a name. That default-writes-nothing nuance is exactly the kind of context annotations cannot convey. It stops short of explaining idempotency_key or how segment_id alters behaviour.

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, zero filler, and the primary behavioural fact (preview by default) is front-loaded. Nothing is restated from the title or schema.

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 takes a recursive filter tree, an optional segment_id, and an idempotency_key, yet the description never says whether segment_id updates an existing segment, how idempotency_key is used, or what the preview returns. With no output schema and 20% parameter coverage, a two-sentence description leaves material gaps for a tool of this complexity.

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

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

With only 20% schema description coverage, the description compensates by explaining preview_only's default and the conditional requirement that name is needed to persist — a constraint the schema does not encode (name is not listed as required). However the required, complex 'filters' tree and segment_id/idempotency_key receive no additional meaning beyond the schema text.

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 (define/preview/persist) and resource (filtered contact segment), and the preview-vs-persist split is clear. It does not, however, differentiate itself from near-neighbours like nitro_search_contacts or nitro_manage_audience, which an agent may consider for overlapping contact-filtering work.

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 a concrete rule for the two modes ('preview_only defaults true; set false and provide name to save'), which is real when-to-use guidance for the persist path. But it never names an alternative tool or says when this tool is preferable to searching or managing audiences, so tool selection is still 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and closed-world scope, so the safety profile is fully covered. The description adds that the response includes trends, benchmarks and recommendations, which is genuinely beyond the annotations, but it says nothing about auth scope requirements or how scope/entity_id affect the result.

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 tight sentence with zero waste, but its brevity is achieved by omitting needed detail rather than by disciplined editing. It is appropriately front-loaded.

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

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

With three parameters, a scope enum that changes what entity_id means, and no output schema, the description should explain the scope/entity relationship and the shape of returned insights. It instead gives a generic one-liner, leaving the agent to reverse-engineer invocation from the schema.

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

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

Only entity_id carries a schema description; scope and period rely on bare enums, giving 33% coverage. The description mentions no parameters at all, so the critical dependency that entity_id is required for flow/campaign/message scopes and only valid there is left entirely to the schema's single note.

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 email analytics') and names the payload (trends, benchmarks, recommendations), which tells an agent what class of tool this is. It does not differentiate from siblings such as nitro_review_delivery or nitro_get_status, which also read performance data, so the agent gets no routing signal.

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 use this tool versus alternatives, no prerequisites, and no exclusions. The agent must infer from the name alone that this is the analytics-reporting path rather than delivery review or status checks.

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, idempotentHint=true, destructiveHint=false, so the safety profile needs no repetition. The description adds nothing beyond that — no indication of what the memory contains, its scope ('brand' vs account), size, or whether retrieval is cheap.

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 words, front-loaded and waste-free, so it passes the conciseness test. The terseness crosses into under-specification: every sentence earns its place because there is only one, and it carries too little.

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 parameters and no output schema, the description is the only channel for explaining the return value, and it does not. An agent cannot tell whether it receives free-text brand facts, structured attributes, or an empty string, nor whether a prior nitro_select_brand call is required.

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, so the baseline is 4; there is nothing for the description to disambiguate. It does not, however, note that the brand must already be selected via nitro_select_brand.

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 verb 'Read' plus resource 'brand memory' names a specific resource, and the sibling nitro_set_memory hints at the write counterpart. However, 'memory' is never defined — what is stored, whether it is per-brand or per-account, and what comes back are all left opaque.

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 when-to-use guidance, no exclusions, and no acknowledgment of the nitro_set_memory sibling it obviously pairs with. The agent must infer that this is the retrieval half of a read/write pair.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds value by enumerating the data categories returned, but does not say whether the response is aggregated, whether it reflects cached vs live state, or what 'readiness' and 'recommendations' actually mean.

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; every item in the list is a distinct data category. The dense enumeration borders on a laundry list, but 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?

With no output schema, the description carries the burden of describing return values, and it does enumerate the categories of data the agent will receive. It stops short of describing the shape or relative importance of those fields, but for a zero-arg read tool it is close to sufficient.

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

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

The tool takes zero parameters, which is the baseline-4 case — there is nothing for the description to disambiguate at the input layer, and the empty schema is self-explanatory.

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 (get) and enumerates the concrete payload: account context, sender identity, dashboard links, readiness, onboarding status, recommendations. That is far more informative than the name alone. It does not, however, distinguish itself from the only other read-oriented sibling, nitro_get_insights, or from nitro_select_account / nitro_select_brand, which touch adjacent account state.

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 alternatives, no prerequisite (e.g. must an account be selected first?), and no exclusion. The presence of nitro_get_insights, nitro_select_account, and nitro_select_brand in the sibling list makes the omission meaningful — an agent cannot infer from the description which read tool to reach for.

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?

Beyond the annotations, it discloses real side effects: new contacts with email subscribe both channels while phone-only do not, existing subscriptions stay unchanged, and CSV resource=leads creates unverified inventory. That is valuable context the annotations don't provide. It stops short of explaining dry_run semantics or idempotency behavior, keeping it out of the top band.

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 compact but written as telegraphic fragments ('CSV upload/finalize', 'Limits: status guardrail or GET /v1/my/imports/spec') with no clear lead sentence, opening instead on a second-order detail (inline max 100). Density comes at the cost of readability.

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

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

For a 10-parameter, nested, no-output-schema import tool, it covers the two main workflows and side effects but omits dry-run behavior, idempotency, and what CSV finalize returns. Adequate but with clear holes 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?

With only 40% schema coverage across 10 parameters, the description partially compensates by explaining options.list_ids, the resource enum, the upload flow and the 100-record inline cap. It leaves dry_run, idempotency_key, parser, columns, and import_id unexplained, so meaningful gaps remain.

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 identifies the operation and its two modes (inline records vs CSV upload/finalize) and the lead-vs-contact resource distinction, which an agent can map onto the tool name. It lacks a clean front-loaded 'Import contacts' statement, but the specific mechanics still distinguish it from siblings like nitro_search_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?

It gives some conditional guidance ('contact list read-back requires options.list_ids', 'read with nitro_query(entity:leads,filters.import_id)') and points at GET /v1/my/imports/spec for limits. However, it never says when to pick this over nitro_ingest or nitro_manage_audience, so sibling 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?

The annotations already establish that this is a read-only, idempotent, non-destructive operation, so the description does not need to repeat that. It adds useful pagination/truncation context via next_calls, but omits command-specific behavior, defaults, prerequisites such as reply_context_digest, and return expectations.

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

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

The description is two sentences, front-loaded with the core purpose, and contains no filler. The second sentence earns its place by adding a pagination behavior hint, though the overall brevity is under-specified for a 31-parameter tool.

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 multi-command tool with 31 parameters, no output schema, and low schema description coverage, the description is far too thin. It gives only a basic read framing and one pagination hint, leaving command semantics, parameter roles, defaults, and result shape largely unexplained.

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

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

The tool has 31 parameters with only 45% schema description coverage, and the required command enum is central to invocation. The description explains neither command selection nor the meaning of any input parameter, and next_calls appears to be output guidance rather than schema semantics.

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

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

The description states a read verb with a queue/mailbox resource, making the broad purpose clear and distinguishing it from mutating inbox siblings. However, it does not cover the eight command modes such as thread retrieval, message-body retrieval, attachments, and validate_reply, so the full purpose remains underspecified.

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 guidance is to follow next_calls for older or truncated thread content. There is no explanation of when to use this tool versus sibling tools, and no guidance on choosing among its commands, such as list_queue, list_mailbox, get_thread, or validate_reply.

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 disclose destructive=true and openWorld=true. The description adds that compose reuses an open thread with the recipient, but it does not explain what destructive commands affect, whether actions are reversible, or how idempotency and dry_run behave. For a tool containing quarantine, spam classification, and sender-policy mutations, this is a significant behavioral 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?

The description is two sentences, front-loaded with the capability list and then compose constraints. There is no wasted wording, though the brevity is arguably too extreme for a 29-parameter tool.

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-command, 29-parameter destructive tool with no output schema, the description is far too thin. It does not explain return values, command-specific prerequisites, idempotency, dry_run semantics, or the behavior of most mutating commands.

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 59% across 29 parameters. The description states compose requires inbox_id, to, subject, and body and broadly maps action categories to command families, which adds some meaning beyond the schema. But command-specific parameter requirements remain largely undocumented for most of the 12 commands.

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 and several verbs (compose, reply, reserve attachments, triage, set sender policy, read state, contact linkage), so the agent knows it is an inbox action surface. However, it omits several enum commands such as mark_handled, request_human, release_to_agent, mark_quarantine, classify_spam, and send_reply_test, and it does not clearly distinguish this tool from siblings like nitro_send_message or nitro_inbox.

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 when-to-use or when-not-to-use guidance, and no alternatives are named. The only conditional instruction is that compose requires inbox_id, to, subject, and body; the agent must infer how to choose among the 12 commands and against 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?

Annotations only declare the generic write/open-world/non-destructive profile; the description goes further by naming the accepted MIME types, the 10 MB ceiling, the two-step upload handshake, and the return contract of a durable email URL capped at 1200px wide. It does not cover failure modes or what happens to existing assets on re-ingest, which keeps it off 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?

Two sentences: the first front-loads the action, formats, size cap, and accepted sources; the second states the return value. Nothing is repeated from the schema and nothing is padded.

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, zero-required tool with nested objects and no output schema, the description should say more about how to choose among the source paths (mutual exclusivity is only implied by 'or') and about the purpose of the unscoped kind/filename/content_type fields. The return value is described sufficiently for an agent to use 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?

With only 22% schema coverage across 9 parameters, the description carries real weight and does the most important job: clarifying that the four image sources are alternative entry points and that image_file is a ChatGPT attachment object. However, it leaves kind, filename, content_type, and the description/alt-text parameter entirely unaddressed, so substantial gaps remain.

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 ('Store a brand image') and immediately constrains it with supported formats and a 10 MB size limit. It also enumerates the four mutually exclusive input paths (image_file, image_data, image_url, upload then signed_id), so an agent knows exactly what the tool consumes and produces without opening 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?

It clearly frames the usage context — ingesting a brand image for email delivery, with the 'upload then signed_id' pattern spelled out as a two-step flow and image_file labeled as the ChatGPT attachment path. There are no explicit exclusions or named alternatives, but no sibling tool competes for this job, so the routing signal is strong enough.

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 destructiveHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds essentially no behavioral context about deletion confirmation, dry-run behavior, idempotency, or prepaid validation requirements beyond what the schema already says.

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 only two sentences with no filler, and the bulk-operation alternative is easy to spot. The first sentence is a bare noun list rather than a front-loaded purpose statement, but the description is not bloated.

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

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

For a destructive, multi-operation tool with a nested params object, the description is quite thin and does not orient the agent to the nine operations. The detailed schema and destructive annotations fill much of the gap, but the description itself does not complete the picture.

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 80%, so the schema already documents most parameter meaning, including the nested params object. The description adds only a small hint about custom fields living under attributes.data and routes bulk operations elsewhere, which is marginal added value.

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

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

The description enumerates audience-related resource domains — contacts, subscriptions, lists, events, segments, tags — but does not state a specific verb or explain the multi-operation nature of the tool. It is enough to infer the broad domain, but it does not clearly distinguish the tool from siblings like nitro_define_segment or nitro_search_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?

It explicitly routes bulk adds and unsubscribes to nitro_import_contacts, which is useful. But there is no guidance on when to use this tool versus the other audience-related siblings, nor on choosing among its nine operations.

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?

Beyond the annotations (destructiveHint, idempotentHint, openWorldHint), the description discloses that write operations need operator confirmation, must be polled, that prepaid funds are a separate track, and that no live presented-credential rail exists. This is meaningful behavioral context a caller cannot get from the annotations alone.

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, front-loaded sentences with no wasted text; the primary read operations come first and the write caveats follow. The telegraphic style is dense but every clause carries 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 an eight-operation, nested-parameter, destructive tool with no output schema, the description is incomplete: it never explains status, plans, checkout_status, or funding_purchase_status, nor what polling returns. The safety and approval guidance is present, but the operation catalog is only partially 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?

Schema description coverage is 100%, so parameters like confirm, idempotency_key, and instrument are already well documented in the schema. The description only lightly reinforces this ('payment_methods reads current cards') and adds no syntax or format detail 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 names the resource (billing) and the primary operations: reading features/plans, reading payment methods, and checkout/add_funds. It is clearly distinct from the campaign/segment/contact siblings. It stops short of covering the status/checkout_status/funding_purchase_status operations, so an agent must open the enum to see the full surface.

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 offers some operational guidance: checkout and add_funds require operator approval and polling afterward, and prepaid funds are separate. However, it does not tell the agent when to choose each of the eight operations over the others; the 'Start with status or features' routing hint lives only in the schema, not 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?

Annotations already disclose destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the risk profile is covered structurally. The description adds the forward-all MX prerequisite, which is real behavioral context, but says nothing about which of the ten operations are destructive, whether removal is reversible, or that confirm gates removals/renames — that appears only 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?

Two sentences, zero filler, with the resource scope front-loaded ahead of the prerequisite note. It is efficient, though the brevity is partly under-specification rather than pure conciseness.

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

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

For a ten-operation, destructive, nested-parameter tool with no output schema, the description is too thin: it never explains the prepare→select→verify lifecycle, which operations mutate vs read, or what a caller gets back. The schema fills much of the gap, but an agent cannot infer sequencing or consequences from the description alone.

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 including the operation enum is documented at the field level. The description adds no parameter meaning beyond that, which is the expected baseline when the schema carries the full load.

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 (Nitrosend sender and custom sending domains) and a management verb, and no sibling tool overlaps this space. However, 'Manage' spans ten quite different operations (prepare/select/rename/add/verify/list/remove/share/revoke), so the agent only learns the broad domain of the tool, not the concrete actions, from the prose.

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 one operational rule given — that receiving MX requires forward-all — is genuinely useful framing for choosing this tool. But there is no explicit when-to-use/when-not guidance and no routing to alternatives or prerequisites for the mutating operations; most such guidance lives in the operation enum description inside the schema rather than the tool 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?

Annotations already declare destructive=true, readOnly=false, and openWorld=false, so safety is covered. The description adds workflow behavior such as based_on cloning and following next_call for intent mode, but does not explain persistence, validation, or what destructive edits affect.

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, starting with the core create/edit action before usage routing. It is efficient but somewhat telegraphic, especially the instruction to follow exact next_call.

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 29-parameter, deeply nested mutation tool with no output schema and only 45% schema description coverage, the description is too sparse. It provides useful mode routing but does not adequately explain the full parameter surface or operational behavior.

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

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

With 29 parameters and only 45% schema description coverage, the description should compensate substantially. It clarifies a few key parameters like template_id, section_updates, if_version, based_on, and composition_mode, but leaves most parameters undocumented in the description.

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

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

The description states a specific verb and resource: create/edit reusable email templates, with based_on cloning. It also distinguishes the broadcast sibling via nitro_compose_campaign, though it does not fully clarify whether management includes delete/list operations.

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

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

It gives explicit routing: creative work should use composition_mode=intent and follow the next call, while exact edits use template_id, section_updates, and if_version. It names nitro_compose_campaign for broadcasts, but lacks broader when-not guidance against other siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description's only addition is 'Returns paginated results', which restates what the per/page params already imply; it does not explain ordering, truncation, or what the paginated envelope looks like.

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 filler, and the resource scope is front-loaded ahead of the return note. It is efficient, though the brevity edges into under-specification for a tool spanning 13 entity types rather than being genuinely economical.

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?

This is a broad, complex query tool with a nested filters object, 13 entity variants, and no output schema. The description never explains how filters combine, what the response envelope contains, or how it relates to sibling query/search tools, so it is not complete enough for an agent to call it confidently in ambiguous cases.

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

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

Schema description coverage is 100%, including a detailed per-entity breakdown of valid filters and the enum list, so the schema carries the parameter burden completely. The description adds nothing beyond 'paginated results', which does not compensate for or enrich any parameter meaning – 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 verb (query) and resource (Nitrosend entity) plus the return shape ('paginated results'), so the basic action is clear. But 'any entity' is so broad across 13 enum values that an agent cannot tell from the description how this differs from nitro_search_contacts or nitro_get_insights; that differentiation only appears buried in the entity parameter's schema text.

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 itself gives no when-to-use guidance, no prerequisites, and no named alternatives. The only routing hint ('Contact full text: nitro_search_contacts') lives in the schema's entity description, not the tool description, so the guidance is present but not where an agent reading the definition would naturally find it.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=false, so the agent knows this is a mutating, closed-world operation. The description adds important gating guidance about when not to submit support, but it does not explain the actual side effects or what "destructive" means for this 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 front-loaded sentence with no wasted text. The usage constraint and exclusion are stated compactly and clearly.

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 schema fully covers the two required inputs, and annotations cover safety characteristics. However, for a destructive support-submission tool, the description does not explain what submitting support actually does or what the destructive side effect is, leaving a meaningful 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?

Both parameters are fully documented in the schema, including the 1500-character limit for message. The description adds no parameter-specific information beyond what the schema already provides, which is acceptable given 100% 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 uses a specific verb and resource: "Submit support." It clearly identifies the action as creating/support submission, though it relies on the title to clarify the full notion of a support request. No sibling tool is a support-request tool, so distinctness is adequate.

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

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

The description gives explicit usage conditions: only when asked or when other tools cannot resolve the issue. It also adds an exclusion: never promote it. It does not name specific alternative tools, but the when/when-not guidance is clear.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered; the description adds value by enumerating the analyses performed (validation, spam/SMS analysis, preflight, previews) and explicitly confirming no approval or send side effect. It omits anything about permissions, latency, or how results are shaped, keeping it below 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?

Two sentences with no filler, and the read-only framing is front-loaded before the scope and effect boundaries. Slightly list-like in the middle clause, but every item earns its place as a capability signal.

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 six optional parameters, 67% schema coverage, and no output schema, the description should at least signal what a review returns or how a caller should combine target_id/target_type with html/subject. It covers the 'what it checks' side well but leaves the invocation-shape and result-interpretation side 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 coverage is 67%, so several parameters (target_id, target_type enum, html/subject limits) are already documented. The description's 'either ... or' hints at the entity-vs-inline mode split, but it does not state that these two parameter groups are mutually exclusive or which must be pair-supplied, which is the single most important semantic for this zero-required-parameter 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 — read-only content and readiness review with validation, spam/SMS analysis, preflight, and previews — and names the exact scope (one account entity or bounded inline email content). The closing 'never approves or sends' cleanly separates it from nitro_send_message and nitro_control_delivery without needing to open their 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?

The 'either one account entity or bounded inline email content' phrase implies the two invocation modes, which is useful routing guidance. However, it never states when an agent should call this versus nitro_send_test_message, nitro_control_delivery, or nitro_get_status, and there is no explicit prerequisite or exclusion guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that results can be a summary list or full profile, but it omits matching behavior, pagination semantics, and output details beyond the mode names.

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 sentences with no filler. The search capability is front-loaded and the return-shape note follows immediately.

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 four-parameter search tool with no output schema, the description covers the core purpose and the two return modes but leaves important gaps around query matching semantics and pagination behavior. It is minimally adequate but not fully complete for reliable 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 75%, with the required query parameter having no schema description. The description partially compensates by saying search covers email, name, or phone, but it does not explain query syntax, matching rules, or how per/page interact beyond what the schema already says.

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, 'Search contacts,' and specifies the searchable fields: email, name, or phone. It also states the two possible return shapes, making the tool's purpose immediately clear without opening 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?

The description implies appropriate use as a contact lookup tool but gives no explicit guidance on when to use it versus alternatives such as nitro_query, nitro_import_contacts, or nitro_manage_audience. No exclusions, prerequisites, or alternative-routing advice 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral guidance beyond that — that results come back as excerpts meant to justify claims, and that the agent should re-search or flag unresolved gaps — but says nothing about result volume or ranking.

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 no filler; the search scope is front-loaded and the grounding instruction follows immediately. Every clause carries usable direction.

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 search with full schema coverage and annotations carrying the safety profile, the description is largely sufficient, and 'returned excerpts' hints at output shape despite no output schema. Only minor gaps around result volume or ranking remain.

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

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

Schema coverage is 100%, with both query and limit already documented (including the 'Max 10' constraint and query examples). The description adds no additional parameter semantics, 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 states a specific verb (Search) and a specific resource set (Nitrosend guides and API/MCP/CLI/integration references), which is clearly distinct from sibling lookups like nitro_search_contacts or nitro_query. It does not explicitly name an alternative, but the scope 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 gives clear usage context: use this to ground unestablished product claims in returned excerpts, and either search again or state what remains unverified. There is no explicit when-not or naming of alternative tools, keeping it 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?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds important behavioral context beyond those annotations: selecting an account changes the connection scope and affects the next call.

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

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

The description is a single front-loaded sentence with no redundant information. It states the action, the source of the ID, and the immediate effect.

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

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

For a simple one-parameter selection tool with rich annotations and full schema coverage, the description covers what the tool does, where the parameter value comes from, and how the selection impacts subsequent calls. No output schema exists, so return-value explanation is not required.

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

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

The schema has 100% description coverage and already specifies that account_id comes from nitro_get_status available_accounts.items[*].id. The description reinforces the source but does not add syntax, format, or validation 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 gives a specific verb and resource: switching the OAuth MCP connection to an account. It also names the sibling tool that supplies valid account IDs, making the purpose immediately clear to an agent.

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 prerequisite source of account IDs via nitro_get_status and explains that the next call uses the selected account. It does not explicitly distinguish when to use this instead of nitro_configure_account, but the context is otherwise clear.

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 the mutation is idempotent and non-destructive; the description adds the key extra fact that the effect is scoped to the connection, which is genuinely useful. It doesn't say what happens to a previously selected brand, whether selection persists across calls, or how the ambiguous-name candidate path leaves state untouched beyond what the schema already says.

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

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

Two sentences, zero waste, with the action stated first and the routing rule second. Nothing to trim.

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

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

For a 2-parameter, no-output-schema tool with full schema coverage, this is nearly complete: action, scope, and preferred usage are all covered. The gap is the relationship to nitro_select_account and whether a brand can be cleared or inspected.

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 the name-vs-brand_sid either/or and the ambiguous-name behavior. The description only echoes brand_sid as the thing you'd otherwise pass elsewhere, adding no new parameter semantics.

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

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

Specific verb+resource ("Select the current brand") scoped to "this OAuth MCP connection", so the agent knows it sets connection-level state rather than editing a brand record. It does not reference the obvious sibling nitro_select_account, so the differentiation from that tool is left implicit.

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

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

Gives an explicit routing rule: use this instead of passing brand_sid to other tools. It stops short of stating when not to use it (e.g. after a brand is already selected, or how it interacts with nitro_select_account).

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 destructiveHint=true, idempotentHint=true, openWorldHint=true and readOnlyHint=false, so the safety profile is known without the prose. The description adds genuine value by converting idempotentHint into an actionable retry rule (same payload AND same key), but it omits rate limits, verified-sender requirements, and what happens to a duplicate submission with a changed payload.

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 clauses, zero filler, with the core action front-loaded before the bulk alternative and the retry rule. Every sentence earns its place and nothing needs trimming.

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 16-parameter, nested-object, destructive send tool with no output schema, the definition covers the essentials: what it does, when not to use it, and how to retry safely. The remaining gap is channel-conditional requirements (SMS needs body, email needs a verified sender) and the test-message sibling, which the schema only partially compensates for.

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 75% across 16 parameters, so the schema already documents most fields including to, body, from, data, dry_run, and headers. The description's only parameter-level contribution is constraining idempotency_key usage to exact retries, which the schema's 'Reuse only for an exact retry' already largely conveys.

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 (send one transactional email/SMS) and scopes it to single-message use, which separates it from the bulk composing siblings. It says 'campaigns/flows' rather than naming nitro_compose_campaign and nitro_compose_flow directly, so the routing cue is inferable rather than explicit, and it never mentions nitro_send_test_message as the test-path 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?

It gives a clear when-not ('For bulk use campaigns/flows') and an explicit retry rule ('Retry unchanged payload/key'), which tells the agent exactly when this tool is the right call versus a campaign/flow tool. It stops short of covering prerequisites such as sender verification or the test-vs-live distinction.

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 flag destructiveHint=true and idempotentHint=true; the description goes further by defining what a success response actually means ('the mail provider accepted the send') and its limits ('does not prove inbox placement'). That is exactly the kind of caveat an agent needs before treating a test send as proof of deliverability.

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 scope constraint and free of filler. It is telegraphic to the point that 'Confirm receipt before approving' depends on the reader already knowing the approval workflow context.

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

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

For a 13-parameter, mutation-capable tool with no output schema, the description covers what success means and what it does not prove, which substitutes well for a missing return-value spec. It leaves ambiguous how to combine the multiple alternative recipient/target selectors, which is the main remaining 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 coverage is 92%, so nearly every parameter is already documented, and the description's only parameter-adjacent statement ('Flows require an exact revision') restates the revision_id description. With the schema doing the heavy lifting across 13 parameters, the description adds no additional selection logic for the overlapping target_type/target_id/template_id/latest_campaign selectors.

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 ('Send one real email/SMS test') and immediately bounds the scope ('Never approves or sends to an audience'), which separates it cleanly from nitro_send_message. An agent can pick between the two 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?

'Never approves or sends to an audience' plus 'Confirm receipt before approving' gives clear context that this is a pre-approval verification step, and 'Flows require an exact revision' states a prerequisite. It stops short of naming nitro_send_message as the alternative for real audience sends, so routing is implied rather than explicit.

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

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

Annotations already declare openWorldHint=true, idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds the useful behavioral constraints that async is URL-only and that fields override scraping, but it does not explain side effects, permission requirements, or what happens to existing brand data.

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

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

The description is two tightly packed sentences with the primary action first and the key constraints immediately after. There is no wasted 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?

This is a complex mutation tool with 9 parameters, nested objects, no output schema, and very low schema description coverage. The description is too brief to cover the missing parameter semantics or the operational behavior of dry_run, scan_id, new_brand, and document.

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

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

Schema description coverage is only 22% across 9 parameters, so the description must compensate and does not. It mentions the source parameters generally and the fields-override rule, but it leaves dry_run, scan_id, new_brand, document, url, and mode behavior largely undocumented.

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

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

The description states a specific verb and resource ('Set Brand Kit') and enumerates the four supported input sources: website, fields, document, and logo URL. It does not explicitly distinguish this tool from the sibling nitro_select_brand, so it stops short of full sibling 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?

The description gives useful conditional guidance: 'Fields override scraping' and 'async is URL-only.' However, it does not say when to use this tool versus nitro_select_brand or other brand-related siblings, and it provides no explicit 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds destruction granularity ('replace entirely' vs 'replace a section' vs 'add to end'), but that same text is duplicated in the operation enum in the schema, and it omits dry_run and the idempotency_key requirement for append.

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 purpose front-loaded before the operation list; nothing is padded. It loses a point only because the operation recap partially duplicates the schema enum descriptions.

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 6-parameter multi-operation write tool with no output schema, the description covers all four modes and their effects on the document. It is slightly thin on dry_run behavior and the retry/idempotency contract, which are left entirely to the schema.

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

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

Schema description coverage is 83%, so the schema already documents content, heading, document, operation and idempotency_key. The description adds no parameter-level detail beyond that and says nothing about dry_run, 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 states a specific verb set and resource ('Read or update the AI memory document') and enumerates the four operations with their effects, so an agent knows exactly what the tool does. It cannot differentiate against a sibling because no sibling memory tool exists, keeping it 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?

Operation semantics ('read (get current)', 'update (replace entirely)', 'patch (replace a ## section)', 'append') imply which mode fits which need, but there is no explicit when-to-use/when-not guidance, no guidance on choosing patch over update, and no mention of the dry_run preview path.

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