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

With no annotations, the description must carry the behavior and safety burden. It discloses that lifecycle state changes, which is useful, but does not say whether archiving is reversible, whether it blocks prediction or comparison workflows, or what side effects occur. 'Update its lifecycle state' is a vague gesture at consequences.

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 nine words, front-loaded with the action and object, and contains no filler. The added 'lifecycle state' clause earns its place by clarifying the broader 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?

For a state-changing tool with no annotations and no output schema, the description omits lifecycle details, irreversibility, return value, and any prerequisites. It could be called by an agent, but not with confidence about consequences or downstream effects.

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

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

The description mentions no parameters and does not explain model_id semantics beyond the schema. Context reports 0% schema description coverage, so the description does not compensate; though the single parameter name is fairly self-explanatory, there is no guidance on identifiers, format, or required state.

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 opens with a clear imperative verb ('Archive') and names the specific resource ('a model record'), then adds that it updates lifecycle state. Among siblings focused on prediction, fitting, and comparison, archive_model is unambiguous and not a tautology.

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 guidance is provided about when archiving is appropriate, whether archived models are excluded from other workflows, or when to prefer a sibling like compare_models or get_model_status. The agent must infer usage solely from the verb and tool name.

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 supplied, the description carries the full behavioral burden. It usefully states that calibration produces a new artifact rather than modifying in place and that lineage is recorded. However, it does not disclose potential side effects such as long-running MCMC computation, random-seed behavior, 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?

A single sentence delivers the action, the subject, the mechanism, and the output with no filler. The most decision-relevant information is front-loaded ('Calibrate an existing MMM') before the more detailed outcome.

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

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

For a complex calibration tool with no output schema and no annotations, the description is adequate but not complete. It communicates the core purpose and the main output behavior, but omits details such as the necessity of a prior fit_mmm step, how sampler settings affect the run, and what the lineage-linked artifact means operationally.

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

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

The description only loosely implies the required inputs ('existing MMM' and 'experimental lift test measurements') without naming model_id, lift_tests, or sampler. Since schema description coverage is 0% and the top-level parameter has no description, the tool description needed to document the parameter structure; it does not. Nested schema $defs include per-field descriptions, which partially help, but this dimension credits the description 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?

The description opens with the specific verb 'Calibrate' and a precise object, 'an existing MMM', and names the method, 'experimental lift test measurements'. It also states the outcome ('a new calibrated model artifact linked via lineage'), which separates it from siblings like fit_mmm or recommend_next_measurement.

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 'existing MMM' clearly establishes the prerequisite that a fitted model must already exist, and 'experimental lift test measurements' identifies the data condition that triggers this tool. It does not explicitly list exclusions or alternatives, but the context is clear enough for an agent to distinguish this from initial model fitting.

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 of disclosing behavior. It does state that only queued or running jobs are eligible, which is useful. However, it does not mention irreversibility, what happens after cancellation, what errors may occur, or whether any related resources are affected. The state constraint is a positive signal, but the description is not fully transparent.

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

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

A single, front-loaded sentence with no filler. Every word carries meaning: 'currently queued or running' is essential and 'background job' identifies the resource. Nothing extraneous is included.

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 simple one-parameter contract and no output schema, the description is minimally adequate. It covers the core purpose and the eligibility condition, but lacks details an agent might need for robust invocation, such as how to obtain a valid job_id or what response to expect. The low complexity prevents a lower score, but the missing behavioral details prevent a higher one.

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

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

The schema has 0% description coverage for parameters, and the description does not explain job_id at all. The parameter is somewhat self-evident from the tool name, but the description adds no guidance on where to find it, its format, or how it relates to the job lifecycle. For a low-coverage schema, the description should compensate; it does not.

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

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

The description uses a specific verb ('cancel') and a clear resource ('background job'), and adds a meaningful state qualifier ('currently queued or running'). This distinguishes it from sibling tools like get_job_status, list_jobs, and submit_fit_mmm_job without needing to open the schema.

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

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

The phrase 'currently queued or running' gives an implicit when-to-use condition: cancel only jobs in those states. It implies reliance on job IDs from submission or listing tools, though it does not explicitly name alternatives such as get_job_status or list_jobs for retrieving job IDs. Clear context, but no 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. Beyond naming the action, it does not state whether the tool is read-only, what output format is returned, whether any side effects occur, or any prerequisites. 'Compare' suggests a read operation, but this is inference, not disclosure.

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

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

The description is a single front-loaded sentence with no wasted words. It packs the verb, the resource, the scope ('multiple'), and the specific comparison dimensions into a compact, scannable form.

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 one required parameter documented in the schema, no annotations, and no output schema, the description gives the core purpose but omits behavioral context such as read-only status and return format. It is adequate for a straightforward comparison tool but leaves the agent to infer important execution details.

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 description does not mention model_ids, and the schema coverage is reported as 0%, so a strict reading says the description fails to compensate. However, the input schema itself contains the description 'List of model IDs to compare' for the sole parameter, which fully explains its meaning. The description adds contextual value by stating what the comparison covers, but does not directly elaborate the parameter syntax.

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

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

The description uses the specific verb 'compare' with a clear resource: 'multiple fitted MMMs', and names the aspects compared: diagnostics, predictive metrics, and lineage. This clearly distinguishes it from siblings like diagnose_mmm (single-model diagnostics) and select_best_model (selecting one), so an agent can tell them 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?

