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

With no annotations, the description carries the full burden, and it does disclose two meaningful traits: provenance is retained and row-level validation errors are preserved rather than aborting the import. It says nothing about whether files are written to disk (the 'out' param hints at it), overwrite behavior, idempotency, 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?

A single front-loaded sentence with no filler; every clause adds information (source types, provenance, error retention). It is efficient, though the terseness borders on under-specification for a tool with eight parameters.

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 an 8-parameter tool with a nested object, zero schema coverage, no annotations, and no output schema, the description leaves too much unknown: what 'mapping' and 'quality' control, what 'out' does, and how validation errors are surfaced to the caller. The complexity clearly outstrips the description.

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% across 8 parameters, including a nested 'mapping' object and ambiguous fields like 'quality', 'source', and 'date'. Only 'file' and 'source_type' are inferable from the prose/enum; the remaining six parameters are undefined anywhere, and the description does not 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?

Specific verb ('Normalize') plus a concrete resource class (local ads/email/website/CRM/survey CSV/JSON exports) makes the operation distinguishable from generic import tools. However, it never addresses the obvious overlap with the sibling tool 'ads_import', leaving ambiguity about which one handles ads data.

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 enumerated source types imply the domain of use, but there is no explicit when-to-use, no exclusion, and no pointer to alternatives. With a sibling named 'ads_import' sitting in the same list, the absence of routing guidance is a real gap.

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 full burden; it does disclose that the tool writes two artifacts (seed .md and benchmarks JSON) and accepts CSV or JSON input. It does not say whether it overwrites existing files, what happens to malformed exports, or what errors look like — meaningful gaps for a file-writing 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 front-loaded sentence with no filler that names input, input formats, and both outputs. It is perhaps too terse given the tool's file-writing side effects, but nothing in it is wasted.

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 covers the essential input formats and the two produced artifacts, which is the minimum an agent needs to invoke it. It omits overwrite behavior, expected export schema, and failure modes, leaving gaps for a mutation-style 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 50%: `out` is documented in the schema, but `file` has no schema description, and the description compensates by explaining it is a Meta/Google Ads export in CSV or JSON with an absolute path. That is real added meaning, but the format/validation expectations (e.g., required columns) remain unspecified.

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 (turn/convert) and both the input resource (Meta/Google Ads export) and outputs (seed Markdown + benchmarks JSON), so the agent knows exactly what the tool produces. It doesn't contrast with the nearby actuals_import sibling, which is the main thing a reader would want clarified.

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

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

There is no statement of when to use this versus alternatives such as actuals_import or campaign_plan, nor any prerequisites or exclusions. The agent must infer the usage context purely 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?

With no annotations, the description carries the full burden but does not say whether this is a read-only computation or whether it persists results, nor whether it requires a completed run or imported actuals to exist. It discloses only the output dimensions (correlation, winner match, calibration) and nothing about side effects, errors, or cost.

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

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

