LiveGraph

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

With no annotations, the description carries the full burden and does well: it discloses partial-cancellation semantics (in-flight hops finish, queued hops no-op), required permission level, and the terminal-status error. It omits whether the action is idempotent or reversible, which would complete the mutation profile.

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

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

Two dense sentences, front-loaded with the operation and its effect before preconditions and errors. Every clause adds distinct information with no filler.

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

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

For a 2-parameter mutation tool with no annotations and no output schema, the description covers semantics, authorization, and error behavior. Missing only secondary details like repeat-cancel behavior or what the caller gets back.

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 runId and the optional reason are already documented in the schema. The description adds no parameter-level detail (e.g. runId format or how reason is surfaced), so the baseline 3 applies.

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

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

States a specific verb+resource (cancel a run) and immediately narrows scope with the exact cancellation semantics ('in-flight hops finish, queued hops no-op'). It does not explicitly contrast with the nearby sibling pause_run, but the verb and semantics still let an agent tell the two apart semantically.

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 concrete preconditions and a failure condition: editor access on the run's graph is required, and cancelling a run already in a terminal status errors. It stops short of explicitly routing the agent between cancel_run and pause_run/resume_run, which is the main missing piece.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses validation behavior ('rejects invalid topology with the schema's own errors') and the return payload (graph id plus canvasUrl), but says nothing about permissions, side effects on existing graphs, or limits.

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

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

Two dense sentences with zero filler; the core action is front-loaded and the ref/edge/entry linkage and return value follow in priority order.

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 correctly fills the return-value gap (id plus canvasUrl), and with no annotations it covers validation failure mode. It stops short of prerequisites and permission context for a creation tool with nested node/edge payloads.

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

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

Schema coverage is only 40% across 5 params, so the description must compensate and partially does: it explains the caller-chosen `ref` linkage between nodes, edges, and `entry`. It adds nothing about `name`, `description`, edge `kind`/`condition`, or node `role`/`model` 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?

States a specific verb and resource: materialize a validated graph spec into a real graph on the caller's account. The mechanics (refs, edges wiring refs, entry naming the start node) make it clearly distinct from siblings like instantiate_template, draft_node, and update_graph_nodes.

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

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

Usage is implied rather than stated: the phrase 'validated graph spec' hints you must already have a spec in hand, and the contrast with instantiate_template (template-based creation) is detectable but never made explicit. No when-not-to-use or alternative routing is 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?

With no annotations, the description carries the full burden, and it delivers the most important trait: this is a non-mutating operation that produces a reviewable draft. It also discloses the return shape (name, role, systemPrompt, description, provider, model) and notes parity with the canvas quick-add. It stops short of describing validation limits or how the model pick resolves absent a graphId.

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

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

The purpose and the non-creation guarantee are front-loaded in the first clause. The single sentence packs in a field list and an alternative tool, which is efficient but makes for a dense, somewhat crammed read.

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

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

For a two-parameter tool with full schema coverage and no output schema, the description usefully compensates by enumerating the drafted fields. It omits only edge behavior like validation failures or how model selection falls back when graphId is absent.

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

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

Schema coverage is 100%, so the schema already documents both graphId and description. The description adds no syntax or format guidance beyond what those schema descriptions provide, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Turn a plain-English brief into a structured node spec') and enumerates the resulting fields. It also sharply distinguishes itself from the create/update siblings by stressing 'WITHOUT creating anything'.

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

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

It names the exact workflow and the follow-up alternatives: draft here, then materialize with create_graph or update_graph_nodes. The agent knows when to reach for this tool versus those siblings without guessing.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the access requirement (viewer access), which is genuinely useful, but says nothing about the returned URL's lifetime, whether it is shareable, or any rate limits. Solid but incomplete.

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 clauses with the core action front-loaded and the access caveat appended. No filler, though the dash-clause could be trimmed slightly.

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 with no output schema, the description covers what it produces, what it's for, and who can call it. Only the URL's persistence/shareability is left unstated, a minor gap at 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?

Schema description coverage is 0% and the single parameter graphId is never mentioned in the description, so nothing compensates for the documentation gap. The name makes the meaning largely self-evident, but the description adds no semantic value.

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

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