The description implies the appropriate use case—when multiple fitted MMMs need to be compared—but provides no explicit guidance on when not to use it or which alternative to choose. It never mentions select_best_model or diagnose_mmm as alternatives, so usage context is implied rather than stated.

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

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

With no annotations provided, the description carries the behavioral burden. It does disclose that the operation runs multiple temporal folds and evaluates out-of-sample predictive RMSE/NRMSE, which is useful. However, it remains silent on side effects, computational cost, whether the model must already be fitted, and the exact return structure.

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 tight and front-loaded: two sentences, no filler, with the primary action stated first. The second sentence adds meaningful outcome information without redundancy.

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 no annotations, no output schema, and a wrapped input object, the description is too thin for safe autonomous invocation. An agent would need to infer that model_id is required and would have no clear idea what the returned RMSE/NRMSE artifact looks like or when this evaluation is appropriate.

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

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

The description never references model_id, n_init, step_size, forecast_horizon, or sampler settings, and schema description coverage is reported as 0%, so the description was expected to compensate. The phrases 'rolling' and 'temporal folds' only vaguely hint at fold-related parameters and do not clarify the required fitted model ID.

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 is specific: 'Run rolling Time-Slice Cross-Validation with PyMC-Marketing' names a clear verb and resource, and it states the evaluation outcome (out-of-sample RMSE/NRMSE across temporal folds). This distinguishes it from sibling tools like fit_mmm, diagnose_mmm, or evaluate_prior_sensitivity.

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 provides no guidance on when to use this tool versus alternatives such as diagnose_mmm, evaluate_prior_sensitivity, or calibrate_mmm. It also does not state prerequisites such as requiring a successfully fitted model before cross-validation can run.

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 discloses the categories of diagnostics performed and the gating behavior, but it does not say what happens when diagnostics fail, whether the operation is read-only, or what the return value looks like. This is a moderate gap for a gating tool.

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

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

The description is a single, efficient sentence with no filler. The most important information ('Mandatory diagnostic gate') is front-loaded, and every clause adds specific value.

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 tool, the description covers its purpose and placement well. However, it lacks any information about output format, failure semantics, or how results should inform next steps. Given the absence of annotations and output schema, the description is not 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 0% and the description never mentions model_id. The parameter name is somewhat self-explanatory, but the description adds no meaning beyond the schema field name, so it only minimally compensates for the coverage gap.

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 ('Checks') and a precise resource (sampler health, posterior predictive coverage, predictive error, residual behavior), and frames the tool as a 'Mandatory diagnostic gate' that precedes decision tools. This clearly differentiates it from the many prediction and optimization 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?

The description explicitly says this runs 'before decision tools may run,' giving clear when-to-use context. It does not name specific alternative tools or exclusions, but the mandatory-gate framing strongly signals its required position in the workflow.

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 burden of behavioral disclosure. It does reveal that the tool computes a discounted net present value and requires fitted models, but it does not state side effects (e.g. read-only vs model mutation), compatibility expectations between the two model IDs, or the shape of the returned estimate.

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 focused sentence that leads with the action and resource, then adds method details and concrete example models. Every clause earns its place 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?

The description is adequate for a read-only estimation task and the schema covers parameter semantics. However, with no output schema and no annotations, it omits information about return format, error behavior if models are not fitted or incompatible, and whether this should be used instead of close siblings like predict_customer_clv.

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 description does not explain any parameters, but the input schema fully documents each nested field (top_n, future_t, discount_rate, value_model_id, purchase_model_id) with descriptions and defaults. Since the schema does the heavy lifting, the missing parameter detail in the description is acceptable.

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

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

The description uses a specific verb ('Estimate') and a concrete resource ('discounted net present Customer Lifetime Value (CLV)'), and it identifies the key inputs (fitted purchase and monetary value models). However, it does not explicitly differentiate this from the sibling tool predict_customer_clv, which likely performs a similar CLV prediction.

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 the tool: after fitting a purchase model (e.g. BG/NBD) and a monetary value model (e.g. Gamma-Gamma), because it combines those fitted models. It does not state when not to use it or which sibling to prefer instead, such as compare_models or predict_customer_clv.

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?

There are no annotations, so the description carries the behavioral burden. It does explain that the tool evaluates sensitivity under alternative priors, which implies a read-only diagnostic analysis, but it does not disclose the output format, side effects, or whether it refits models. The behavioral intent is clear 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?

The description is a single, front-loaded sentence with no filler or redundancy. It packs the key resource, the exact quantities of interest, and the condition being varied into a compact and readable form.

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 tool, the description provides enough to understand the core purpose and the sensitivity dimensions being examined. However, without an output schema or annotations, it should ideally say what kind of result is returned (e.g., summary tables, plots, metrics) and whether any fitted model prerequisite applies. The missing return-value clarity prevents a higher score.

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 only parameter, model_id, is already described in the schema as 'Model ID to evaluate for prior sensitivity'. The tool description adds no parameter-level detail, but with a single obvious parameter this is not a significant gap. The description neither enriches nor contradicts the schema.

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

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

The description uses a specific verb ('Evaluate') and clearly identifies the resource: sensitivity of commercial conclusions, specifically channel rank order and iROAS, under alternative adstock and saturation priors. This distinguishes it from sibling tools like model fitting, prediction, or budget optimization even without naming 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?

The context of use is implied: this should be used when one needs to check whether prior choices materially affect commercial conclusions. However, it does not explicitly say when to use it versus alternatives like diagnose_mmm, compare_models, or cross_validate_mmm, nor does it provide exclusions or 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?

