Moltline Outbound Engine

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, but the description adds genuinely new behavior: it never raises a protocol error and instead returns an {"error": ...} object, and it is always safe to retry after fixing input. The "FREE" cost signal is also useful. It repeats the read-only/idempotent claims from annotations, which keeps 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?

Front-loads the purpose, then scope, then example I/O, then exclusions and error contract – each block is one tight sentence or fragment. The inline return example is arguably redundant with the output schema, but it is compact and earns its space as a call-shape illustration.

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 free, two-parameter read-only validator, everything an agent needs is present: what it checks, what input looks like, what comes back, the error contract and retry safety, and which siblings to use instead. Nothing material is missing.

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

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

Schema description coverage is 100%, so the two parameters are already documented, including that subject may be empty. The sample input object restates that relationship but adds no syntax, limits, or edge-case meaning beyond the schema. 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 (audit outreach copy) plus the exact risk classes it checks (spam triggers, deliverability). It names the two siblings it is not, so an agent can route correctly without opening a 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?

"Use on the body of an outreach message" gives the positive case, and the next sentence gives two explicit exclusions with the sibling that covers each: subject_line_scorer for subject lines, sequence_planner for send schedules.

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 cover safety (readOnly, idempotent, non-destructive), yet the description still adds material context: no plan required, automatic skill selection, and a full error contract (never raises protocol errors, returns {"error": ...} with remediation). That error behavior in particular is not derivable from annotations or schema.

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

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

Front-loaded with purpose and cost ("FREE."), then example, then routing rule, then error contract. Slightly long because the inline JSON examples take vertical space, but no sentence is filler.

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

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

For a one-parameter read tool, everything an agent needs is present: what comes back, which skill is selected, what happens on bad input, and that retry is safe. Output and error shapes are described, which more than compensates for the single-parameter surface.

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

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

Schema coverage is 100% and the slug parameter is well documented, so the baseline is 3. The description goes further with a worked example ({"slug": "linkedin-outreach"}) and an error example that tells the agent what to do with a bad slug, adding 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 and resource ("load a product's free gateway skill with its complete instructions") plus the scoping rule that exactly one skill is returned, auto-selected from the slug. It also explicitly distinguishes itself from get_full_skill, so an agent can separate the two without inspecting either schema.

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

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

Gives an explicit trigger ("Use when the caller wants usable instructions immediately") and an explicit exclusion ("Not for the product's other skills: those are named and need get_full_skill with a skill_name, which requires a paid plan"). When-to-use, when-not, and the alternative are all named.

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 the description adds behavior beyond them: it never raises a protocol error, instead returning {"error": ...} with corrective text, and states retries after fixing input are always safe. It also discloses the premium/license gating and the concrete return shape, which annotations cannot convey.

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

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

Front-loaded with the core action and the example payloads are compact and useful. The third sentence ('Returns persona plus every skill for one product') restates the opening line, a minor redundancy that costs a bit of tightness.

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?

An output schema exists, so return values needn't be re-explained, yet the description still shows a representative response. Combined with license gating, error contract, and retry safety, an agent has everything needed to invoke and recover from failures correctly.

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

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

Schema coverage is 100% and the slug property already documents 'exactly as returned by list_products'. The description reinforces this with a literal example input and ties the parameter to error semantics ('unknown slug'), which adds a little beyond the schema but is not essential new 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?

States a specific verb and resource ('Load one product in full: its persona plus every paid skill') and names exactly what is included. It also distinguishes itself from the three relevant siblings (get_full_skill, list_products, get_free_skill) so an agent can select it without inspecting 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?

Explicitly gives the selection condition ('Use when the caller wants the whole product') and names the alternatives for the adjacent cases: single skill via get_full_skill, free look via list_products/get_free_skill. Includes the PREMIUM (license) prerequisite, which is real usage guidance.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, but the description adds materially new behavior: a PREMIUM license requirement, and the fact that invalid input never raises a protocol error but returns {"error": ...} with a fix hint. The explicit retry-safety statement after correcting input is exactly the kind of operational context annotations cannot convey.

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

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

Purpose and premium status are front-loaded, followed by example, routing exclusions, and error semantics in a logical order. Slightly verbose — the inline JSON example and the return-shape sentence partly duplicate the output schema — but nothing is filler.

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

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

