skforecast-ai

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

Annotations already declare this as a non-destructive, non-open-world write (readOnlyHint=false, destructiveHint=false). The description adds useful behavior beyond that: it writes predictions and metrics to CSV files as a side effect. However, it says nothing about permissions, runtime, or whether repeated runs overwrite output files.

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 the mechanism and output front-loaded before the return value. No filler, though the trailing 'Returns a backtest id' is somewhat redundant given an output schema exists.

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, the return value need not be explained, and the description still summarizes it. It conveys the CSV side effects and the cv_id prerequisite; only explicit alternative-tool routing and overwrite/permission behavior are 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 schema already fully documents cv_id and the optional plan_id with its null default semantics. The description adds no additional parameter meaning, which matches the baseline 3 when the schema does the work.

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 ('Backtest') and resource ('a plan') plus the mechanism ('with a cross-validation strategy') and the artifact it produces. This distinguishes it from siblings like forecast or compare, though it never names them 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?

Usage is only implied: the required cv_id 'Id returned by create_cv' hints that a cross-validation strategy must exist first, but the description gives no explicit when-to-use or when-not-to-use guidance versus forecast, compare, or refine_plan.

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 it is not read-only, not destructive and not open-world; the description goes further by disclosing that it reports per-candidate progress, that it 'can be cancelled between candidates', and that a failing candidate context matters ('a candidate that fails is ranked last' lives in the schema). The long-running/cancellable trait is exactly the kind of behavior annotations cannot express, though cost/scaling implications of many candidates are not stated.

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 operation and ranking rule, followed by runtime behavior and return contract. Every clause carries information and nothing is padded.

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

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

An output schema exists, so return values need not be spelled out, yet the description still names the key return artifacts (comparison id, winner plan id). Combined with 100% schema coverage and modest parameter count, the definition is nearly complete; only cost/duration expectations for many candidates are 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 schema already documents all five parameters in depth. The description only reasserts that `metric` is the ranking key and references `links.best_plan_id` as the winner pointer, adding marginal meaning beyond the structured fields. Baseline 3 is appropriate.

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

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

The description names a concrete verb pair plus resource ('Backtest several configurations ... and rank them by `metric`'), and the scope 'several configurations on the same folds' implicitly distinguishes it from the single-run `backtest` sibling. An agent can pick this tool for candidate comparison 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?

Usage is implied rather than stated: comparison of multiple candidate configs on shared CV folds is clearly the use case, but there is no explicit 'when to use this vs `backtest`/`refine_plan`' and no preconditions (e.g. that a `cv_id` from `create_cv` is mandatory) in the prose. The routing comes from the reader's inference, not the text.

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

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

Annotations already declare destructiveHint=false and readOnlyHint=false, covering the mutation/safety profile. The description adds that the response reports its own 'cost' and returns a cv id, which is real behavioral context. It says nothing about persistence, lifetime, or whether the strategy can be modified or deleted afterwards.

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

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

Three short sentences, front-loaded with the purpose, no filler. The final sentence 'Returns a cv id' is largely duplicative of the output schema, which costs it 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?

With an output schema present, return values need not be explained, and the schema documents all eight parameters thoroughly. The definition is complete enough to invoke correctly; only the relationship to sibling tools 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 description coverage is 100%, and the eight parameters have detailed inline descriptions covering gap, refit, fold_stride, skip_folds, and initial_train_size semantics. The description adds nothing about parameters, so baseline 3 applies; the schema carries the full parameter burden.

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 artifact: 'Build a time series cross-validation strategy (TimeSeriesFold) for a plan.' An agent can tell it creates a CV configuration rather than running a backtest. It doesn't explicitly differentiate from the sibling 'backtest' or 'forecast', so it stops short of a 5.

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

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

No statement of when to use this tool versus alternatives, and no prerequisites. With siblings like 'backtest' present, the description never says whether this must be created first or how it relates to them. Usage must be inferred entirely.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one useful behavioral nuance — that it returns the historical creation payload rather than the object's current state — but says nothing about missing records, pagination, or truncation.

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 sentence, front-loaded with the action, with the parenthetical payload list earning its place by clarifying scope. It is slightly dense ('the response that created an object') and would benefit from a touch more precision, but there is 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?

With an output schema present, return-value explanation is not strictly required, and annotations cover safety, so the definition is minimally viable. It is still missing usage context and any hint of error behavior when no creation record exists.

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

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