No annotations are provided, so the description must carry the behavioral disclosure burden. It discloses deprecation status and the model family, but not what happens during fitting, whether artifacts are written, how long it runs, or what the return value is.

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 plus a short parenthetical deprecation note. Every token earns its place, and the most important behavioral signal (deprecation) is clearly set off.

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 a complex nested config requiring column mappings, sampler settings, and model types, one sentence is incomplete. There is no output schema and no annotation coverage to offset the missing details about required config, return values, or side effects.

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 description does not mention any parameters or config fields. The nested schema has its own property descriptions, but the tool description itself adds no parameter meaning to compensate for the low coverage.

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

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

The description states a specific verb ('Fit'), a specific resource ('Bayesian Customer Lifetime Value model'), and a specific input domain ('RFM transaction data'). It also names sibling alternatives, which differentiates it from the many other model-fitting 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?

Explicitly warns the tool is deprecated and instructs the agent to prefer fit_purchase_model or fit_value_model. This is direct when-not-to-use guidance, even if it does not detail when to choose between those two alternatives.

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 must carry the burden of behavioral disclosure. It only adds the constraint 'No arbitrary Python is accepted' and lists supported types, but does not mention side effects (e.g., whether a model is overwritten), compute time, return value behavior, or failure modes. This is a significant gap for a fitting 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?

The description is compact and front-loaded with the main purpose. The listing of types is fairly long but directly relevant to configuration. It avoids redundant filler, though some enum lists duplicate schema information.

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

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

For a complex tool with a nested config object and no output schema, the description is too high-level. It does not explain return values, synchronous/asynchronous behavior, prerequisites (like registered dataset), or consequences of fitting. The schema covers parameter syntax, but the description leaves key operational context 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 0% in the textual description, but the input schema itself has rich descriptions for nested parameters (e.g., dataset_id, date_column, AdstockConfig). The description adds the 'No arbitrary Python' constraint and summarizes the type enums, which is marginal value beyond the schema. Since the schema already carries parameter explanations, a baseline of 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 states a specific verb ('Fit') and resource ('Bayesian Marketing Mix Model'), and clearly differentiates itself with 'No arbitrary Python is accepted' – signaling this is a controlled-config tool rather than a code execution tool. It also names the supported adstock and saturation types, which helps distinguish it from prediction/analysis 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?

No guidance is given on when to use this tool versus alternatives like submit_fit_mmm_job (likely async) or other model-fitting tools. It does not mention prerequisites such as the dataset being registered, nor does it state that this is a blocking operation.

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 a notable behavior: normalization of column names, which is helpful. However, it does not mention that fitting runs MCMC (evident from sampler schema), potential runtime expectations, or that it likely requires a registered dataset (implied by dataset_id). Given the Bayesian natureamented, it is a moderate disclosure.

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 concise: two sentences, with the core purpose in the first and the normalization side-effect in the second. It is front-loaded and avoids redundancy, though mentioning the model types could be omitted since they are in the schema enum, but it helps clarify 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?

For a complex Bayesian model fitting tool with an extensive sampler config, the description is sparse. It does not explain what the output will be (though no output schema exists, so this is a gap), nor does it clarify the data requirements beyond 'RFM data'. It relies heavily on the schema for parameter specifics, but lacks guidance on prerequisites or expected 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?

Schema description coverage is 0%, meaning all parameter descriptions come from the schema itself. The description adds no additional meaning beyond what the schema already states, but the schema is quite self-explanatory with detailed descriptions for each parameter. Since coverage is high in terms of schema self-documentation, a baseline 3 is appropriate; the description doesn't need to compensate.

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 clearly states the action ('Fit a Bayesian purchase/transaction frequency model'), specifies the resource (BG/NBD or Shifted Beta-Geometric), and mentions a key side effect: normalizing user column names to canonical RFM attributes. This clearly distinguishes it from sibling tools that fit value models or predict other metrics.

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 for fitting frequency models but does not explicitly state when to use this vs. alternatives like `fit_value_model` or `fit_clv_model`. It mentions two model types, suggesting when each might be appropriate (continuous vs. contractual), but there is no explicit guidance on when to select this tool over 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?

No annotations are present, so the description carries the full burden. It discloses that this is Bayesian and Gamma-Gamma, but not what happens on invocation—whether a model artifact is saved, how long MCMC runs, or what output is returned. Sampler settings exist in the schema, but the description does not explain their behavioral effect.

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 one efficient sentence with two useful clauses. No filler or redundant restatement of the tool name. It could be slightly more structured by front-loading prerequisites, but overall it is compact.

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 fitting tool with no annotations and no output schema, key operational details are missing: dataset_id is required, a registered dataset must exist, and the return/result behavior is unspecified. It also does not signal how sampler configuration affects runtime. The description is not complete enough to invoke correctly from context alone.

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

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

Schema description coverage is 0% at the top-level config parameter, so the description must compensate, but it only references frequency and monetary value columns. It does not mention required dataset_id, model_type constraint, or sampler configuration. The schema's nested descriptions carry most of the 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?

