bridgecore

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

Adds substantial behavior beyond the annotations: the server is preview-only, never sends the request, and never accepts credentials; unmatched inputs come back in `missing`; values spoken in the need (emails, #channels, +phones) are auto-filled; multi-step needs fan out to one preview per step. This is exactly the operational context an agent needs before calling, and nothing contradicts readOnlyHint/idempotentHint/destructiveHint=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?

Front-loaded with the core offer (plain words in, exact call out) and packed with concrete examples rather than filler. It is dense to the point of being semicolon-heavy, and the closing Actor promotion is borderline promotional, though it does redirect the agent for real execution.

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

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

For a tool with an output schema, the description covers the things structure cannot: preview-only semantics, credential handling, multi-step behavior, n8n workflow emission, and how to resolve incomplete inputs. Nothing an agent needs in order to call this 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?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: values embedded in `need` are auto-extracted and filled, so `inputs` is a supplement rather than the primary channel, and `missing` from a prior call tells the agent what remains. That relationship between `need`, `inputs`, and the returned `missing` list is not derivable from the schema alone.

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 function: take a plain-language need, match it against 3,631 app capabilities (n8n catalog + OpenAPI + MCP), and return the exact HTTP/MCP request as a preview. It also carves out the real-execution case (Bridgecore Apify Actor), which separates it from the execution path. It never names the sibling tools (find_recipe, plan_automation, make_n8n_workflow, inspect_workflow), so the boundary with those is left to inference.

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

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

Gives clear usage context: one action phrase runs a single capability, a 'when …' need or multiple steps yields one preview per step, and n8n-only steps return an importable workflow. It also states the exclusion that real sending is handled by a separate Actor. It stops short of saying when to prefer a sibling such as plan_automation or find_recipe.

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 readOnlyHint and openWorldHint; the description goes further and discloses the shape of the result (apps chained with →, what it does, the n8n workflow JSON, the blanks to fill, accounts to connect) plus supplementary public templates. No auth, rate-limit, or failure behavior is mentioned, and nothing contradicts the annotations.

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

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

Front-loaded with the purpose sentence and the example, followed by return contents and coverage. Slightly long in the final 'Covers connecting apps…' clause, which lists near-synonyms, but overall it earns its space.

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?

Inputs, expected result contents, and scope are all covered, and an output schema exists so return-value detail is not strictly required. An agent has enough to invoke it correctly; only explicit sibling routing 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, but the description adds meaning by giving a full example need ("when a typeform is submitted add a row to google sheets…") and framing the input as plain words. That complements the schema's 'start with when…' hint without repeating it verbatim.

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

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

States a specific verb+resource ("Find a ready-made automation recipe") and reinforces it with a concrete plain-words example, so the agent knows exactly what comes back. It does not explicitly distinguish itself from siblings like plan_automation or make_n8n_workflow, though "ready-made" implicitly separates it from workflow-building tools.

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

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

The description implies when to use it (turning a plain-words need into a prebuilt recipe) and lists coverage areas such as connecting apps and getting notified. It never names an alternative tool or a condition under which a sibling is the better choice, so routing guidance 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 only declare readOnlyHint and openWorldHint; the description adds real substance beyond them — how risk levels are derived ('computed from the node's own resource + operation'), what add_gates returns (a copy with an Approve/Decline step wired in), and explicit non-mutation guarantees. This is exactly the behavioral 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?

A single dense paragraph, front-loaded with the core action ('Read an existing n8n workflow JSON … say what it would do before it runs') followed by the enumerated outputs. Every clause is informative; only the parenthetical channel list is mildly expendable.

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

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

For a read-only inspector with an output schema, complete annotations, and full schema coverage, the description covers everything an agent needs: what it reads, what it returns, the opt-in gating branch, and the no-side-effect guarantee. 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 coverage is 100%, so 3 is the baseline, but the description adds meaning: it explains the interaction model behind ask_via ('one-tap Approve / Decline step (Slack, Telegram, Gmail…)') and clarifies that add_gates yields a separate gated_workflow copy rather than altering the original. Adds modest value over the schema text, which already documents both optional params.

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

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

States a specific verb ('read/inspect') and resource ('an existing n8n workflow JSON') and then enumerates exactly what it reports: per-node risk labels, ungated irreversible steps, existing approvals, and unconnected accounts. This clearly separates it from the mutation/creation siblings (make_n8n_workflow, plan_automation, do) without needing to name them.

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

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

'before it runs' plus 'Nothing is run; the original is not modified' gives a clear usage context: pre-flight inspection of an existing workflow. It also explains the add_gates branch condition. It stops short of naming the sibling to use instead for authoring or executing, so it is clear context without explicit exclusions.

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

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

Without relying on annotations, the description discloses that the tool only produces JSON (shape-checked, human-tested before activation) and that the built-in approval gate blocks sends, posts, deletes and payments until a tap — squarely consistent with readOnlyHint=true. This is far more behavioral context than the annotations supply.

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 core purpose is front-loaded in the first clause and every element (output contents, blanks, approval gate) is substantive rather than filler. The prose is conversational and clause-heavy, which inflates length slightly, but nothing is clearly redundant.

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

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

With an output schema present, return values need no explanation, and the description covers generation behavior, approval semantics, and the human-test-before-enable step. The only remaining gap is the lack of any differentiation from the sibling automation-planning tool, which leaves the agent to infer routing.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description still adds practical phrasing guidance for 'need' (start with 'when …', insert 'and ask me first') and maps the spoken phrase to approval='always', giving marginal but real value 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 — 'Generate an importable n8n workflow JSON from a plain-words need' — and enumerates what the output contains (wired nodes, pre-filled values, blanks, credentials). An agent can tell what it produces without opening the schema. It does not, however, distinguish itself from the sibling 'plan_automation', which plausibly covers similar ground.

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 concrete usage instruction for the approval feature ('Say "and ask me first" (or approval=\'always\')') and notes the workflow is tested in n8n before being turned on, which frames expected usage. But there is no explicit when-to-use-this vs. the siblings (do, find_recipe, plan_automation), so routing guidance 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?

Annotations already establish readOnlyHint=true and openWorldHint=false, and the description adds genuinely useful behavior beyond that: it searches 3,000+ capabilities (n8n nodes, OpenAPI, MCP) and, distinctively, reports a gap rather than silently substituting a different app. That no-substitution policy is exactly the kind of behavioral trait an agent needs. It stops short of describing plan shape or failure modes.

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

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

Two sentences, no filler, and the core action plus the gap-reporting guarantee are front-loaded. Every clause carries information about scope or behavior.

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 and annotations covering the safety profile, the description only needs to supply scope and behavior, which it does. The remaining gap is pipeline positioning: nothing tells the agent how this relates to do or make_n8n_workflow, which matters for a planning tool in a multi-step toolset.

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

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

Schema description coverage is 100%, so both parameters (need, alternatives) are already fully documented, including the trigger/action phrasing and the 1-5 range. The description adds no syntax or meaning beyond the schema, which is the expected baseline here.

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

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

States a specific verb and resource: converts a plain-words need into a trigger+actions plan and selects a concrete tool per step from a large capability catalog. The scope is clear and clearly read-oriented, but it never names the siblings (do, make_n8n_workflow, find_recipe) that an agent would weigh it against.

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

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

Usage is only implied: the tool is framed as the planning stage that precedes execution, so an agent can infer it should be called before 'do' or 'make_n8n_workflow'. There is no explicit when-to-use, when-not, or naming of alternatives, and no stated prerequisite tying it to the sibling tools.

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