There is a single parameter and schema coverage is 100%; the schema documents object_id as 'Id of a registered object.' The description adds no format, sourcing, or lookup guidance for the id, so the baseline 3 applies.

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

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

The description gives a specific verb ('Return') and a precisely scoped resource ('the response that created an object'), even enumerating the payload parts (summary, links, notices, files). It does not, however, distinguish itself from siblings like list_objects or get_code, which an agent might reasonably confuse it with.

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

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

There is no statement of when to use this tool versus alternatives, nor any prerequisite (e.g. that the object must be registered or that a creation record must exist). The reader must infer the trigger condition entirely.

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 it is a non-read-only, non-destructive, closed-world operation. The description adds real behavioral context beyond that: predictions and metrics are written to CSV files (a side effect) and a forecast id is returned for chaining, which the annotations do not 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?

Three tight sentences, front-loaded with the action and the two modes, then the side effects and return value. No filler, though the second clause is slightly compressed.

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 annotations covering safety and an output schema covering return values, the description only needs to frame the modes and side effects, which it does. Nothing critical is missing, though the relationship to sibling tools remains 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% and the parameter descriptions are highly detailed (exog_path semantics, test_size null vs integer vs fraction). The description adds little beyond the schema, only naming `test_size` as the evaluation switch, so the baseline 3 is appropriate.

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

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

The description gives a specific verb+resource ('Run a plan') and clearly splits into two operating modes: forecast the future, or evaluate on a test set. It is distinguishable from generic siblings, though it never contrasts itself with the adjacent `backtest`/`compare` 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?

It explains when each internal mode applies (default/null `test_size` to forecast, a value to evaluate), which is genuine conditional guidance. However, it never addresses when to reach for this tool versus siblings like `backtest` or `compare`, leaving the selection implicit.

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, destructiveHint=false and a closed world, so the safety profile is covered. The description does add one real behavioral fact ('would run for a plan' implies no executed script exists for plans), but it says nothing about permissions, script size, or what happens for objects with no associated code, which matters given the broad object_id scope.

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

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

A single front-loaded sentence with zero filler; the colon construction keeps the core action first and the qualification second. Slightly compressed, but every clause earns its place.

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

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

An output schema exists, annotations cover safety, and all parameters are documented, so the description need not explain return values. The only remaining gap is the absence of explicit routing against the object-inspection siblings, which is minor for a tool this simple.

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 both object_id (plan, CV strategy, backtest, forecast, comparison) and candidate (the comparison candidate, null for the best). The description adds no parameter-level meaning beyond that, which is the correct 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+resource ('Return the Python script of an object') and adds the discriminating nuance that it is the script that ran, or the one that would run for a not-yet-executed plan. This clearly separates it from metadata-style siblings like describe_object and list_objects, though it never names those siblings.

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

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

Usage is only implied: retrieve code when you need the actual script rather than a description. There is no explicit 'use this instead of describe_object' routing, no mention of prerequisites, and no when-not-to-use guidance, even though sibling tools clearly overlap in the object-inspection space.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds that the payload is a traceback plus code, which is useful content-level context. It does not say what happens if object_id points at a non-failed object, which is the main remaining behavioral gap.

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

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

A single sentence with the payload front-loaded ahead of the eligible input types. It is efficiently sized, though the trailing 'or of a failed candidate of a comparison' clause is slightly convoluted.

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

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

The tool is a simple read with an output schema and full parameter documentation, so return-value explanation is unnecessary. The description covers what is fetched and from which object; only the failure case for a successful/non-failed id 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 description coverage is 100%, so both candidate and object_id are already documented in the schema (failure_id or comparison id). The description restates that a failed comparison candidate is a valid target but adds no format or syntax detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource: it returns the traceback and the code for a failed run or a failed comparison candidate. That is concrete and distinguishable from the raw code-retrieval sibling get_code. It stops short of explicitly naming when to prefer it over get_code or describe_object.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative routing. The phrase 'of a failed run or of a failed candidate of a comparison' hints at the eligible inputs but leaves the agent to infer that this is the debugging entry point versus get_code or describe_object.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered without the description. The one added fact is that only ids (not full objects) are returned, which is useful but thin; no mention of ordering, volume, or empty results.

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 short sentence with no filler, and the id-only scope is stated up front. It is efficient, though the terseness is part of why scope is unclear.

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 annotations cover the safety profile, so the description is not required to carry much. Still, for a discovery tool with six possible kinds, the definition leaves the agent guessing what domain it enumerates.

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 single `kind` parameter is fully described in-schema ("Only the objects of this kind. Null for every kind."), so the schema carries the burden. The description adds nothing about the filter or kind values, leaving this at the baseline 3.

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 ("List the ids of the objects"), but "the objects the server keeps" never says what an object is here. Sibling tools (profile, plan, cv, backtest, comparison, forecast) imply the domain, yet the description does not name any of them or distinguish itself from describe_object.

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

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