Description opens with a specific verb and resource: 'Fit a Bayesian monetary value transaction model (Gamma-Gamma) on repeat customer spending.' This distinguishes it from frequency/purchase siblings by naming the value model explicitly. It does not name a sibling, but the model type and subject make the tool's role clear.

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 states required inputs ('Requires frequency and average monetary value columns'), which is a clear precondition. It does not state when to prefer this over fit_purchase_model or fit_clv_model, nor any exclusions. The usage context is implied by the model type.

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 behavioral burden. 'Does not fabricate estimates' adds a useful transparency guarantee that outputs are model-derived rather than invented, and 'fitted model' signals a prerequisite. However, it does not disclose output format, error behavior, or what happens when model_id is invalid or the model is not fitted.

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 with no filler; the core action is front-loaded and the non-fabrication guarantee earns its place. The length is appropriate for a simple one-parameter tool.

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

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

The definition is adequate for selecting the tool but not fully complete for invoking it blind: there is no output schema, no return-structure details, and no guidance on where model_id comes from. Complexity is low and the parameter is obvious, so the gaps are moderate rather than severe.

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 input schema has a single required model_id with no description (0% coverage), so the description must compensate. 'From the fitted PyMC-Marketing model' implies model_id identifies a previously fitted model, adding some meaning beyond the schema. It does not explain how to obtain or format model_id, leaving partial compensation.

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 precise operation ('Return posterior channel contribution summaries') and scope ('from the fitted PyMC-Marketing model'), which clearly distinguishes it from sibling tools like get_response_curves or optimize_budget. There is no ambiguity about the resource being operated on.

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 'from the fitted PyMC-Marketing model' implies the tool should be used after fitting a model, but it never explicitly states when to choose this over related tools like get_incremental_roas, get_response_curves, or get_posterior_plots. No alternatives or exclusions are given.

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 behavioral burden. It clearly explains the filtering rule, default threshold, and the confidence interpretation, but it does not disclose output format, error behavior, or whether the operation has side effects. It is accurate but not deeply transparent.

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 sentences with no filler. The purpose is front-loaded, followed by the core behavioral rule and default value, and every sentence adds useful information.

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

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

The tool is simple and the description covers selection and threshold behavior, but there is no output schema and the description does not explain the shape of the returned customers or whether additional fields like P(alive) are included. This leaves some ambiguity for an agent invoking the tool.

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 0%, so the description must compensate. It explains threshold_p_alive well, including the default value and the inverse confidence relationship, and it ties model_id to 'a fitted CLV model.' It does not state the valid numeric range for the threshold, but the probability context makes it reasonably inferable.

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: identify churn-risk customers from a fitted CLV model. It further distinguishes itself by specifying that it returns customers whose Bayesian P(alive) is below a threshold, which separates it from sibling prediction and model-fitting 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 it should be used after fitting a CLV model and explains how to interpret the threshold, but it does not explicitly compare against alternatives like predict_probability_alive or state when this tool should be preferred. No exclusions are given, only implied context.

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 must carry the burden. It discloses the output type (total and marginal iROAS, posterior uncertainty) and clarifies it uses the official API rather than ad-hoc computation. However, it does not mention prerequisites like whether the model must be fitted, how model_id is validated, or any failure/error behavior.

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, front-loaded with the core action and resource, with a clarifying negative statement at the end. Every word earns its place and there is no redundant or vague 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?

This is a low-complexity tool with a single required parameter and no output schema. The description covers what is returned and the source API. It could be slightly more explicit about the model_id's role, but overall it provides enough context for a correct call in most situations.

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%, so the description needs to compensate for the model_id parameter. It does not explain what model_id refers to, where to obtain it, or any format constraints. The parameter name is somewhat self-explanatory, but the description adds no semantic guidance beyond the schema.

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

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

The description clearly states the tool returns total and marginal iROAS from a specific official API, and explicitly distinguishes it from ad-hoc LLM-based calculations. This is a precise verb-resource pair that differentiates it from the sibling tools, which focus on CLV, churn, and MMM budgeting.

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

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

The description gives clear context: this is the official incrementality API for iROAS, not an improvised calculation. It does not name a specific sibling alternative, but the 'No ad-hoc LLM ROAS calculation' line provides an explicit exclusion and implicitly tells the agent to prefer this API when authoritative iROAS is needed.

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 must carry the burden, and it does state read-only retrieval and the kinds of output (status, results, error details). However, it does not disclose details such as whether the call can be polled, whether partial results appear before completion, or any ownership/authorization expectations.

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

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

One sentence with no filler or repeated schema information. The verb and resource are front-loaded, and every word contributes to the tool's meaning.

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-only status tool the basic call is fully specified, but with no output schema and no annotations, the description leaves out workflow context: expected statuses, polling behavior, and the relationship to submit/list/cancel siblings. An agent could call it correctly but would have to infer the surrounding async workflow.

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 0%, but the single parameter job_id is self-descriptive by name and title. The description adds a small amount of meaning by tying the ID to an asynchronous job, yet it does not specify the ID's format or where to obtain it (e.g., from a submit_*_job response).

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

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

The description uses a clear verb ('Retrieve') and identifies the resource precisely: execution status, results, or error details of an asynchronous job. This differentiates it from sibling status-like tools such as get_model_status and from lifecycle tools like submit_fit_mmm_job, cancel_job, and list_jobs.

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 'asynchronous job' implies use after a job has been submitted, but there is no explicit when-to-use guidance or comparison with alternatives such as list_jobs for finding job IDs or get_model_status for model-level status. The usage context is implied, not stated.

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

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