A single dense sentence with the action front-loaded and the metric list appended; no filler. It stops short of five only because the compactness comes at the cost of the missing prerequisite and parameter detail.

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 3-parameter, annotation-free tool with no output schema, the description does useful work by naming the returned metrics. But it omits the purpose of 'map', the prerequisite that ads_import/actuals_import must have run, and whether a run must be finished — gaps an agent would need to resolve by trial.

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% across 3 parameters. The description implicitly covers 'run' and 'actuals' (real ad results from ads_import) but says nothing at all about the 'map' parameter, which is entirely undocumented in both schema and prose. Partial compensation is not enough at this coverage level.

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 ('Score') and resource ('a run's feed test against real ad results'), and enumerates the metrics produced (rank correlation, winner match, calibration), so the agent knows exactly what the tool computes. It does not explicitly distinguish itself from the sibling holdout_backtest, which is a similar scoring tool, leaving that differentiation to the agent.

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 parenthetical '(from ads_import)' hints at the prerequisite source for actuals, which implies a call ordering. However, there is no explicit statement of when to use this versus holdout_backtest, and no exclusions or preconditions beyond that hint.

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 does real work: it discloses the side effect that calibration.json is written into the run folder, and names the verdict categories (trust / correct / walk-away) and the AIPW correction. It omits failure behavior (missing run, malformed CSV) and permission/overwrite semantics.

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

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

One dense, front-loaded sentence that leads with the core verb and ends with the write side effect. The long parenthetical on CSV format is justified, though the sentence is heavy to parse.

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

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

No annotations and no output schema, so the description carries full load; it covers the deliverable file and headline metrics but leaves three parameters and error conditions undefined. Adequate to start, not complete for a 5-parameter 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% and three of five parameters (by, map, field) are never mentioned, so an agent cannot know what they control or their formats. Only real_csv is explained in useful detail (columns, label encoding, row count) and 'run' is implied by 'run folder'.

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

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

States a specific verb and resource: 'Check a run's simulated survey against real answers', and enumerates the concrete outputs (covariate overlap, per-audience calibration, verdict, AIPW-corrected rate). This clearly separates it from siblings like results or actuals_import.

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

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

Implies the tool is used after a run exists and that you supply an external ground-truth CSV, and even gives sizing guidance ('50-300 rows is enough'). But it never says when to prefer this over siblings such as results, backtest, or actuals_import, nor any prerequisites.

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

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

With no annotations, the description carries the full burden. It does disclose one important trait — no campaign is actually sent — but omits whether the saved plan persists where, whether it overwrites, permission needs, or what is returned. For a write-style tool with nine parameters, the disclosure is thin 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 tight sentences with the purpose front-loaded and the safety disclaimer second. Nothing is wasted, though the compactness comes at the cost of the parameter detail a tool this complex needs.

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

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

A nine-parameter tool with nested objects, no annotations, and no output schema needs substantially more description. Key elements — budget shape, profile vs profile_file vs project precedence, channels, out, and return behavior — are all unexplained.

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% across nine parameters, including nested objects (budget, profile, research) and required goal/budget. The description only loosely gestures at profile, profile_file, project, and research via 'from a profile or existing project'; it does not explain the structure of budget, channels, out, or the file-vs-object alternatives.

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 ('Save an evidence-led campaign plan and runnable test specs') and identifies the input modes ('from a profile or existing project'). It is clear enough to distinguish from siblings like research or pitch, though the term 'evidence-led' is loosely defined.

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 campaign is sent' usefully scopes what this tool does not do, and 'from a profile or existing project' hints at two entry paths. However, it never states when to choose campaign_plan over siblings such as pitch, research, or study, leaving selection to inference.

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

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

With no annotations, the description carries the full burden, yet it only discloses that execution happens asynchronously as a background job. It says nothing about whether arbitrary commands can mutate or delete data, what permissions or environment are used, how failures surface, or that results must be retrieved via job_status/results.

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

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

Two compact sentences, with the 'Advanced' qualifier and the verb front-loaded before the example. The trailing pointer to CLAUDE.md is a cheap external reference an agent cannot read at call time, but it costs little space.

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

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

For a catch-all command executor with no annotations, no output schema and an undocumented single parameter, the description is thin: it omits the return value (job handle), how to poll progress, timeout/rate-limit behavior, and any safety constraints on what commands are permitted.

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, and it partly does: the example shows args is an ordered argv list where element 0 is the subcommand and the rest are flags/values. It still gives no escaping, quoting, or shell-vs-direct-execution semantics.

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

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

States a specific verb and resource: run any MarketMirror CLI command as a background job, with a concrete example argv array. It is clearly distinguishable as a generic escape hatch rather than a targeted operation, though it never names which siblings it supersedes.

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 'Advanced:' prefix implies this is a fallback when no dedicated tool fits, but that is inference, not guidance. There is no statement of when to prefer run_test, backtest, survey-workflow tools, or similar over raw CLI invocation, and no prerequisites or warnings about misuse.

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 exist, so the description carries the full burden; "Check" implies a non-mutating probe and the parenthetical "(never shown)" usefully discloses that the API key is redacted from output. However, it never states whether the tool has side effects, whether it can repair what it finds, or what form the report takes, which are exactly the gaps annotations would normally fill.

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 a compact enumeration of the four checks; no filler. Slightly clipped to the point of ambiguity, but every clause earns its place.

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

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

For a zero-parameter, no-output-schema diagnostic tool, the agent still needs to know whether this is a safe read-only probe and how to act on the results, neither of which is covered. Adequate to identify the tool, insufficient to complete the troubleshooting loop.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing parameter-level for the description to clarify or omit.

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

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

The description gives a specific verb ("Check") and enumerates the exact subsystems inspected: engine install, Python deps, API key, backend status. That is far more informative than the bare name "doctor", though it never distinguishes itself from look-alike siblings such as setup, provider_setup, or start_backend.

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 implies a diagnostic/troubleshooting role but never states when to run it (e.g., before start_backend, after install, when a run fails) or when to prefer setup/quickstart instead. No exclusions or alternatives are named, so the agent must infer the workflow placement.

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

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

With no annotations, the description carries the full burden and does well: it explains the attention-gate simulation model, that an LLM decides skim/read/click/reply/unsubscribe/spam 'with honest odds', the async background-job nature, and exactly what metrics are returned. It omits cost/rate-limit implications but covers behavior far beyond a bare verb.

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

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

The purpose is front-loaded, but the body is a single dense run-on packed with inline field lists, making it hard to scan. The information is useful, but structure (separating inputs from outputs) would let the same content earn its place better.

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 nested objects, no output schema, and zero schema description coverage, the description supplies both input shape and expected return metrics plus the background-job note. Remaining gaps are the undocumented `run` parameter and no pointer to job_status for retrieving results.

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, and it largely does: the emails array is enumerated field-by-field including the send_time enum values and nested sequence structure, plus benchmarks keys and list_size. The exception is the `run` parameter, which is never explained anywhere.

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+resource: an email campaign test run against simulated people's inboxes, with a defined outcome (open/click/unsubscribe/spam rates). This clearly separates it from siblings like website_test or market_test without needing to name them, though it never explicitly names those alternatives.

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 the key prerequisite ('Needs a prepared simulation (simulation_id)') and that the operation is a background job, which implies polling job_status. However, it never says when to pick this over run_test/market_test or what to do if no simulation exists, leaving usage largely implied.

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

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

No annotations are provided, so the description carries the full behavioral-disclosure burden. It does not state whether the operation is read-only, what permissions are needed, whether it has side effects, or what the response contains.

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

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

The description is a single front-loaded sentence with no wasted words. It efficiently communicates the evaluation target and baseline.

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 two parameters, no annotations, no output schema, and 0% schema description coverage, the one-sentence description is too sparse. It leaves the input format, output behavior, and operational context undocumented.

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 the required 'pairs' parameter or the optional 'out' parameter. Neither parameter's meaning, format, or expected structure is explained anywhere.

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 ('Evaluate') and resource ('independent held-out real experiments') plus a comparison baseline. It is clear what the tool does, but it does not explicitly distinguish itself from the sibling 'backtest' tool.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as 'backtest' or 'run_test'. The phrase 'held-out' implies a usage context, but no when/when-not conditions or prerequisites are 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 does real work: it discloses side effects (writes ideas.json/.md into the run folder and appends a 'Test ideas' section to the dashboard) and the shape of the return (prioritised experiments each citing evidence plus a simulation config). It omits permission/auth needs, what happens when no run folder exists, and whether writes are additive or overwrite.

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 input contract is front-loaded before the outputs and persistence behavior, and both sentences carry real information with no filler. The opening clause is long and comma-heavy, which slightly slows parsing but no sentence is wasted.

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 six-parameter tool with zero schema coverage, no annotations, and no output schema, the description covers the data inputs, the run context, and the returned artifacts adequately. It still leaves three parameters undefined and gives no guidance on defaults or failure modes, which is a meaningful gap given the empty 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 coverage is 0%, so the description must compensate for six bare parameters. It does well for rows (enumerating name, campaign, spend, impressions, clicks, conversions, country), ads_file (export file path), and run (prior run's objections, audiences, decision), but n, brand, and brief receive no explanation at all, leaving half the surface undocumented.

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 (generate next test ideas) on a specific resource (real ad data / a previous run) and names what comes out (prioritised experiments with evidence plus a MarketMirror config to simulate). It implicitly separates itself from market_test/run_test by positioning ideas as the pre-simulation step, though the verb phrasing 'Next test ideas' is slightly awkward.

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 it applies ('pass ad rows you fetched... and/or an export file path, plus a previous run'), which tells the agent the expected preconditions. It never states when NOT to use it or names an explicit alternative sibling, so the agent must infer the boundary with market_test, research, or campaign_plan.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that log tail and final result are returned, but says nothing about polling behavior, error handling for unknown jobs, permissions, or whether the call blocks or returns partial data.

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

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

A single front-loaded sentence with zero waste. It is appropriately sized for a simple one-parameter status 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 tool is simple, and the description usefully names the return components despite there being no output schema. However, it leaves the required job_id undocumented and omits usage context, so it meets only the minimum viable bar.

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 the required job_id parameter. The parameter name is self-explanatory, but no format, source, or usage details are added beyond the bare 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 names the specific resource (a background job) and the specific data returned: status, log tail, and final result. That is clearer than a generic status tool, though it does not explicitly differentiate itself from siblings such as results or list_runs.

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

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

There is no guidance on when to use this tool, when to poll versus use results/list_runs, or what prerequisites exist. The single vague context is that it applies to background jobs, 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?

With no annotations, the description carries the full burden but says nothing about read-only behaviour, ordering, result limits, pagination, or what a 'decision' looks like. Only the verb 'list' faintly implies a non-mutating read.

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, but it is terse to the point of under-specification rather than true conciseness. Nothing is wasted, yet little is conveyed.

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

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

No output schema, no annotations, and no parameter docs, so the description is the only source of information about the return value and it does not describe it. An agent cannot know the result shape, ordering, or what 'decision' means before calling.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The one missed opportunity is stating that no filtering is possible, which would matter given the unbounded 'previous runs' scope.

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 verb (list) and resource (runs) plus an extra field it returns (decision), which is more informative than the title alone. But 'runs' is undefined in a sibling set that also contains run_test, backtest, results and job_status, so an agent cannot confidently tell what a 'run' is or which tool surfaces them.

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

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

No indication of when to call this instead of results, job_status or backtest, which are the obvious neighbours. The agent is left to guess whether this is a history view, a status poll, or a results summary.

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

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

With no annotations, the description carries the full burden and does disclose the approval gate, persona-creation pause, simulation reuse, and background execution. It omits spend/cost implications, permissions, idempotency, error behavior, and how results are retrieved.

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

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

The purpose and approval workflow are front-loaded, and most content is necessary given the empty config schema. However, the long run-on config key list is dense and hard to scan, reducing practical clarity.

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 asynchronous job with no annotations, no output schema, and an empty config schema, the description provides useful config semantics and the approval sequence. It still omits required/default config keys, result retrieval via job_status/results, and error or cost 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 schema has 0% description coverage and exposes only an undifferentiated config object, so the description's enumeration of keys and their meanings compensates substantially. Some nested structures are only loosely described, but the key semantics are much richer than the schema alone.

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

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

The opening phrase 'All-in-one market test' plus the config-key list makes clear that this tool runs persona generation, feed creative testing, surveys, panels, and reporting. However, it does not explicitly distinguish itself from siblings such as run_test, website_test, or email_test.

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

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

It gives a concrete two-step approval flow: call without approve_spend to stop after persona creation, then call again with simulation_id and approve_spend true. It also notes that the work runs as a background job. It lacks guidance on when to choose this over sibling test tools.

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 still discloses meaningful traits: it is a background (async) job, it mutates state by scoring the pitch and assigning lead scores to every person, and it requires a live environment. It does not explain how to retrieve the async result (job_status/results) or what happens if the simulation is not alive.

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

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

Front-loaded with 'Sales rehearsal' and the core action, and every clause adds information (precondition, rebuttal format, scoring outputs). The rebuttal-format parenthetical mid-sentence makes it slightly run-on, but there is little waste.

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

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

For a 7-parameter mutation with no output schema and no annotations, the description covers the workflow and rebuttal shape but leaves the async retrieval path and four parameters unexplained. An agent knows what the tool does and roughly when, but not how to fully parameterize or collect its result.

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% across 7 parameters, so the description must carry the load. It documents rebuttals well ({objection_type: text, '*': generic}) and implies script and simulation_id, but run, channel, product, and segment get no explanation at all — over half the parameters remain opaque.

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

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

States a specific verb and resource: pitch a script to every simulated buyer of a simulation, collect objections, answer with rebuttals, and score the pitch plus each person. The full pipeline (pitch → objections → rebuttals → scoring) is unambiguous and distinct from siblings like market_test, which only sets up the simulation.

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 concrete precondition: the environment must be alive, so either run market_test with rounds first or start it. That tells the agent when the tool is callable. It doesn't name alternatives for other scenarios (e.g. email_test or website_test for non-pitch rehearsals), so it stops short of full routing guidance.

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

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

With no annotations, the description carries the behavioral burden and does disclose meaningful traits: predictions include intervals, are scaled by real-vs-simulated results, and are labelled with their calibration basis. It also explains that targets yield a probability of success and that an adoption forecast is produced, though it does not explicitly state read-only behavior 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 two dense sentences that front-load the main prediction purpose and then add output details. It is information-rich with little waste, though the semicolon-heavy structure could be easier 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?

For a complex tool with no output schema and no annotations, the description explains the kinds of predictions and their calibration labels reasonably well. It remains incomplete for the input parameters days, brand, and spend, and does not describe the return shape beyond naming metrics.

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 for five parameters. It clarifies run and targets, including a targets example, but does not explain days, brand, or spend, leaving most parameters without semantic meaning.

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

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

The description names a specific verb, predict, and enumerates the resources/metrics covered: CTR per ad, cost per lead, conversion, email click rates, and adoption forecast. It is clear what the tool does, though it does not explicitly differentiate itself from siblings such as results or study.

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 implies the tool should be used after backtest and calibrate by referencing their stored results as inputs, and it notes optional targets for probability of success. However, it gives no explicit when-to-use guidance versus siblings and 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?

With no annotations, the description carries the full burden and does add real value: it warns never to paste an API key into arguments and states that local settings are inspected in masked form, plus that some providers return login commands instead of keys. What it omits is whether 'configure' mutates persistent settings, whether changes are reversible, and what 'check' actually verifies — a meaningful gap for a mutation-capable 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?

One dense sentence enumerating the four capabilities followed by a short, well-placed safety rule and a caveat about login commands. Every clause carries information and the security warning is front-loaded rather than buried, though the first sentence is long enough that the action-to-capability mapping takes a second pass to parse.

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

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

No output schema and no annotations, with 5 parameters at 20% coverage, means the description has to do a lot; it covers purpose and safety well but leaves the semantics of the required 'action' values underspecified. An agent knows broadly what the tool is for and the key security rule, but could still pick the wrong action (status vs check) or omit provider/model when configuring.

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 only 20%, so the description must compensate, and it only partly does: it implies key_env takes a variable name (reinforced by the 'existing key environment variable' phrasing and the no-paste warning) and gestures at model/base_url via 'configure a local model'. It never maps provider to the list/configure actions, and the distinction between the 'status' and 'check' actions is completely undefined, leaving the required action enum under-specified.

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?

Uses specific verbs over a clearly bounded resource set: list provider choices/guides, inspect masked settings, configure a local model or key env var, and discover models. An agent can tell this is a provider/credential configuration tool, not a test runner like run_test or doctor. It does not name any sibling tool to distinguish overlapping areas (setup, cli, doctor), which keeps it below 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?

The four described modes imply when to call it (listing providers, checking local settings, configuring, discovering models) and the closing note tells the agent that ChatGPT/CLI login choices yield local login commands rather than credentials. However, there is no explicit when-not guidance and no comparison against near-neighbors like setup, doctor, or cli, so the agent must infer routing.

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

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

With no annotations, the description carries the full burden. It usefully discloses that updates flow into every persona card from the next round on, that each update is one or two sentences, and that the runner re-reads the file every round. However, it omits whether updates append or overwrite, permission/auth needs, error conditions, and what the tool returns.

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 main action and effect are front-loaded, and the examples earn their place by making the expected input concrete. It is slightly run-on and includes a somewhat promotional closing sentence, but overall it is appropriately sized.

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 four-parameter mutation tool with no annotations, no output schema, and zero schema description coverage, the description gives useful runtime context but leaves significant gaps. An agent understands the intent and timing, but not fully how to populate or interpret all parameters, nor what to expect 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?

Schema description coverage is 0%, so the description must explain all four parameters. It implicitly describes 'text' as a one- or two-sentence update and gestures at 'round' via 'from the next round on', but it never explains 'simulation_id' or 'source' and gives no format expectations for optional fields.

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

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

The description states a specific action: pushing real-world context into persona cards from the next simulation round onward. It clearly distinguishes the tool's role from broad simulation siblings like start_live or results, though it does not explicitly name alternatives.

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

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

It gives clear timing guidance ('while a simulation is running (or before it starts)') and a concrete purpose ('ground the rounds in live reality'), with examples of acceptable inputs. It does not explicitly state when not to use it or name alternative tools.

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 to lean on, the description still discloses key behavior: it runs as a background job requiring job_status polling, and it deliberately stops before paid rounds (cost boundary). It also notes the result names files to edit and the next command. It omits whether it writes to disk, whether re-running overwrites an existing folder, and permission/auth needs.

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

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

Front-loaded with the benefit ('Easiest start'), then the deliverables, then the key list, then the background-job caveat — a sensible order. The middle key enumeration is dense and comma-chained but each item carries call-relevant information; nothing is padding.

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

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

For a 4-parameter tool with a nested object and no output schema, the description covers what is produced, how completion is detected (poll job_status), and what the result contains. Missing pieces are the semantics of `url` and `no_run` and any statement of runtime or failure behavior, but the core calling information is present.

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

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

Schema coverage is only 25% and the required `answers` parameter is an opaque nested object, but the description compensates well by enumerating its expected keys (brand, product with what/for-whom/price, buyers, platforms, tests, budget format like '300 USD', size enum, past_ads absolute path, docs). That is meaningfully more than the schema offers. The top-level `url` and `no_run` parameters remain 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 concretely what the tool produces — a scenario folder with brief, personas, two template captions per platform, messages, launch calendar, pitch, plus simulated people — and marks the boundary 'stops before any paid rounds', which separates it from paid-test siblings like market_test or run_test. It never names or contrasts against the nearest onboarding siblings (setup, understand, start_live), so differentiation is implicit rather than 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?

'Easiest start' and 'stops before any paid rounds' imply this is the first-run entry point, and 'the exact next command' hints at a guided flow. However, no alternative tool is named and no condition for choosing this over setup, understand, or campaign_plan is given, so the agent must infer the routing.

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

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

With no annotations, the description carries the burden well: it discloses keyless public sources, Reddit access limitations, fallback behavior, and that the tool writes research.md, research.json, and voices.json under a scenario path. It does not cover overwrite behavior or error handling beyond Reddit blocking.

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 dense but front-loads the purpose, then sources, outputs, and usage. The single long sentence with many parentheticals is somewhat run-on, but most content earns its place.

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

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

It provides useful context for a complex tool with no annotations or output schema by naming sources, output files, and sequencing. However, it leaves key parameter meanings unexplained, which is a significant gap given 6 parameters and 0% schema description coverage.

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 partially maps query, country, and urls, but does not explain the out, sources, or subreddits parameters, leaving half the parameters undocumented.

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 resource: public sentiment from Hacker News, App Store reviews, Reddit search, and page URLs, and names the output files. It is more specific than the tool name alone but does not explicitly distinguish itself from similar research-oriented siblings such as understand or study.

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

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

It gives a clear sequencing rule ('Run it before planning personas') and a practical fallback for Reddit blocking: use browser tools and add findings as seed files. It lacks explicit when-not-to-use guidance or comparisons to sibling tools.

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

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

With no annotations, the description carries the full behavioral burden; it does add real value by enumerating the returned artifacts (decision, verdicts, objections, pricing, ROI projections, files), which is the only return-value documentation since no output schema exists. It says nothing about read-only nature, error behavior for an unfinished or missing run, or size/cost of the payload.

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. The tail is a dense comma list of return fields, which is efficient though slightly catalogue-like.

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

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

Because there is no output schema, the enumerated field list is genuinely necessary and is the description's main contribution. However, for a retrieval tool with no annotations, it omits prerequisites, failure modes, and whether results are partial for an in-progress run.

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

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

Schema description coverage is 100% and the schema already explains that 'run' is a run name under mirofish_runs or an absolute path. The description adds no additional meaning about the parameter, so the baseline 3 applies.

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

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

The description names the resource (results of a run) and enumerates what is inside it, but the verb is only implicit and there is no differentiation from siblings such as list_runs, job_status, or run_test. An agent can guess it retrieves a run's outcome, but must infer that from a noun phrase rather than a stated action.

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

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

There is no statement of when to call this versus list_runs or job_status, and no prerequisites such as whether the run must be finished first. The only implicit guidance is the 'run' parameter 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?

No annotations are provided, so the description carries the burden. It usefully discloses the return shape and winner/lift/tie semantics, and mentions 'Background job', but does not explain async handling, retrieval via job_status/results, permissions, or side effects.

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

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

Front-loads the core action and packs necessary enum-like detail into a single dense but purposeful statement. The semicolon-heavy run-on structure is slightly harder to scan, but no sentence is wasted.

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 nested-spec background job with no annotations or output schema, the description covers the result shape well. It still omits how to obtain or poll results, where simulation_id comes from, and how this differs from sibling test/job tools.

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 many spec fields (type, variants, audience, metric, budget, rounds), but leaves simulation_id, run, and brand largely undocumented.

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 clear verb and resource: testing variants from a spec on a prepared simulation. The long type enumeration clarifies scope, but it does not distinguish this tool from siblings like website_test, email_test, market_test, or pitch.

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

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

Implies usage through 'prepared simulation' and type values, but gives no explicit when-to-use/when-not guidance or alternatives. The overlap with sibling test tools is left unresolved.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that execution is a background job, that completion requires polling job_status, and that git and uv must be present. It does not discuss permissions, failure modes, or whether an update is destructive to existing 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?

Two compact sentences that front-load the action and mechanism, then immediately give the async polling behavior and prerequisites. Every clause earns its place.

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

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

For a zero-parameter, no-output-schema tool, the description covers the key operational facts: what it installs, the mechanism, that it is asynchronous, how to track completion, and prerequisites. Missing only edge-case behavior such as failure reporting or upgrade 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?

The tool has zero parameters, so there are no parameter semantics to explain; the baseline for 0 params is 4. The description appropriately adds no parameter detail because none exists.

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 (install/update) and resource (MarketMirror engine), with a parenthetical on the mechanism (git clone + uv sync). It is distinguishable from provider_setup and quickstart, though it does not explicitly name those siblings as alternatives.

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?

Clarifies when the tool applies (install or update) and gives the follow-up behavior: it is a background job, so poll job_status. Prerequisites (git and uv) are stated as a condition for use, but no explicit when-not guidance is 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, the description carries the full burden: it usefully discloses the bound port and a hard prerequisite, but says nothing about whether the call blocks on a long-running server, how it behaves if the backend is already running, or how success is signalled. Those are the traits an agent most needs before invoking a server-start 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?

Two short sentences with zero filler, the identity of the action front-loaded and the prerequisite following immediately. Every clause adds information an agent needs.

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

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

For a zero-parameter tool with no output schema the description covers purpose and prerequisite adequately, but omits what the agent should do after starting (e.g. doctor, market_test) and whether the call returns immediately or holds the session. Those gaps matter for a backend-lifecycle 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?

The tool takes no parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies; the port mention is scope rather than parameter documentation.

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

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

States a specific verb and resource ("Start the MarketMirror backend") and pins the concrete detail of port 5001, so an agent knows exactly which process is launched. It does not explicitly differentiate itself from siblings like start_live, provider_setup, or quickstart, which keeps it short of a 5.

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

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

Gives a clear precondition: one of four provider configurations must exist first (API-key, ChatGPT sign-in, local CLI gateway, local-model provider), which tells the agent the correct ordering of calls. It offers no exclusions or explicit routing to siblings, so it stops at clear context rather than full when/when-not guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the dashboard URL and run selection, but not whether the server blocks, runs in the background, persists after the call, requires an available port, or how to stop 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 front-loaded sentence with no wasted words. The URL and run-selection behavior are both communicated compactly.

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 with no output schema this covers the basic purpose, but it omits important operational behavior for launching a live server. An agent knows what it does and the main parameter semantics, but not the full invocation context.

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

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

The single optional "run" parameter is given meaning: omit it for the newest run, or provide it for a specific run. However, the description does not specify run identifier format or examples, and schema coverage is 0%.

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

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

States a specific verb and resource: "Serve the live dashboard" with an explicit URL and optional run targeting. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as start_backend or list_runs.

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

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

The description implies usage by saying it serves the newest run or a given run, which helps an agent decide whether to pass the optional parameter. However, it does not state when to use this tool versus alternatives or mention prerequisites such as whether a backend must already be running.

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

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

With no annotations, the description carries the full burden and does disclose key behavior: it writes three named artifacts under mirofish_runs/<name>/, details the contents of study_summary.json, reuses finished cells on rerun, and executes as a background job. It omits cost/runtime expectations and how to retrieve results once the job completes.

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?

Content is front-loaded and nearly every clause adds information, but it is delivered as one dense run-on with an inline schema sketch, making it hard to scan. Some structuring (separate sentences for what it does, the spec shape, and what it writes) would cost nothing.

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 nested spec object at 0% schema coverage, the description is thorough about spec internals, output artifacts, and rerun behavior. It still leaves an agent without guidance on the 'out' parameter or on how a finished background job is collected.

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, and it does: every key of the required nested spec (name, base, simulation_id, scenarios/overrides, seeds, steps) is enumerated and given meaning, with base explicitly typed as a market_test config. The optional 'out' parameter is never mentioned, which is the one real 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?

States a specific verb/resource: a study runner that crosses several scenarios with several seeds over the same simulated people and yields 'one defended conclusion.' It distinguishes itself from the single-run sibling by defining base as 'a market_test config object,' but it never explicitly contrasts with market_test, run_test, or predict.

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?

'Background job' implies polling via job_status and 'Finished cells are reused on rerun' implies resumability, so usage is inferable. However, there is no explicit when-to-use-this-vs-market_test guidance, no statement of prerequisites, and no exclusion of 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?

No annotations exist, so the description carries the full load — and it discloses real behavioral traits: synchronous execution, a single Claude call, a file side effect (writes product_profile.json), and a dependent side effect (seeds the market map before the graph build). It omits overwrite/error behavior and what happens when no inputs are supplied.

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

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

The purpose is front-loaded in the first clause and the dense parenthetical enumerating profile fields is informative rather than filler. The closing sentence bundles three unrelated facts (output file, project mode, market-map seeding), which slightly hurts scanability.

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, no output schema, and six undocumented parameters, the description is the only source of truth. It covers input modes, the output artifact, and key side effects well, but the two unexplained parameters and the absent failure/overwrite semantics leave a gap.

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

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

Schema coverage is 0%, so the description must compensate. It explains `docs` (absolute .md/.txt paths), `url` (landing page), `ads_file` (ads export) and `project` (existing project), but never mentions `out` or `name`, leaving two of six parameters undocumented anywhere.

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 ('read ... into one product profile') and enumerates exactly what the profile contains, so the agent knows what the tool produces. 'Step one for any product' positions it relative to the later-step siblings, though it never names which sibling to use next.

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 the entry condition ('step one for any product') and an explicit alternative invocation mode ('pass `project` instead of docs to profile an existing project'). It doesn't warn about when not to use it, e.g. when a project has already been profiled, or how it differs from `research` or `quickstart`.

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

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

With no annotations, the description carries the full burden and discloses important behavior: actions and screenshots are observed, only supplied DOM checks verify goals, cart changes require cart/checkout goals, signup requires explicit test data and opt-in, and no payments/orders occur. It omits permissions, result retrieval, and side-effect details beyond those constraints.

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 core action first and constraints following. It is dense but earns most of its sentences; a slightly clearer structure around background polling and results retrieval would help.

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 complex nested-schema tool with no annotations and no output schema. The description covers key safety constraints and background polling, but it does not explain the nested spec parameters, the meaning of simulation_id, or how to retrieve results beyond polling job_status.

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 effectively 0% for most parameters, and the description explains only a few concepts: checks, cart/checkout goals, test data/opt-in, and job polling. It leaves major parameters such as simulation_id, spec.url, goal, task, device, max_steps, observation_mode, and resource limits 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?

The description states a specific verb and resource: 'Run prepared synthetic visitors on a real website URL.' It clearly conveys a browser-based synthetic-user test, though it does not explicitly differentiate itself from siblings like email_test, market_test, or run_test.

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

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

It gives useful operational context: this is a background job and you should poll job_status. It also specifies gating conditions for cart changes and signup submission. However, it does not say when to choose this tool over email_test, market_test, or run_test.

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