Two required params at full schema coverage, an output schema covering success shape, and the description still covers the error path and licensing prerequisite. Nothing an agent needs to call this correctly or handle failure is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes further by supplying a concrete example input and output, showing the expected value shapes for slug and skill_name and reinforcing that skill_name selects exactly one skill. It stops short of documenting skill_name matching rules (case sensitivity, aliases), which the schema also omits.

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 ('Load one paid skill's complete instructions from a product') and immediately scopes it to a single named skill. The final sentence distinguishes it from both get_free_skill and get_full_product, so an agent can route without opening another schema.

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

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

Explicit selection rule: 'Use when the caller wants one specific paid skill,' followed by named exclusions ('Not for the free gateway skill, which get_free_skill returns... and not for every skill at once (get_full_product)'). Both alternatives are named with the condition that selects them.

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, yet the description adds materially new behavior: it is FREE, it accepts no arguments, it returns metadata only (no persona text, no skill instructions), and it never raises a protocol error but instead returns {"error": ...} with remediation guidance. That error contract plus the safe-retry assurance is exactly the context annotations cannot carry.

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 well organized: purpose, cost, argument contract, return shape, routing guidance, then error behavior. It loses a point because 'Takes no arguments' and the inline return-shape example partly duplicate the empty schema and the existing output 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?

An output schema exists, yet the description still pins down the important things an agent needs: cost, that results are metadata-only, how slugs feed other tools, and the non-throwing error contract. Nothing required to call it correctly is missing.

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

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

Zero parameters, so the baseline is 4, and the description confirms 'Takes no arguments.' It also explains how to consume the returned slug values in sibling tools, which is useful but borders on output documentation rather than 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?

Opens with a specific verb and resource plus scope: 'List the 7 outbound products with their included skills.' It immediately differentiates from siblings by naming what it is not (search_catalog, get_free_skill) and by pointing to get_free_skill/get_full_product/get_full_skill for follow-up calls.

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

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

Explicit trigger ('Use when the caller wants to see what this server covers') plus two explicit exclusions with the correct alternative named for each: keyword search belongs to search_catalog, actionable instructions belong to get_free_skill. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds useful behavioral detail beyond those annotations: it says the tool is FREE, never raises a protocol error on bad input, returns an error object explaining what is wrong and how to fix it, and is safe to retry after correction. It does not cover rate limits or deeper runtime constraints, so it is strong but not exhaustive.

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

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

The description is front-loaded with the core purpose and usage guidance, then provides a concrete example and error behavior. It is somewhat long and includes example output despite the presence of an output schema, but the included material is generally useful rather than wasteful.

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

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

Given the moderate complexity, complete schema descriptions, annotations, and the existence of an output schema, the definition is complete. It covers purpose, appropriate use, the closest alternative, example shape, error behavior, and retry safety without needing to explain return values in detail.

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 days, touches, and channels, including defaults and clamping ranges. The description reinforces the semantics with a typical input example and the alternating-channel behavior, but does not add much beyond what the fully described schema already provides.

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

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

The description states a specific verb and resource: plan an outreach cadence with expanding gaps and per-touch purposes. It distinguishes the tool from the sibling audit_copy by explicitly saying it is not for message wording, and the example input/output makes the tool's scope concrete.

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 usage criteria: use when cadence and per-touch purpose are the question, and not for wording of any single message. It names audit_copy as the alternative for message wording, and adds retry guidance after correcting invalid input.

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 cover readOnly, idempotent, and non-destructive, but the description adds genuinely new context: it is free, it scores on named dimensions, it never raises a protocol error and instead returns an {"error": ...} object, and retry after correction is safe. Minor repetition of the read-only/idempotent claims already in annotations keeps this from a 5.

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

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

Front-loads the verb, scope, and the FREE signal, then the scoring criteria. The embedded JSON example consumes space but is doing real work illustrating input and output; the trailing retry sentence is slightly redundant with the idempotent annotation.

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?

A complete picture for a simple single-parameter tool: purpose, alternatives, error contract, and cost. Since an output schema exists, the inline return-value example is somewhat duplicative rather than necessary, which caps the score at 4.

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

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

The single parameter already has 100% schema coverage including the 'first 20' truncation, so the baseline is 3; the description goes further with a concrete input/output example showing the expected shape. It does not add per-parameter constraints beyond what the schema states.

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

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

Names a specific verb and resource (score and rank email subject lines) plus scope (up to 20, best first). It explicitly contrasts itself with headline_analyzer and audit_copy, so an agent can place it 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?

States when to use it ('several subject lines need ranking against deliverability and curiosity signals') and when not to ('not for article headlines... not for message bodies'), naming the alternative tool for each exclusion.

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 and destructiveHint, but the description adds a genuine error contract: it never raises a protocol error and instead returns {"error": ...} with fix guidance, and retry after correcting input is safe. That is real behavioral disclosure beyond the annotations, though failure modes for malformed optional fields (term/content) are not spelled out.

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

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

Purpose is front-loaded in the first line, and usage/exclusions follow before the error contract. The inline JSON examples are somewhat verbose and split awkwardly across lines, but each sentence carries actionable information.

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

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

With an output schema present, return values need no explanation, and the description still supplies the error shape, retry safety, usage boundaries and a concrete example. An agent has everything needed to call this correctly on the first attempt.

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 each field already documents its utm_ mapping and defaults, so the baseline is 3. The worked input/output example adds modest value by showing how the four required params assemble into the final tagged_url, but it restates rather than extends the schema (optional term/content are absent from the example).

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

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

States a specific verb and resource ('Build a UTM-tagged URL for campaign tracking') plus an explicit scope limit ('one tagged tracking URL'). It also names what it is not for ('analyzing campaign results') and points at the sibling audit_copy, so an agent can separate it from the rest of the toolset 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?

Gives both a positive trigger ('Use to build one tagged tracking URL') and explicit exclusions, routing message-body work to audit_copy by name. The one-URL-at-a-time constraint is stated, which prevents batch misuse.

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