With no annotations, the description carries the full burden. It implies a non-mutating read via 'Get' and 'persisted', and 'safe failure information' hints at error semantics. However, it does not disclose permissions, side-effect absence beyond implication, or any rate/performance considerations.

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

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

The description is a single compact sentence with no filler. It front-loads the verb and resource and adds meaningful qualifiers ('persisted', 'lineage', 'safe failure information') without wasting 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?

For a low-complexity one-parameter status tool, the description names the high-level content of the response. But with no output schema, it leaves unspecified the exact return structure, what 'safe failure information' means, and how this differs from get_job_status or archive_model in practical usage.

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 only one parameter, model_id, and schema description coverage is 0%. The description contextualizes the parameter by tying it to 'model fit state', but it does not explicitly explain how model_id is used, what format it takes, or where it comes from. The parameter is self-explanatory enough to partially compensate.

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

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

The description uses a specific verb ('Get') and names concrete resources: persisted model fit state, lineage, and safe failure information. This distinguishes it from prediction, fitting, and optimization siblings, though it does not explicitly contrast with get_job_status.

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 guidance is given for when to use this tool versus alternatives such as get_job_status, archive_model, or the fitting tools. The agent must infer from the name that this is a status/retrieval tool rather than a mutation or prediction tool.

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 at all, the description carries the full behavioral burden. It discloses the output format (base64-encoded PNG/SVG), where images go (evidence envelope and MCP resources at a specific URI pattern), and the prerequisite that the model must be 'fitted and approved.' This is substantial coverage of side effects and constraints, though it omits error cases or permission requirements.

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

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

The description is a single, dense sentence that front-loads the main action and then packs in output format, caching, and supported types. No filler words. It earns its place, though it could be split into two sentences for readability without losing concision.

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?

Despite zero schema coverage and no annotations, the description conveys the tool's purpose, output format, caching side effect, and valid plot types. It falls short on explaining the format and model_id parameters in detail, and it does not clarify what 'approved' means or how failures are reported. For a tool with only three simple parameters, this is adequate but not 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 0%, so the description must compensate. It explicitly lists the allowed plot_types, which maps directly to the plot_types parameter. However, it does not explain model_id (though its role is obvious from context) or format (though the output description implies it). The description partially covers parameters but leaves some to inference.

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 opens with a specific verb and resource: 'Generate posterior visualization plots from a fitted and approved MMM.' It enumerates the exact plot types supported, which sharply distinguishes it from sibling tools like get_response_curves or get_channel_contributions. The purpose is unambiguous and not a tautology.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It implies a precondition (fitted and approved model) but does not mention when not to use it, nor does it point to any sibling for other plot types. An agent must infer usage from the tool name and sibling list.

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

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

The description discloses an important behavioral trait: it returns sampled response/saturation information rather than raw posterior arrays. However, with no annotations provided, the description carries the burden and does not mention potential prerequisites, error conditions, or whether any computation is required. The read-only nature is only implied by 'Return.'

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

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

The description is a single sentence with no filler and is front-loaded with the action and object. It conveys the key distinction about the output efficiently.

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 retrieval tool, the description states the core purpose and output nature, but with no output schema or annotations it leaves the exact return shape, model_id semantics, and relationship to fitted models implicit. It is adequate for selection but not fully self-contained for confident invocation.

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

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

Schema description coverage is 0% and the description does not mention model_id or how it selects the model. The parameter name 'Model Id' is somewhat self-explanatory, but the description adds no meaning beyond what the schema already trivially provides.

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

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

The description uses a specific verb and resource: 'Return response/saturation information sampled by PyMC-Marketing rather than raw posterior arrays.' It clearly conveys what the tool computes and adds a distinguishing qualifier about the output. It does not explicitly differentiate from sibling tools such as get_posterior_plots, but the core purpose is unambiguous.

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

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

The phrase 'rather than raw posterior arrays' implies when this tool is appropriate, but it does not name alternatives or state explicit conditions for selecting this tool over siblings. Usage context is present only by implication.

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 of behavioral disclosure. It does add transparency by naming the prerequisite (dataset must be registered) and all the return contents, but it does not explicitly state that inspection is read-only, requires no special permissions, or has no side effects. The verb 'inspect' implies safety but does not fully guarantee it.

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 only two sentences with no filler. It is front-loaded with the primary action and then states the output. Every phrase adds value and none is tautological.

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 a simple single-parameter tool with no output schema, this description is nearly complete: it explains what to pass, when to use the tool, and what will be returned. The only noticeable gap is not specifying the structure or format of the returned fields, but the output schema is absent, so the agent can still make a correct call with the identifier information.

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 0% for dataset_id, so the description must compensate. It explains that the dataset must already be registered, which gives dataset_id the essential context that an ID of an already-registered dataset is expected. It could have elaborated on where to find this ID, but the core need is met.

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 ('inspect'), a specific resource ('a registered dataset'), and a clearly scoped purpose ('before MMM configuration'). It also enumerates the output (candidate targets, channels, controls, frequency, and data issues), which distinguishes it from siblings like register_dataset or validate_dataset.

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 'before MMM configuration' establishes a precise temporal and functional context, telling the agent exactly when this is the right tool. However, it does not explicitly point to alternatives or provide any 'when not to use' guidance, which would cap the score at 5.

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

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

With no annotations provided, the description bears full responsibility for disclosing behavior. It only states that it lists jobs, implying a read-only operation, but does not mention pagination, result ordering, what 'recent' means, or any authentication or rate-limit requirements. The brevity leaves important behavioral details undisclosed.

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

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