No when-to-use guidance and no named alternative. An agent wanting object details rather than ids gets no routing hint toward describe_object, and there is no statement of prerequisites or expected result size.

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 indicate it is not read-only and not destructive, so the agent knows it creates a persistent artifact. The description adds that it returns a plan id, which is useful for chaining. However, it does not disclose any side effects, storage behavior, or whether the plan is mutable later, leaving gaps for a state-changing operation.

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?

Extremely concise: one sentence for the action and one for the return value. It is front-loaded with the key verb and purpose, with zero wasted words.

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

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

Given the complexity (14 parameters, many optional with defaults, and an output schema for the return), the description is nearly complete. It states the required inputs (profile and horizon) and the output (plan id), and the schema covers all parameter details. The only missing piece is the relationship to sibling tools (e.g., that 'forecast' takes the plan id), but the core information for invocation is present.

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 extensive per-parameter documentation in the schema already provides deep semantics (defaults, allowed values, constraints). The description only lists categories of configuration at a high level; it adds no new meaning beyond the schema, which is acceptable given full coverage but offers no extra value.

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

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

The description states a specific verb ('Build a forecasting plan') and enumerates exactly what the plan captures (lags, window features, metric, preprocessing, interval) from its inputs (a profile and a horizon). It clearly distinguishes the tool from siblings like 'forecast', 'backtest', and 'refine_plan' by naming the building activity and its artifact.

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

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

There is no explicit guidance on when to use this tool versus alternatives like 'refine_plan' or directly invoking 'forecast'. The description implies its role as a setup step but does not state prerequisites (e.g., must call 'profile' first) or dependencies (e.g., 'forecast' consumes the returned plan id).

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is already covered. The description adds that a profile id is produced (a persistent artifact to reuse later), which is useful, but says nothing about side effects, re-profiling the same file, or whether the id is required by siblings.

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

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

Two short sentences, zero filler, with the action and the output front-loaded. Nothing is repeated from the schema or annotations.

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 full parameter coverage, the description only needs to say what the tool is and what it returns; it does both. The one gap, chaining guidance toward plan/forecast, is minor for a profiling entry point.

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 all seven parameters are already documented in detail (separator detection, target semantics, exog defaults, date/series-id columns). The description adds no parameter-level meaning 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 concrete verb+resource ('Profile a CSV file') and enumerates what profiling yields: frequency, series, exogenous columns, and a recommended forecaster and estimator. That distinguishes it from the downstream siblings (plan, forecast, backtest), though it never names them 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?

Usage is only implied: the mention of a 'recommended forecaster and estimator' and the returned profile id suggest this is a precursor step before plan/forecast, but the description never says when to call this versus plan or forecast, nor any prerequisites or 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, and the description usefully adds that the operation is non-destructive: it returns a new plan id and leaves the original intact. It does not mention validation failure modes (e.g. incompatible overrides) or any cost, but the key mutation semantics are disclosed.

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 zero waste, and the return/immutability fact is front-loaded alongside the purpose.

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 need no elaboration, and the description still notes that a new plan id is returned. For a tool whose override semantics live in the schema, this is nearly complete; only guidance on choosing between refine_plan and plan 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% and the $defs go into deep detail on each override, including null/omitted semantics, so the schema carries the burden. The description adds nothing parameter-specific beyond the example in the schema itself; 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+scope: building a new plan derived from an existing one by changing decisions. This implicitly separates it from the `plan` sibling (which builds from scratch), though no sibling is named 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?

Usage is only implied by 'from an existing one' — the agent can infer this is the tool for modifying an already-created plan rather than creating a fresh one, but there is no explicit when-to-use/when-not guidance or reference to `plan`/`forecast` alternatives.

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