States a specific verb+resource: produce a deep link into the web canvas for a given graph. An agent can tell this apart from get_graph or get_run by the 'web canvas' framing, though it never names a sibling to differentiate explicitly.

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

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

Implies the usage context ('open it to watch or steer runs live') and gives a prerequisite ('Requires viewer access'), but never states when not to use it or which alternative to prefer over get_graph/get_run. Usage is implied rather than prescribed.

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

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

No annotations are provided, so the description carries the full burden. It discloses two useful behavioral facts: the returned shape is the canvas model, and viewer access is required. However, it says nothing about rate limits, pagination, error behavior, or what happens if the graph is missing.

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

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

Two compact sentences with no filler. The key content — return shape and access requirement — is front-loaded, which is appropriate for a single-parameter fetch 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 one-parameter, non-destructive fetch tool with full schema coverage and no output schema, the description covers the essential facts: what is returned and the access requirement. It is a bit thin on failure modes and sibling differentiation, but otherwise complete.

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

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

Schema coverage is 100%, so the sole parameter is already documented in the schema, including that the id comes from list_graphs. The description adds no syntax or format detail beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb (Fetch) and resource (one graph's full live spec), and enumerates the returned content (nodes, edges, settings). This distinguishes it from list_graphs (enumeration) and update_graph_nodes (mutation).

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

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

The description implies usage by mentioning the graphId source ('from list_graphs') and the required access level, but it does not state when to choose this over alternatives like list_graphs or get_run. Usage is inferable but not explicit.

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

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

With no annotations, the description carries the full burden. It usefully discloses the viewer-access requirement and mentions parked tool-call approvals, but does not describe output format, error behavior, or other operational traits.

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 written sentences with no filler. The core purpose is front-loaded, and the access prerequisite follows as useful supporting 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?

Although there is no output schema, the description names the key return elements: status, output, and parked tool-call approvals. It also covers the auth requirement, leaving only minor format details unspecified.

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 single runId parameter is already well documented. The description adds no syntax or format detail beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description states a specific verb and resource: reading one run's status, output, and parked tool-call approvals. The phrase 'one run' distinguishes it from sibling list/search tools like search_runs and from lifecycle tools like start_run or cancel_run.

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 an implied usage context, namely fetching details for a specific run by id, and states the access prerequisite. However, it does not explicitly say when to use this versus search_runs or other run-management 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?

With no annotations, the description carries the full behavioral burden. It does disclose two valuable traits — idempotency and that a repeat call returns the existing assistant rather than a duplicate — but says nothing about required permissions, what side effects beyond the graph seeding occur, or what the response contains.

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

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

Two tight sentences with the core behavior front-loaded and the idempotency caveat placed second. No filler, though the 'end-to-end' phrasing is slightly vague and 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 5-parameter mutation tool with a nested object and no output schema, the definition covers the primary effect and repeat-call behavior but leaves the breadth of 'end-to-end' onboarding undefined — for example whether credentials, nodes, or runs are also created.

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 name/tone/focus/template/spec are all documented in the schema; the description only lightly paraphrases them ('name + optional tone/focus', 'optionally applies an assistant-shape template'). Baseline 3 is appropriate since the schema does the heavy lifting and the description adds little syntactical detail.

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

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

The description names a concrete action and resource ('seeds the caller's assistant graph') and clarifies scope ('onboard the workspace end-to-end'). It does not, however, differentiate itself from close siblings like create_graph or instantiate_template, which an agent might otherwise pick for the same goal.

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

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

Usage is implied by the onboarding framing and the idempotency note implicitly tells the agent that repeat calls are safe, but there is no explicit statement of when to prefer this over create_graph or instantiate_template, nor any mention of prerequisites.

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

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

With no annotations, the description carries the full load. It does disclose real behavior beyond the schema: server-side validation against the template's schema, credential/origin preflight, creation of graphs and schedules on the caller's account, and a structured error result naming missing credentials/origins. It still omits reversibility/idempotency and permission requirements, which matter for a tool that provisions schedules. Rich but incomplete; 3 rather than 4 given the total absence of 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?

One dense sentence, front-loaded with verb+resource, then ordered clauses for validation, preflight, provisioning, return value, and error shape. No filler or restated title.

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

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

No output schema exists, and the description compensates by naming the returned nextSteps and the failure surface (structured errors listing missing credentials/origins). Given the nested, template-dependent spec object, this is nearly complete; only idempotency/repeat-invocation behavior is unaddressed.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning: spec is validated against the template's own schema (a dynamic, per-template shape) and templateId must come from list_templates. That clarifies the nested-object parameter beyond the schema's terse wording.

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 (instantiate) and resource (automation template), names where templateId comes from (list_templates), and enumerates the concrete effects: graph/schedule build-out on the caller's account. An agent can distinguish this from create_graph, which builds nodes manually rather than from a template.

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?

Positions the tool in a workflow by pointing to list_templates as the source of templateId, and the "re-runs credential/origin preflight" phrasing implies prerequisites must already be satisfied. It never states when NOT to use it or contrasts it with create_graph/start_run for manual construction, so it stops short of explicit routing.

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

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

No annotations are provided, so the description carries the burden. It discloses the access scope (owned + shared) and the returned tagging (role, MCP slug when published), which is useful behavioral context. But it omits permissions required, pagination behavior, and result limits — meaningful gaps for a listing tool with zero annotation coverage.

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

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

One dense sentence, front-loaded with the verb and resource, that also carries the scope and return-shape detail. No waste.

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

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

For a no-param listing tool with no output schema, the description covers what is returned (graphs, access role tags, MCP slug) and the visibility scope. It is nearly complete, missing only pagination/ordering 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?

Zero parameters, so the schema contributes nothing and there is nothing for the description to document. Per the rubric, a 0-param tool has a baseline of 4.

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 (list) and resource (graphs) with precise scope — the caller's own graphs plus those shared with them. This clearly distinguishes it from get_graph (single graph) and list_templates (templates), so the agent can tell the siblings apart.

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

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

Usage is implied by the plural 'list' and the scope statement, but there is no explicit when-to-use/when-not guidance or naming of alternatives (e.g., get_graph for a specific graph). Adequate, not rich.

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

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

With no annotations, the description carries the full burden. It does disclose the return content well (entry fields listing spec keys plus per-field question text for conversational collection), which is meaningful behavioral context. It says nothing about read-only semantics, pagination, or size limits, leaving gaps for a zero-annotation tool.

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

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

A single sentence that is front-loaded with the tool's identity and then explains the relationship to instantiate_template. It is dense but each clause earns its place; the em-dash nesting slightly taxes 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?

No output schema exists, so the description must describe returns, and it does so reasonably (entry fields name spec keys with per-field question text). For a zero-parameter list tool this is close to complete, missing only pagination or ordering 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?

The tool takes zero parameters, so there are no parameter semantics to document; the baseline of 4 applies. The description instead focuses its detail on the output, which is appropriate here.

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

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

The description identifies the tool as the automation catalog an agent can instantiate, a specific resource that is clearly distinct from the sibling instantiate_template (which consumes a spec). The noun phrasing never states a clean verb like 'list', but the resource and its scope are unambiguous.

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

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

Usage is implied rather than stated: by explaining that each entry maps to instantiate_template's spec keys, it suggests calling this first to discover what to pass. There is no explicit when/when-not guidance or naming of alternatives beyond the indirect reference.

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

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

With no annotations, the description carries the full behavioral burden and does so: it discloses that the in-flight model call finishes, how mid-tool-loop vs between-hop pauses differ (checkpoint continued in place vs next hop parked before starting), required permission level, and which run states produce errors. This is substantially more than the name implies.

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

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

One dense paragraph, front-loaded with the action, the boundary at which it takes effect, and the resumability contrast, before moving to mechanics and preconditions. 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 mutation tool with no output schema and no annotations, the description covers effect timing, state transitions, permission requirements, and error conditions — everything an agent needs to call it correctly.

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

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

Schema coverage is 100% for the single runId parameter, so the schema already documents it ('The run id'). The description adds no format, syntax, or sourcing detail beyond that, so the baseline 3 applies.

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

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

States a specific verb ('pause') and resource ('a run') and immediately scopes it to the next step/hop boundary, distinguishing it from both cancel_run (terminal) and resume_run (the resumption path). An agent can differentiate it from every sibling 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?

Explicitly names the alternatives and the condition that selects them: use resume_run to continue, and pause is preferred over cancel_run because cancel is terminal. It also states the precondition (editor access on the run's graph) and the failure cases (already-parked or terminal runs error), so when-not-to-use is covered.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses two traits that structured data does not: the key is stored encrypted and is never echoed back in the response. It still omits important mutation semantics such as overwrite/idempotency behavior and any auth or validation requirements.

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

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

Two tight sentences, front-loaded with the action and the security-relevant return behavior. Every clause earns its place with no redundant restatement of the tool name.

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?

Because there is no output schema, the description rightly states what comes back (a credential summary, not the key). For a credential-writing tool with no annotations, though, it should also address re-provisioning/overwrite behavior and error conditions to be fully complete.

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

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

Schema description coverage is 75% (label is undocumented), and the schema already explains apiKey, baseUrl, and provider. The description adds no parameter-level meaning beyond that, so the baseline of 3 is appropriate with the schema doing the heavy lifting.

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

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

Specific verb (Store) plus a precise resource (a provider API key in the caller's encrypted credential vault). It is instantly distinguishable from all siblings, which deal exclusively with graphs, runs, and templates.

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 "the result of a conversational 'paste your key' step" implies the context in which this tool fires, which is useful. However it gives no explicit when-to-use/when-not-to-use guidance, no prerequisites, and does not say whether calling it again for the same provider overwrites or creates a duplicate.

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

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

With no annotations present, the description carries the full burden and does so well: it distinguishes checkpoint continuation (paused, resumes the parked hop) from re-execution (errored, re-runs the failed node), flags the conditional argument requirement, and discloses the editor-permission requirement. These are non-obvious behavioral traits an agent could not infer from 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, and the core action is front-loaded with the per-state behavior clauses following. Every clause carries information the caller needs.

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

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

For a two-parameter mutation tool with no annotations and no output schema, the description covers state-specific behavior, the conditional argument, and permissions. It stops short of describing what the resumed run returns or how partial progress is surfaced, which is a minor gap.

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

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

Schema description coverage is 100%, so runId and maxCostUsd are already documented in the schema, including the conditional requirement for maxCostUsd. The description largely restates this ('requires a new maxCostUsd in the arguments'), adding no format, range, or constraint detail beyond structured data.

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 (resume) plus resource (run), and immediately scopes it to two distinct states (paused, errored) with different semantics. An agent can distinguish this from cancel_run, pause_run, or start_run without opening any schema.

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

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

Gives clear conditional guidance: a budget_exceeded run requires a new maxCostUsd, and editor access on the run's graph is a prerequisite. It does not explicitly contrast with start_run for non-resumable states, but the state conditions are specific enough to route correctly.

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

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

With no annotations, the description carries the disclosure burden and does well: it declares read semantics implicitly ('search'), discloses a tenancy/auth boundary ('graphs the caller owns'), and describes the return shape ('excerpts with run/node/hop provenance'). It omits operational traits such as rate limits or result-count behavior, keeping it short of a 5.

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

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

Two dense sentences with no filler: the first delivers purpose, scope, and the sibling comparison; the second delivers the return format. The most decision-relevant information is front-loaded.

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

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

There is no output schema, but the description compensates by naming the returned excerpts and their provenance. For a 3-parameter, fully documented read tool the definition is essentially complete; only marginal operational detail is absent.

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

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

Schema description coverage is 100%, so limit, query, and graphId are already fully documented in the schema. The description adds only the framing of 'hop logs (inputs and outputs)' and reiterates the owned-graph scoping around graphId, which is marginal value beyond the structured fields.

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 (full-text search across previous runs' hop logs) plus the exact scope (inputs and outputs, on graphs the caller owns). It explicitly distinguishes itself from the in-run search_runs variant and from siblings like get_run and list_graphs, which are lookup-by-id rather than text search.

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?

Clearly frames this as cross-run, past-run recall as opposed to the in-run tool, and constrains scope to owned graphs, which tells the agent when this tool applies. It does not, however, explicitly say when to prefer get_run or list_graphs instead, so there is no 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?

With no annotations, the description carries the full burden and does well: it discloses the credential's scope (topology and hop status, never hop content), its read-only nature, and the required access level. It omits whether re-minting invalidates prior tokens, revocation behavior, or that the token itself is the returned artifact.

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: the action and artifact come first, then the scope limitation, then the access requirement. No filler, and the em-dash clause carries real information rather than restating the tool name.

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

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

For a two-parameter, no-output-schema tool the description covers purpose, authorization, and token scope, which is most of what an agent needs. It could be slightly more complete by stating that the minted token is the return value and what happens on repeat calls.

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 runId and the ttlSeconds range/default are already documented in the schema. The description adds no format or behavioral detail about either parameter, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb ('Mint') and resource ('read-only share/embed token for one run'), and pins down the exact token semantics by equating it to POST /runs/:id/share. No sibling tool does anything similar, so it is unmistakably distinct from get_run, search_runs, or start_run.

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 the operative condition for use ('for one run') and a prerequisite ('Requires owner or editor access'), plus an API-equivalence reference that tells the agent exactly what calling this produces. It stops short of naming when not to use it or how it relates to a revoke/unshare path, 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?

With no annotations, the description carries the full behavioral burden and does so well: it discloses that execution is asynchronous ('Returns immediately'), that explicit graph membership (owner or member row) is required, that cost is bounded by the caller's monthly spend cap on that graph, and that the saved snapshot (not the draft) is what executes. These are exactly the non-obvious traits an agent needs before firing a launch.

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 tight sentences, front-loaded with the action and followed by behavioral constraints in order of importance (mode, sync/async, permission, cost). Every clause carries information; nothing is repetitive or padding.

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

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

There is no output schema, and the description compensates by stating what the call returns behaviorally ('returns immediately') and how to obtain results ('poll get_run for status'). Combined with the disclosed permission and spend constraints, an agent has everything needed to invoke and follow through correctly.

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

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

Schema description coverage is 100%, so the schema already documents graphId, input, and context, giving a baseline of 3. The description adds no per-parameter detail (no format hints, no interplay between input and context) 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?

Opens with a specific verb+resource pair ('Launch a run on a graph') and immediately narrows scope with 'pinned mode (the saved snapshot)' and 'attributed to the caller.' This cleanly separates it from siblings like create_graph, resume_run, and get_run without the agent needing to open any schema.

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

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

It gives clear usage context by naming get_run as the required follow-up for status, which routes the agent correctly after the call. It does not, however, contrast itself with alternatives such as resume_run (restarting a paused run) or cancel_run, so the when-not-to-use case 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?

With no annotations provided, the description carries the full burden and does so well: it discloses the exact op application order (remove edges → remove nodes → update nodes → add nodes → add edges), that it returns per-op results, the assistant-graph refusal and force override, and the authorization model (editor role required, scoped API keys excluded). This is unusually rich behavioral disclosure for a mutation tool.

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

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

Three dense sentences, front-loaded with the core action and ordering, then constraints. Every clause conveys actionable information with no filler.

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

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

For a 7-parameter mutation tool with no annotations and no output schema, the description covers safety, ordering, failure behavior, and return shape ('reports per-op results'). An agent has enough to invoke it correctly and anticipate the refusal path.

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

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

Schema coverage is only 57%, so the description compensates by explaining force's purpose, enumerating the op arrays and their ordering, and pointing addNodes at create_graph's node fields. It does not elaborate on the edge spec fields (condition, priority) or how patch semantics work in updateNodes, leaving some parameter meaning to the schema.

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

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

States a specific verb and resource ('Edit a graph's topology') plus the concrete operations (add/remove/rename nodes, rewire edges) and the batching scope ('in one call'). This clearly separates it from siblings like create_graph, get_graph, and draft_node, which an agent can distinguish without opening any schema.

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

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

Gives clear usage context and hard exclusions: it refuses on the workspace's assistant graph unless force is set, requires the editor role, and cannot be called by scoped API keys. It does not explicitly name a preferred alternative for graph creation versus editing, so it stops just short of full when/when-not/alternative routing.

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