The description is a single, concise sentence with no redundant wording. The core purpose is front-loaded and the structure is appropriate for a simple list operation.

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 lack of an output schema and annotations, the description must convey return behavior and parameter semantics. It does neither. The tool is simple, but an agent cannot know what the response looks like or how to filter effectively without additional information.

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 description provides no explanation of the 'limit' or 'status' parameters. The agent gets only type and default values from the schema, with no semantic context (e.g., what limit caps, what status values are valid). This is a critical gap.

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 clearly states the verb 'List' and the resource 'recent asynchronous background jobs' with an explicit scope of 'for the active tenant'. It is unambiguous and distinguishes itself from siblings like get_job_status (single job) and cancel_job (mutation) without consulting schemas.

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

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

No guidance is given on when to use this tool versus alternatives such as get_job_status. The description provides no exclusions, prerequisites, or context for selecting this tool over sibling list-like operations, leaving the agent to infer usage.

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 of behavioral disclosure. It mentions the high-level workflow and a diagnostic prerequisite, but it does not disclose whether the operation mutates the model, what the returned comparison looks like, failure modes, or any rate/performance constraints. This is a significant gap for an unannotated tool.

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

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

The description is two sentences with no filler. The core action is front-loaded, and the prerequisite is placed second. Every sentence earns its place, and the structure is easy to scan.

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 has a nested config schema, no output schema, and no annotations, so the description must compensate for missing return and behavior details. It does not explain what the output comparison contains, what conditions could cause errors, or whether the model is modified. An agent would still have significant uncertainty before invoking 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?

The description does not name or explain parameters like budget, constraints, cell_constraints, or planning_periods. It only paraphrases the constraint concept already visible in the schema. Since schema description coverage is reported as 0%, the description needed to compensate by mapping its workflow to config fields, but it does not.

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

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

The description names a specific action and resource: 'PyMC-Marketing budget optimization' with 'channel or dimension-cell constraints', followed by the comparison of baseline and recommended posterior responses. This is clear enough to distinguish it from siblings like simulate_budget or optimize_flighting, though it does not explicitly name a sibling or state what the tool is not.

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

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

The only usage guidance is the prerequisite 'Requires a diagnosed model.' There is no guidance on when to choose this tool over alternatives such as simulate_budget, optimize_flighting, or get_response_curves, and no exclusions or failure-prevention advice. Usage context is mostly implied rather than stated.

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

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

With no annotations, the description carries the full burden. It discloses the optimization behavior (adstock carryover, constraints, iROAS floors), the approval precondition, and the return values (weekly spend table, posterior response distribution, net-profit estimates). It does not explicitly state whether the operation mutates any state or requires authentication, but for a compute-and-return tool that is a minor 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?

Two dense sentences with zero filler. The main action, constraints, prerequisite, and return values are all packed into clear, front-loaded prose.

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

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

For a complex optimizer with no output schema, the description covers the key inputs, constraints, and outputs, plus the approval prerequisite. It could mention failure modes or parameter bounds, but those are largely captured in the schema.

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

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

Schema description coverage is 0% for the single top-level parameter (config), and the description does not explain how to structure the input or map the mentioned constraints/objectives to specific parameter fields. Some compensation is attempted by naming channel spend constraints and target iROAS floors, but it does not compensate for the undocumented config object.

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 ('Optimize') and a specific resource ('dynamic weekly media flighting schedule'), and details the constraints and objectives. It clearly distinguishes from sibling optimize_budget by focusing on weekly flighting across a planning horizon with adstock carryover.

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 states a prerequisite: the model must be approved or approved_with_caution before optimization. It does not name alternative tools or exclusion conditions, but this clear precondition provides actionable context.

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 behavioral disclosure burden. It only restates the core function and deprecation; it does not mention output shape, side effects, limits, or any assumptions of the BG/NBD prediction.

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

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

The description is a single sentence plus a parenthetical deprecation warning. It is front-loaded with the primary action and contains no filler, making it well-structured and appropriately concise.

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 description plus the nested schema gives enough context for a simple prediction tool: required model_id, optional future_t and top_n_customers, and clear deprecation routing. The absence of an output schema and any behavioral detail prevents it from being 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?

Context signals report 0% schema description coverage, so the description needed to compensate for parameter meaning. It only implies model_id through 'fitted BG/NBD model' and does not clarify future_t or top_n_customers in the description 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?

The description identifies a specific verb and resource: generating per-customer CLV predictions from a fitted BG/NBD model. It also names the preferred sibling tools, distinguishing its purpose from predict_expected_purchases and estimate_customer_lifetime_value.

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 deprecation notice explicitly instructs the agent to prefer predict_expected_purchases or estimate_customer_lifetime_value, providing a clear when-not-to-use signal and alternatives. It does not state the exact conditions under which this deprecated tool should still be called, which keeps it from a 5.

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

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

No annotations are provided, so the description carries the full burden. It clarifies that it works on a fitted BG/NBD model, but does not disclose whether it mutates state, requires specific permissions, what the output format is, or whether predictions are per period or cumulative. The phrase 'from a fitted purchase model' hints at a read-only operation but does not confirm it.

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 clear sentence with no fluff. It front-loads the core purpose. Could include a usage hint, but for its length it's well structured.

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 1 parameter with 0% schema coverage, no output schema, and no annotations, the description is insufficient. It does not explain how 'top_n' and 'future_t' interact, the return format, or any edge cases (e.g., what if model is not fitted). An agent would need more info 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 description coverage is 0%, so the description must compensate. The description adds that the model is BG/NBD and points to 'purchase model', but it does not explain the semantics of 'top_n' (e.g., cutoff threshold) or 'future_t' (period units: days, weeks?). The schema provides basic descriptions like 'Return top N customers' and 'Number of future periods', but the description adds little beyond that.

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

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

The description names a specific verb ('predict'), a resource ('expected future purchase counts per customer'), and mentions the model type (BG/NBD). It distinguishes from sibling tools like 'predict_expected_spend' and 'predict_customer_clv' which predict different quantitiesable. However, it doesn't explicitly contrast with 'predict_expected_spend' or 'predict_probability_alive', which might lead to confusion.

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 for post-fitting prediction, but does not state when to use this tool over siblings such as 'predict_expected_spend' or 'predict_probability_alive'. No exclusions or alternatives are mentioned, so the agent must infer the scope from the tool name.

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?

There are no annotations, so the description carries the burden. The verb 'Predict' implies a read-only inference, and 'from a fitted Gamma-Gamma value model' states the prerequisite. However, it does not disclose behavior such as error handling, side effects, or what happens if the model is not available.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to identifying what the tool does and what it depends on.

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 description is adequate for a simple prediction tool: it states the output and the prerequisite model type. However, with no annotations and no output schema, it does not explain the optional top_n parameter or the expected return shape, leaving some inference burden on the agent.

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

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

The description mentions Gamma-Gamma model context and the spend metric, which indirectly relates to model_id, but it does not mention top_n or parameter names. Given the context signal of 0% schema description coverage, the description should compensate for parameter details but fails to do so.

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

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

The description names a specific verb ('Predict'), a specific resource ('average transaction monetary spend per customer'), and the required model type ('fitted Gamma-Gamma value model'). This clearly distinguishes it from siblings like predict_expected_purchases and estimate_customer_lifetime_value.

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 'from a fitted Gamma-Gamma value model' clearly implies this tool should be used after fitting a value model and not before. It provides clear context, though it does not explicitly name alternatives or when not to use it.

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

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

No annotations are provided, so the description carries the full behavioral burden. It only states an estimation action; it does not disclose whether the operation is read-only, what the response shape is, or whether any model state or requirements matter beyond having a fitted model.

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

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

The description is a single, front-loaded sentence with no filler. It communicates the core action and object efficiently.

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 annotations and no output schema, the description should clarify what the tool returns and how top_n changes the result. It does not explain the return shape or whether it returns one probability, a list of customers, or a scored table, leaving an agent to infer important 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?

The description mentions the fitted model, which maps to model_id, but it does not mention the optional top_n parameter. The input schema already describes both parameters clearly, so the description reaches the schema-covered baseline without adding much meaning beyond it.

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

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

The description names a specific action ('Estimate'), a specific output ('probability of customer retention/alive'), and a source ('fitted purchase or churn model'). This is clear enough to distinguish it from sibling spend/purchase prediction tools, though it does not explicitly name an alternative.

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

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

The phrase 'from a fitted purchase or churn model' implies the tool is used after model fitting and for retention/alive probability questions Echo. However, there is no explicit when-not-to-use guidance or comparison to alternatives such as predict_expected_purchases or get_churn_risk_cohorts.

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 burden. It discloses one behavioral nuance (can return that no single experiment is implied) but remains silent on side effects, data access, or output format. Minimal but not misleading.

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, front-loaded purpose, no redundant filler. Efficient.

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 there is no output schema and no annotations, the description is too sparse: it does not explain what model_id is, what form the recommendations take, or how to interpret the result. An agent could call it but would not know what to expect.

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 0% and the description never mentions model_id, leaving the sole parameter's meaning and usage entirely unexplained.

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 ('recommend') and resource ('evidence-gathering options'), plus a triggering condition ('material uncertainty'). Also discloses the special case of returning no experiment, which differentiates it from prediction and fitting 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?

Gives a clear context for when to use (uncertainty in model/data signals) but does not name alternative tools or state when not to use. No 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns a stable dataset reference, but it does not explain side effects (e.g., whether the dataset is persisted, whether registration overwrites existing references, whether the file is copied or referenced), permission requirements, or validation behavior. This is a significant gap for an operation that likely creates or mutates state.

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, directly worded sentence that front-loads the core action and return value. No filler or redundant phrasing.

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 description is adequate for a simple registration action but leaves gaps: no mention of prerequisites, error handling, or what the stable dataset reference looks like. With no output schema and no annotations, an agent may not know how to confirm success or use the returned reference 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?

The schema only defines 'path' as a string with no description (0% coverage). The description partially compensates by specifying it is a local file path for CSV or Parquet marketing datasets, but it does not provide details such as whether the path must be absolute, whether the file must already exist, or format constraints beyond the file types.

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 ('Register') and resource ('a local CSV or Parquet marketing dataset'), and explicitly mentions the return value ('a stable dataset reference'). This clearly distinguishes it from sibling tools like inspect_dataset or validate_dataset, which perform different actions.

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 the tool: when you need to register a local CSV or Parquet dataset for later reference. However, it does not explicitly mention alternatives, exclusions, or a broader workflow context such as 'use this before fitting models' or 'use inspect_dataset to examine the dataset'.

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?

Since no annotations are provided, the description carries the full burden and does usefully disclose the same-dataset constraint and return payload. However, its method list ('loo, waic, stacking, all') is stale relative to the schema, which splits this into 'criterion' ('loo', 'waic', 'both') and 'weighting' ('stacking', 'bb-pseudo-bma', 'pseudo-bma') and marks 'method' as deprecated — so the description can actively mislead an agent about valid inputs.

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 compact (~60 words) and front-loaded with the primary action, followed by concrete return details and method options. The trailing 'Methods:' list repeats PSIS-LOO/WAIC/stacking already named in the first sentence, a minor redundancy that keeps it from a 5.

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 has a nested four-property config, no output schema, no annotations, and a closely named sibling ('compare_models') yet the description covers only the core action and returns. It does not map the method list onto the actual parameters, does not disambiguate from 'compare_models', and gives no sense of error behavior or how the 'recommended model ID' is determined.

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 top-level 'config' parameter has no description (0% coverage per signals), though the nested ModelComparisonInput properties are individually documented. The description attempts to compensate but introduces a value ('all') that does not exist in the schema ('both' does), conflates criterion and weighting into a single 'Methods' list, and omits the deprecation warning, so it partially undermines parameter clarity.

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 ('Compare multiple fitted MMMs') and names concrete statistical methods (PSIS-LOO, WAIC, Bayesian stacking) plus the outputs (ranked specifications, scores, recommended model ID). However, it does not differentiate from the close sibling 'compare_models', so it cannot reach 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?

A clear prerequisite is given ('All models must be fitted on the same dataset') and the method enumeration helps the agent choose values, implying when the tool is appropriate. But there is no explicit when-not-to-use guidance and no reference to the overlapping sibling 'compare_models', leaving the choice between them ambiguous.

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 must carry the behavioral burden. It mentions posterior response sampling and blocked rejected models, but does not clarify whether the tool is read-only, what model status is required, or what happens on success or failure.

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

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

The description is short and mostly front-loaded, but 'Rejected models are blocked.' is cryptic and adds little without supporting context. It is concise but not fully self-contained.

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 complex nested config schema, no output schema, and zero annotations, this description is insufficient. It does not explain expected return values, input construction, constraints, or how the simulation results are delivered.

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 description adds no meaning to the sole 'config' parameter. The agent receives no help understanding model_id, changes, cell_changes, or planning_periods from the description.

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

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

States it evaluates an exact requested channel or dimension-cell scenario via posterior response sampling, which helps distinguish it from optimization and prediction siblings. However, it omits the word 'budget' and does not explicitly contrast itself with optimize_budget or get_response_curves.

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 guidance on when to use this tool versus alternatives. The description implies use for specific scenario evaluation but provides no exclusions, prerequisites, or comparison to sibling tools like optimize_budget or predict_expected_spend.

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 disclosure burden. It honestly discloses the central trait — the call returns without blocking and work continues in the background — which is genuinely useful beyond the tool name. But it says nothing about what the call returns (e.g., a job ID), how to track job progress, idempotency semantics, or failure behavior, all of which matter for a submission-style 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 tight sentence that front-loads the verb and the defining async trait. There is a slight redundancy between 'asynchronous' and 'without blocking,' but otherwise every word earns its place. It is appropriately sized for a job-submission 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 job-submission tool with no annotations and no output schema, the description omits the two things an agent most needs: what the call returns (a job identifier to reference later) and how it connects to the sibling job tools (get_job_status, cancel_job, list_jobs). The complex config object is also left entirely unexplained at the top level, so an agent must open the schema to learn even the minimal call shape.

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 at the parameter level is 0%: neither top-level parameter ('config', 'idempotency_key') has a description, and the tool description adds no parameter information. Since coverage is low, the description needed to compensate — especially because 'config' is a large opaque nested object and 'idempotency_key' is a non-obvious concept — and it does not.

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

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

The description uses a specific verb ('Submit') with a clear resource ('asynchronous MMM fitting job') and adds a defining behavioral trait (background, non-blocking execution). It implicitly contrasts with the synchronous fit_mmm sibling, but it does not name that sibling explicitly, so the differentiation is present yet implicit rather than fully explicit.

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 async/background phrasing implies the intended use case: long-running fitting jobs the caller does not want to block on. However, there is no explicit when/when-not guidance, no mention that fit_mmm is the synchronous alternative, and no routing to the job-lifecycle siblings (get_job_status, cancel_job, list_jobs) that clearly exist in the sibling set.

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 does disclose that the tool performs a pass/fail validation gate and gives categories of checks, but it doesn't state what happens on failure, whether it writes anything, or what the response looks like.

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

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

Two compact sentences that front-load the purpose and end with the critical workflow constraint. No filler or repetition.

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 or annotations and six parameters, the description is too thin: it omits return format, failure behavior, and how the parameters map to the validation checks. It gives the workflow position, but not enough for an agent to call it confidently.

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 description names none of the six parameters or their roles. The agent must infer that dataset_id, date_column, target_column, and channel_columns are required and how dims/control_columns affect checks; nothing in the description compensates.

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 action ('Run') on MMM-specific checks (data quality, panel-shape, identifiability) and clearly identifies the resource. The closing 'must pass before fitting' links it to the fit_mmm workflow, distinguishing it from fitting and diagnosis 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?

Explicitly says this must pass before fitting, giving a clear temporal usage context. It doesn't name alternatives or exclusions, but the before-fitting gate is enough to route an agent.

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