StayCharted AMT

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

Annotations declare destructiveHint=true, and the description meaningfully scopes that destructiveness: removed rows leave the training data while the uploaded file is kept and nothing else is deleted. This is exactly the kind of clarifying context that goes beyond a bare destructive flag. It does not mention permissions or reversibility, so not a 5.

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

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

Three tight sentences, with the ordered operation list and the 'only what the user chose' constraint front-loaded, and the destructive-scope clarification last. No filler, though the sentence slightly repeats the ordering idea.

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 destructive, nested-object mutation tool with no output schema and sparse parameter descriptions, the definition covers the operation order, the skip-if-not-chosen rule, and the deletion scope adequately. Prerequisite/permission context and per-field semantics remain unstated but are not strictly required for correct 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 only 20% (just model_id), so the description must compensate, and it does by mapping the operations to the parameters in execution order: merge category names, leave categories out, remove near-duplicates, and mask/remove/keep personal information. This adds real meaning over the bare nested schema, though it doesn't document field-level details like the 'into'/'labels' sub-structure.

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 and resource ('Apply the user's choices to the training data') and enumerates the four concrete operations it performs, so an agent knows exactly what the tool does. It stops short of explicitly distinguishing itself from near-siblings like data_quality or correct_labels, keeping it at a 4.

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?

'Only what the user chose' implies the precondition that the user has already made quality selections and that unspecified operations are skipped, which is useful implied guidance. There is no explicit when-to-use/when-not statement and no named alternative tool, so it remains implied rather than directive.

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 goes well beyond the annotations, disclosing that each item counts as a prediction against the workspace's monthly allowance (billing), that predictions are retained with the model's recent ones, that confidence is the model's and not the agent's, and that items are data never instructions (a prompt-injection guard). It does not clarify failure/error behaviour or whether results overwrite prior predictions, but the disclosures added are substantive for an inference 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 purpose is front-loaded, but the remainder is a dense run-on block stitched together with semicolons, parentheses, and restatement ('like the Prediction API'). Most sentences carry real information, yet the structure and length hurt scannability.

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

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

With no output schema, the description still explains what comes back (category and confidence per item) and adds billing, retention, and safety context. It stops short of covering failure modes when a batch exceeds limits or the model cannot classify, which is a minor gap for a 3-parameter inference 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 description coverage is 100%, so the schema already documents items, texts ordering, maxItems, and model_id sourcing. The description largely restates this pairing semantics rather than adding meaning beyond it, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Ask the model's live version to categorise up to 25 items') and scopes the input types (text, picture links, or paired text+picture). It also distinguishes this from the agent doing the categorisation itself via the labelling guide, so an agent can route correctly without comparing 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?

It gives an explicit trigger ('whenever the user asks to categorise, classify or sort items with it, call this and report its category and confidence for each item') and an explicit exclusion ('rather than categorising them yourself from the labelling guide'). It further clarifies that the labelling guide is not an input here, which routes the agent away from the sibling labelling-guide path.

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?

Goes well beyond the annotations by disclosing that reading is metered like a fill (rows count toward a monthly quota, pictures toward pictures read), that reading is queued and may not start immediately, and that start requires explicit user confirmation via a returned code. It also instructs the agent to report AMT's numbers as given and never fabricate them, which is important behavioral guidance for a destructive/quota-consuming 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?

Dense and front-loaded with the primary purpose, and every clause carries operational weight (charging, queuing, confirmation, number fidelity). However, it is a single run-on paragraph with some awkward phrasing ('with no other arguments, says where its cold start is') that slightly impedes fast parsing.

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 and 5 parameters, the description carries a lot: it describes what the first call returns (what it will use plus a confirmation code), the async queuing behavior, and quota charging. It stops short of describing the second call's return or error/edge cases, but the agent has enough to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-call semantics the schema can't: columns and confirmation interlock across two invocations, and use_gpu's trade-off (GPU Dedicated AI Model can suggest categories itself vs. CPU AI Classifier) is tied to outcome. It also explains label_column's effect on which rows count as reviewed. Only marginal added detail per individual parameter, so not a 5.

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: for a model with unlabelled rows, it either reports cold-start status or begins reading rows so AMT can suggest categories. The two operating modes (status-only vs. reading with columns) are explicit. Sibling differentiation is partial — it references create_model's upload link and AMT's process but never names start_fill or suggest_labels 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?

Gives clear conditions for each mode: no other arguments to see cold-start status, columns to begin reading. The two-step confirmation flow (first call returns a code; only call again after explicit user agreement) tells the agent exactly how to proceed. No explicit when-not or named alternative tool, so not 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?

Annotations declare readOnlyHint=false and destructiveHint=true, and the write path ('set which column is the answer') is consistent with a mutation, so no contradiction. However, the description never says what the setting overwrites, whether the model must be retrained afterwards, or that changes are destructive — precisely the context that matters for a destructive tool with full annotation coverage already in hand.

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 read mode is front-loaded, which is good, but the whole definition is one dense, semicolon-chained sentence that packs three modes of behavior together and is hard to parse on first read.

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

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

For a five-parameter, dual-mode tool with no output schema, the description covers both modes but omits what the inspection returns (beyond 'how strongly each relates'), any pagination or size limits, and the side effects of committing column choices. Adequate for orientation, insufficient 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 100%, so the schema already carries enum semantics for test_split and the role of every parameter. The description adds only the pairing rule (category_column with input_columns) and the read-vs-write framing, which the schema substantially duplicates; 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 (columns of the training file) and two distinct verbs — inspecting column/category relationships and setting the answer/input columns. It is identifiable without opening the schema, though it uses no sibling names to differentiate from dataset_summary or sample_rows.

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 implicitly routes usage by argument shape: calling with category_column and input_columns is the configuration path, anything else is the inspection path. There is no explicit when-to-use or when-not-to-use guidance relative to the many sibling tools that also touch columns and data.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description clarifies the exact blast radius: it changes only the label, does not delete the row, does not retrain, and takes effect at the next training run. This resolves the ambiguity created by a bare destructiveHint and adds genuine operational context.

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

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

Three short sentences, zero filler, with the core action and the hard limit front-loaded and the side-effect exclusions following immediately. Every sentence carries distinct 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 small mutation tool with no output schema but with annotations covering its safety profile, the description covers effects, timing, and limits well. It is silent only on return value and any permission requirements, which is a minor gap.

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

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

Schema coverage is 50% (model_id and the nested 'text' field are documented; category and row_index are not). The description adds little about individual parameters other than restating the 50-item cap already encoded as maxItems. Baseline 3 is appropriate since the schema does the bulk of the work.

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

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

States a specific verb+resource (change the category of mislabelled training rows) and bounds the scope (up to 50), so the agent knows exactly what operation this performs. It does not explicitly differentiate itself from near-neighbours like suggest_labels or apply_quality_choices, so it stops short of a 5.

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

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

The phrase 'rows the user agreed are mislabelled' implies the tool is used after a review/agreement step, which is useful implicit context. There is no explicit when-to-use/when-not statement and no named alternative (e.g. suggest_labels), so guidance is only implied.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), and the description adds genuinely useful context beyond them: the model is 'open to assistants from the start' and creation returns a one-time AMT link for the training file that never passes through chat. The one-time nature of the link is important behavioral detail the agent would otherwise not know.

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

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

Three short sentences, purpose front-loaded, and each sentence carries distinct information (what is created, initial sharing state, return artifact plus a security note). 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?

There is no output schema, so describing the returned one-time AMT link is valuable and present. However, for a mutation tool with three parameters at 33% schema coverage, the description omits any parameter explanation, leaving the reads enum and name constraints undocumented anywhere the agent will see them.

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 33% – only the 'description' parameter is documented, while 'name' and the 'reads' enum (text/pictures) are bare. The description compensates for none of this, mentioning no parameter names, formats, or the meaning of the reads choice.

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: 'Create a new model in this workspace.' The agent can distinguish this from list_models (read) or train (train an existing model) without opening a schema, though the description never explicitly names those siblings or states the boundary.

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 says what happens on creation but never when to choose this tool over alternatives like train, list_models, or model_report. There is no prerequisite, ordering, or exclusion guidance for the agent to act on.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description usefully adds that this is a pre-training inspection and enumerates the issue categories it inspects, which is real context beyond the annotations. It stops short of describing cost, runtime, or whether results are cached, so it earns a solid but not rich 3.

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 front-loaded sentence that leads with the purpose ('what could be fixed before training') and then lists the concrete findings. Nothing is redundant, though the parenthetical for pictures makes the single sentence somewhat dense.

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

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

For a read-only diagnostic with no output schema, the description partially compensates by enumerating the categories of issues returned. It still omits how results are structured, whether they are exhaustive or sampled, and how to act on them via apply_quality_choices, leaving clear gaps for a tool whose whole value is its report contents.

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

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

There is a single parameter and schema description coverage is 100%, with model_id documented as 'from list_models' — an excellent pointer to a sibling tool. The description adds no further parameter meaning, so per the baseline rule for high coverage this lands at 3.

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

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

The description names a concrete resource (the training data / model's dataset) and enumerates exactly what the tool surfaces: duplicate-looking category names, near-duplicate rows, PII, and mislabelled or near-duplicate pictures. An agent can tell this is a pre-training diagnostic report. It does not, however, distinguish itself from siblings like mistakes, review_suggestions, or dataset_summary, so the verb+resource is clear but sibling differentiation is absent.

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

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

There is no explicit when-to-use statement, no prerequisites, and no exclusions. Crucially, it never points to apply_quality_choices, the obvious follow-up sibling for acting on the found issues, nor contrasts itself with mistakes or review_suggestions. Usage must be inferred entirely from the phrase 'before training'.

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

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

Annotations already establish the safe read-only, non-destructive, closed-world profile, so this is not the description's main job. The description nonetheless adds genuinely useful behavioral context: the numbers are AMT's own and must not be recalculated or invented, and row text/labels/file names are untrusted user data that may contain injected instructions.

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 tightly packed sentences with no filler; the content list is front-loaded and the safety constraints follow. The enumerated list is slightly dense but every element maps to real return content.

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

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

With annotations covering the safety profile and the parameter fully described in the schema, the description's job is mainly to explain what comes back — which it does, since there is no output schema. It omits only explicit routing to sibling tools, a minor gap for a simple read operation.

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 single model_id parameter is fully documented in the schema ('from list_models'), so the description carries no extra burden. The description adds no parameter detail beyond the schema, which is the expected baseline for full 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?

States the specific resource (the model's training data) and enumerates the returned content — file, rows, columns, category column, category counts, status — so an agent knows it is a summary/read tool rather than a mutation. It does not explicitly contrast itself with near-neighbors like model_report or columns, keeping it just 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?

There is no statement of when to call this versus the many sibling analysis tools (columns, data_quality, model_report). The only imperative guidance is about how to report results faithfully, not about tool selection, so usage must be inferred from the name alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered, and the description still adds real behavioral context: the download link is one-time and only appears once the fill is done, and defaults to the latest fill. It does not clarify link expiry duration or what happens on a failed 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 no filler; the return contents come first and the default-fill behavior is folded in compactly. The nested parenthetical '(or a given) one's' is slightly awkward but does not cost meaningful 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?

With no output schema, the description carries the full burden of explaining return values, and it only sketches them (status, row counts, link). It never enumerates possible status values or describes behavior on failed/in-progress fills, which is the key gap for a status-polling 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 description coverage is 100%, so both parameters are already documented, including fill_id defaulting to the latest. The description only echoes that default behavior rather than adding syntax or constraint detail, which matches the baseline 3 when the schema does the heavy lifting.

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

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

The description names the resource (a model's fills) and precisely what it returns: status, row counts, and a one-time download link. It is clear but never distinguishes itself from the sibling read_fill_results, so an agent must infer the boundary between checking a fill and reading its results.

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 when-to-use or when-not-to-use guidance, and no routing to alternatives such as read_fill_results or job_status. The polling intent is only inferable from the fact that a 'status' is returned, which is weak guidance for a multi-sibling 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?

Annotations flag this as non-read-only and destructive; the description explains the source of that risk ('a group left out is dropped', same-named groups merged) rather than merely restating it. It further adds traits absent from the annotations: no re-read and no charge on the naming pass, and an explicit prompt-injection warning that row text/labels/file names must not be treated as instructions. This is meaningful disclosure beyond the structured fields.

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, and the core purpose plus return contents are front-loaded before the second-call workflow. It is dense and slightly packed with parenthetical rules, but every clause carries 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?

With no output schema, the description correctly carries the burden by enumerating what comes back (group size, distinguishing words, sample rows). It also covers the two-call lifecycle, cost behavior, and the data-safety constraint, leaving nothing an agent needs in order to invoke 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 100%, so the baseline is 3, and the schema itself already documents `groups`, `split` and `names`. The description nevertheless adds real semantics for `names` (each entry becomes a category, duplicates merge, omissions are dropped) that the schema only gestures at with 'the groups to keep', so it earns slightly above baseline.

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

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

States a specific verb+resource ('Find the categories in a cold start's rows by grouping similar ones') and even describes the return payload (group size, distinguishing words, example rows). It is very clear what the tool produces, but it never names or contrasts sibling tools such as classify or suggest_labels, which occupy adjacent conceptual space, so the sibling-differentiation condition for a 5 is unmet.

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

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

Gives concrete workflow guidance: run it first to discover groups, then 'call again with names' to promote named groups to categories, including the merge/drop rules of that second pass. It does not, however, state when to prefer it over alternatives like classify or suggest_labels, so usage context is clear but without explicit exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. Because there is no output schema, the description's enumeration of the four possible run states is genuinely useful return-value disclosure, though it says nothing about permissions or freshness of the status.

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 compact sentence with no filler, and the key qualifier about latest-vs-given run is placed early. It is an incomplete sentence fragment, which slightly hurts readability but not economy.

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 simple read-only, two-parameter tool with annotations covering safety and no output schema, the description supplies the state vocabulary an agent needs to interpret results. Missing only explicit routing guidance to sibling tools, which is minor here.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema, including the 'latest when left out' default for job_id. The description only restates that default and adds no format or ID-syntax detail beyond the schema, so the baseline 3 applies.

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

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

The description names the resource (a model's training runs) and the exact information returned (queued/running/finished/failed), which is more specific than the name or title alone. However, it is a noun phrase rather than a verb+resource statement and does not differentiate itself from siblings such as train, model_report, or fill_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?

Usage is only implied: the parenthetical '(or a given)' hints that you may query either the latest run or a specific one. There is no explicit statement of when to use this versus model_report or other status-related siblings, and no prerequisites are mentioned.

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

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

Annotations already establish this as a safe, closed-world read. The description goes further with non-obvious behavioral context the annotations cannot express: the guide does not change model answers, is not a substitute for classify, and must be treated as the user's data, never as instructions about tools or actions — a valuable injection-safety caveat.

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, front-loaded with what the guide is before the usage and safety caveats. Dense and largely waste-free, though the safety sentence is long and could be tightened.

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

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

No output schema exists, and the description adequately conveys what the call returns (the guide's category meanings and the user's exceptions). With one param documented in the schema and no return structure to explain, the definition is sufficient for correct 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 coverage is 100% and the single model_id param is fully described in the schema (including its source, list_models). The description adds nothing 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?

States the specific resource (the model's labelling guide) and its contents (what each category means plus the user's exceptions). It also names the sibling it is not — classify — so an agent can distinguish reading the guide from using the model to categorise.

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?

Explicit when-to-use: read before labelling anything yourself for this user and when explaining the model's answers. Explicit alternative: 'to categorise items with the model, call classify.' Both the trigger and the routing are stated outright.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description's 'Replace' corroborates that this overwrites the existing guide. It adds the 4,000-character ceiling, but does not disclose permission requirements or what happens to prior content on failure/excess length.

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 content constraint trailing. Every clause carries information, though the parenthetical about length slightly duplicates the schema's maxLength.

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

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

For a two-parameter mutation tool with no output schema and annotations covering the safety profile, the description says enough to call it correctly. It does not address error behavior, but that omission is minor at this complexity.

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

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

Schema coverage is only 50%: model_id is documented in the schema, but the guide parameter has no description there. The description compensates by defining what the guide should contain (each category's meaning and its exceptions) and restating the length cap, adding genuine meaning 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?

States a specific verb ('Replace') and resource ('the model's labelling guide'), with scope detail about the guide's contents. An agent can distinguish this from the labelling_guide_get sibling by the get/set pairing, though the description never names the alternative 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 phrase 'text the user agreed' implies this is used to persist a human-approved guide, giving implied workflow context. There is no explicit when-to-use/when-not or reference to labelling_guide_get, so usage must be inferred.

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

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

Annotations already declare readOnly, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new context: the list is filtered by Builder switch-on, the workspace chosen at connect time, and the caller's role, and it enumerates returned attributes (kind, status, latest accuracy).

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 with the resource and its authority claim, with no filler. Slightly clause-heavy in the first sentence, but every clause carries scope 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?

With no output schema, the description carries the return-value burden and does so at a summary level (kind, status, latest accuracy), plus the scoping rules that determine membership. Adequate for a zero-param read tool; finer field detail would be the only improvement.

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 description correctly implies no filtering arguments exist by framing the list as fully determined by connection context.

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 being listed and its scope ('the models AI assistants may use'), and adds a strong boundary statement ('This list is authoritative; no other model can be reached'). It does not explicitly distinguish itself from the sibling model_report, so it stops short of a 5.

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

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

Usage is implied rather than stated: the 'authoritative' claim tells the agent this is the source of truth for reachable models, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. model_report for per-model detail).

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

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

Annotations already establish the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds real value beyond them by enumerating the return fields and warning that returned row text, labels, and file names are untrusted user data that must not be treated as instructions. That injection warning is exactly the kind of behavioral context annotations cannot convey.

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

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

Two sentences, no filler: the payload description comes first and the safety caveat second. The first sentence is dense but every clause maps to a returned field.

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

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

With no output schema, the description correctly carries the return-shape burden by listing the per-example fields, and the schema covers the lone parameter. Only minor gaps remain, such as result size/ordering for what could be a large error set.

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 single model_id parameter is documented as coming from list_models, so the baseline is 3. The description adds no parameter detail and in fact says 'the latest trained version,' which slightly underspecifies that the model is caller-selected via 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 concretely states what the tool returns: the misclassified examples from the latest model's held-out test, itemized as text, category, predicted value, and row index. That is specific enough to separate it from metric-oriented siblings like model_report. It stops short of framing itself as a retrieval call or explicitly naming sibling 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?

Usage is only implied: the mention of 'the row index to correct' hints at a follow-up correction workflow (e.g. correct_labels), but there is no explicit when-to-use or when-not-to-use guidance, nor any named alternative such as model_report for aggregate metrics. Adequate but minimal.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds genuine context beyond that: the numbers come from held-out data, they are AMT's own authoritative values, and the agent must echo them verbatim rather than derive or guess them. That output-authority constraint is real behavioral guidance.

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 with what the report contains and followed by the reporting constraint. Every clause carries information; the enumeration is a little packed 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?

With no output schema, the description correctly compensates by enumerating the report's fields, and a single fully documented read-only parameter needs no elaboration. Only the format or units of the numbers is left unspecified, a minor gap.

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

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

There is a single parameter with 100% schema description coverage (model_id, sourced from list_models), so the schema already carries the meaning. The description adds nothing about the parameter, which is the expected baseline when schema coverage is complete.

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 resource and scope: the latest trained version's score on held-out examples, and enumerates the exact contents (accuracy, always-guess baseline, per-category accuracy, live status). This clearly separates it from siblings like list_models, mistakes, or data_quality without the agent needing to open any schema.

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

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

The use case is strongly implied (fetch a model's evaluation report) and the description adds an operational directive for the returned numbers, but it never states when to pick this over alternatives or any prerequisites. Usage is inferable rather than explicit, so a 3 is warranted.

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

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

Annotations already flag this as non-read-only and destructive, but the description adds substantial extra behavior: the first invocation is a no-op, the code is single-use, scoped to this model and these arguments, and expires in 10 minutes. That is real operational context beyond the annotations; it does not, however, say what happens to the previously live version or whether the change is reversible.

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?

Four tightly packed sentences, front-loaded with the effect and immediately followed by the two-step constraint that governs correct invocation. No filler; every clause carries a rule the caller must obey.

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

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

With no output schema, the description still tells the agent what the first call returns (the pending changes and a confirmation code). Combined with annotations covering the destructive profile and the description covering the expiry/scope rules, nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 67% and the undocumented parameter is `confirmation`, whose semantics (exact code, single use, model-and-argument scoped, 10-minute expiry) are fully explained in the description. The description thus compensates for the schema gap rather than merely restating job_id/model_id, which the schema already covers.

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 (make live) and resource (a trained version) plus the concrete downstream consumers (fills, classify, Prediction API), which pins down what publishing actually affects. An agent can distinguish it from train, job_status and list_models without reading any schema.

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

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

Explicitly prescribes the two-call workflow: first call is a dry run that returns the diff plus a confirmation code, and the second call happens only after the user explicitly agrees. It also gives a negative rule ("The user's yes is not the code"), which is exactly the kind of when-not guidance that prevents misfires.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description goes further by disclosing pagination limits, the provenance guarantee that all numbers are AMT's own, and a prompt-injection warning about row text, labels, and file names. That is meaningful behavioral context beyond the annotations.

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

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

Three tight sentences with the core purpose front-loaded, followed by provenance and safety guidance. Nothing is redundant, though the injection warning is somewhat generic boilerplate for a read 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?

With no output schema, the description correctly carries the burden of describing the return payload (row text, category, confidence, page size). It is nearly complete for a read tool, missing only an explicit note on whether offset paging is the intended iteration pattern versus a cursor.

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%: fill_id and model_id are described in the schema, but limit and offset are not. The description partially compensates by describing page-based reading capped at 200 rows, which conveys the semantics of those two undocumented parameters, but it never names or maps them explicitly.

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

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

States a specific verb (Read) and resource (rows of a finished fill) and names exactly what is returned (category and confidence AMT gave each row). It implicitly separates itself from fill_status by qualifying the fill as 'finished', but it never explicitly contrasts itself with siblings like sample_rows or fill_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?

The description implies the precondition that the fill must be finished and explains the paging model ('a page at a time, up to 200 rows'), which is real usage context. However, it never states when to reach for this tool versus fill_status, sample_rows, or model_report, and no alternatives are named.

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

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

Annotations only declare write/non-destructive/non-open-world, so the description carries the real burden and delivers: the first call changes nothing, answered items affect the next retrain, the code is single-use, scoped to this model and these answers, and expires in 10 minutes. These are exactly the behaviors an agent must respect and are not derivable from the annotations.

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

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

Purpose is front-loaded, then the two-step flow and code constraints follow in tight order. Every sentence earns its place — the confirmation-code warnings are load-bearing and nothing is repeated from the schema.

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

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

With no output schema, the description compensates by explaining what the first call returns (the pending record plus a confirmation code). It is largely complete for a mutation tool, though it omits edge cases like partial-batch failures and the 50-item cap.

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 67%, and the description adds genuine meaning beyond it: the confirmation parameter's one-time, 10-minute, answer-scoped semantics, and the relationship between category and the skip/unsure action. It does not explain the model_id source or answer-array limits, but the schema's own field descriptions cover those.

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 — 'Record the user's answers to waiting items' — and enumerates the answer kinds (category, skip, unsure). An agent can distinguish it from siblings like review_queue (which surfaces items) and review_retrain without reading either schema.

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

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

Gives explicit procedural guidance: first call is a no-op preview returning what will be recorded plus a code, and the second call must use that exact code after user agreement, with the pointed warning 'The user's yes is not the code.' It does not, however, name sibling alternatives for inspecting items or suggest answers, so alternative-selection guidance is only implied.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds real context beyond that: it spells out the exact destructive actions (exclude from training data, relabel, dismiss) and reassures that the uploaded pictures themselves are kept, clarifying the true blast radius of the operation. That is meaningful behavioral disclosure on top of the annotations.

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

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

The content is front-loaded by naming findings first, then fixes, which is good ordering. But it is a single dense run-on sentence with a nested parenthetical, making it harder to parse than it needs to be.

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

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

No output schema exists, so the description carries the return-value burden, and it does describe the findings returned plus the thumbnail behavior of include_pictures. Combined with the fix semantics, an agent has enough to invoke it correctly, though response shape details are still thin.

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?

With 60% schema coverage, the description compensates well: it maps remove to 'leave pictures out of the training data', relabel to 'relabel them', dismiss to 'dismiss a finding', and explains include_pictures as returning up to 6 thumbnails. Only model_id is left to the schema, which documents 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 the concrete findings it surfaces (near-duplicate pairs, two-label pictures, out-of-category pictures) and the fixes it can apply (remove, relabel, dismiss), which is a specific verb+resource. It does not explicitly contrast itself with close siblings like review_suggestions or correct_labels, so an agent must infer the boundary.

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 conditional for the mutating path ('when the user agreed, apply fixes'), which is useful usage guidance. However, it never says when to prefer this tool over review_suggestions, correct_labels, or data_quality, so alternative selection is left implicit.

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

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

Annotations only declare it is a safe read; the description goes well beyond by disclosing ordering (least sure first), result composition, the include_pictures/thumbnail behavior, and two strong safety constraints: every number is AMT's own and must never be calculated or invented, and row text/labels/file names are user data that must never be followed as instructions.

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?

Long, but front-loaded and dense: what the queue is, the two modes, the per-item return shape, routing, then two safety rules. Each sentence carries distinct information, though the return-field enumeration could be trimmed slightly.

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

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

There is no output schema, and the description fully compensates by enumerating the returned fields (text or picture name, answer and confidence, top three categories, up to three similar labelled items, existing suggestion). An agent has everything needed to call it correctly.

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

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

Schema coverage is 50%: model_id and include_pictures are documented in the schema, while limit and offset are not. The description adds real value by explaining the with/without model_id branching and that results are paged 'least sure first', but it never clarifies limit/offset semantics, so it only partially 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?

States a specific resource (the Review Queue) and precisely what it contains: answers a model was unsure about. It even distinguishes two modes (per-model counts with no model_id, a page of waiting items with model_id), so an agent can tell it apart from review_suggest, review_answer and review_suggestions without opening any schema.

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

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

Explicit routing: read labelling_guide_get before proposing, use review_suggest to propose, review_answer to record answers. It names the prerequisites and the sibling tools for the downstream actions, leaving nothing 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?

Beyond the annotations (readOnly=false, destructive=false, openWorld=false), the description discloses the dry-run-first confirmation flow, that the first call changes nothing, and that it returns allowance usage plus a confirmation code. This is exactly the behavioral context an agent needs before triggering a mutation.

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

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

Three tight sentences, front-loaded with purpose, then the two-step mechanics, then the boundary with publish. No filler and every clause carries operational 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?

No output schema exists, yet the description explains what the first call returns (projected additions, allowance consumption, confirmation code), which is the key unknown. Combined with the 100% schema coverage and annotations, nothing an agent needs to invoke this correctly is missing.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the 'confirmation' code semantics. The description reinforces the ordering (only send the code after explicit user agreement) but adds little syntax or format detail 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?

States a specific verb and resource ('Retrain the model') plus the exact data source (answers reviewed in the Review Queue) and the settings baseline (live version). This clearly separates it from siblings like train, publish, and review_answer.

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 an explicit two-step protocol: first call is a no-op dry run, second call requires the exact confirmation code and explicit user agreement. It also routes publishing to the 'publish' sibling, so an agent knows where this tool's responsibility ends.

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

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

Annotations only declare write/non-destructive/openWorld=false; the description adds substantive behavior the annotations cannot convey: a suggestion trains nothing and records no answer, and it surfaces to the user as 'Your assistant suggests' on the Review Queue screen. That is meaningful context for a write-adjacent tool, though it doesn't cover error handling or what happens to prior suggestions.

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 action and its scope, then explains behavior and the alternative in short clauses. Slightly dense with embedded workflow detail but no filler sentences; every clause contributes.

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 write tool with no output schema, the description covers what is written, the constraint on category values, the downstream effect, and the routing to review_answer and the labelling guide. Adequate for correct invocation, with only minor gaps around failure modes and the suggestions array limits.

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% and the nested item fields carry no descriptions, so the description compensates by defining category ('suggested category', limited to existing model categories), reason ('one-line reason'), and item_id implicitly (waiting items from review_queue). It adds real meaning beyond the bare schema, missing only detail on model_id and the 50-item limit.

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 (record a suggested category) and resource (waiting items from review_queue), and explicitly distinguishes itself from the recording-of-answers action performed by review_answer. An agent can tell it apart from review_answer and suggest_labels without opening a schema.

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

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

Explains the workflow: the user answers on AMT's Review Queue screen, or agrees here and the agent records with review_answer. It also constrains usage ('Only the model's existing categories can be suggested') and points to the labelling guide. It stops short of an explicit when-not-to-use exclusion, but the alternative is named with its selecting condition.

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

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

Annotations only say readOnlyHint=false and destructiveHint=true; the description goes well beyond by disclosing that answers are persisted, that unreview retracts an answer, that only reviewed rows train, and that use_reviewed overwrites the model's training data. It also flags that confidence numbers are AMT's own and must not be recalculated, and warns about instructions embedded in row text/labels.

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

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

The core read-and-record action is front-loaded, and the remaining sentences cover workflow consequences and two safety constraints. It is dense rather than padded, though the number-handling and injection warnings add length that a shorter phrasing could partly absorb.

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 destructive mutation with no output schema, the description supplies the workflow context, mutation consequences, and trust boundaries an agent needs. It leaves the filter enum values and offset behavior to the schema and says nothing about the result payload, which keeps it short of 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?

With only 38% schema description coverage across 8 parameters, the description carries real weight: it explains that limit is capped at 100 with least-sure rows first, and defines the semantics of answers (confirm or change), accept_above (accept at or above a confidence), and unreview (take an answer back). filter modes and offset are still only inferable from the schema, so it does not fully close 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 gives a precise verb+resource: it reads a cold start's rows together with AMT's suggested category and confidence, and records the user's answers. It also situates the tool in the workflow (only reviewed rows train; use_reviewed then train), which separates it from siblings like train and use_reviewed.

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 operating modes clearly (confirm/change rows via answers, bulk-accept via accept_above, undo via unreview) and explains the downstream condition for use_reviewed/train. It does not explicitly contrast with nearby siblings such as correct_labels or suggest_labels, so the routing guidance is strong but not exhaustive.

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

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint false, openWorldHint false), so the bar is lower. The description still adds real value: it discloses the 100-row ceiling and, notably, warns that row text, labels and file names are user data and must not be treated as instructions - an injection caveat annotations cannot express.

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, both earning their place: the first front-loads the purpose and scope, the second is a critical safety note. The first sentence is clause-dense, which costs a little readability, but there is no filler.

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

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

For a read-only, four-parameter tool with no output schema and sparse parameter docs, the description covers the essential shape: pagination, the 100-row cap, per-row content, and the category filter. Ordering and total-count behavior are left implicit, but neither is essential for correct 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 only 25% (only model_id is documented), so the description must compensate. It does partially: 'up to 100' pins the limit ceiling and 'optionally only one category's' explains the category filter's semantics. However, offset/pagination semantics remain unstated, leaving one parameter undocumented in both places.

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: reads a page of a model's training rows, with page cap, per-row contents (index, category) and an optional category filter. This is clear and concrete, though it does not explicitly distinguish itself from siblings that also expose training data such as columns, group_rows or dataset_summary.

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 says what comes back but never says when to reach for this tool versus alternatives like group_rows, mistakes or columns. The only usage hint is the incidental 'optionally only one category's', which signals a filtering use case but gives no conditions, prerequisites, or exclusions.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the mutation profile is already known. The description adds real context beyond that: it returns a one-time AMT link, the user performs the upload/fill out-of-band, and 'the file never passes through the chat' discloses a privacy/data-flow trait. It does not mention auth or rate limits, but the human-in-the-loop handoff is valuable behavioral 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?

Three sentences, front-loaded with the core action, then the handoff mechanics and the privacy note. No filler, though the middle sentence packs several sub-steps into one clause.

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

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

With no output schema, the description carries return-value burden and does so by explaining the one-time AMT link result. For a single-parameter initiation tool this is nearly complete; only explicit routing to the follow-up siblings (fill_status, read_fill_results) is missing.

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

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

Only one parameter (model_id) with 100% schema description coverage, so the schema already documents it fully ('The model id, from list_models'). The description's phrase 'the model's categories' adds slight contextual meaning but no syntax beyond the schema, matching the baseline 3.

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

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

States a specific verb+resource: 'Fill a spreadsheet with the model's categories.' An agent can tell this initiates a filling operation, though it doesn't explicitly contrast itself with siblings like fill_status or read_fill_results.

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 conveys the workflow context (a one-time AMT link, the user uploads and starts the fill themselves), which implies this is an initiation step. However, it never names alternatives such as fill_status or read_fill_results to route the agent among the fill-related 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?

Despite annotations only declaring destructive/not-read-only, the description adds substantial behavioral context: CPU mode reads nothing again and charges nothing, GPU mode is a fresh charged read on every call, and GPU runs as a two-step flow with a confirmation code like train. Cost and confirmation semantics are exactly what the agent 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?

The critical CPU-vs-GPU distinction is front-loaded and no sentence is wasted, though the prose is dense and run-on, requiring close reading. Slightly more structure would improve 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 output schema and a mutating, cost-bearing tool, the description covers cost, confirmation flow, mode selection, and a reporting directive ('never calculate, estimate or invent one'). It omits what happens to the suggestions afterward (e.g., review/accept via review_suggestions), a minor gap.

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

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

Schema coverage is 50%, and the description compensates well: use_gpu is tied to Business eligibility, charging, and row re-reads; categories are explained as becoming the model's categories; confirmation is tied to the two-step flow. model_id gains little beyond the schema hint, but overall meaning is well extended.

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 with scope: 'Suggest a category for every unreviewed row of a cold start.' It is clearly distinguishable from siblings like start_fill, train, and classify, and it explains the two operating modes without ambiguity.

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 conditional guidance on the two modes (categories supplied vs. not) and spells out when use_gpu applies (Business plan, re-reads rows, charged). It does not explicitly route the agent away from siblings such as start_fill or train, so it falls short of 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?

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=false. The description adds substantial context those annotations cannot convey: the first call is a no-op preview returning allowance usage plus a code, the code is single-use, scoped to this model and these arguments, and expires in 10 minutes. That is exactly the behavioral detail an agent needs before a costly write.

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?

Four short sentences, front-loaded with the two-step shape, and every sentence carries operational weight (preview, user confirmation, code-is-not-consent, code lifetime). No filler.

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

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

With no output schema, the description carries the return-value burden and does describe the first call's response (allowance usage plus confirmation code). It does not say what the second call returns or how to track training progress (e.g., via job_status), which leaves a modest gap for a mutating 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 100%, so the baseline is 3, but the description adds real meaning about the confirmation parameter beyond the schema: it is single-use, valid for 10 minutes, and bound to this model and these arguments. The model_id/model_type semantics are left entirely to the schema's already-detailed enum text.

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

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

States a specific verb and resource ('Train a new version of the model') and immediately frames it as a two-step operation, so the agent knows what the tool does. It does not, however, distinguish itself from sibling tools like create_model or review_retrain, so the agent must infer which of several model-related tools is appropriate.

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 explicit procedural guidance: call once to preview, show the user, and only call again after explicit agreement with the exact code, including the sharp caveat that 'the user's yes is not the code.' It lacks any comparison to alternative tools (create_model, publish, cold_start), but the when/when-not protocol for this tool is unusually clear.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral value beyond that: the numbers are authoritative and must be reported verbatim, not recalculated or estimated, which directly governs how the agent should handle the output.

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 with what the tool returns followed by a short handling directive. Neither sentence is redundant and the schema is empty, so there is no 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 zero-parameter, read-only tool with no output schema, the description does the necessary work of enumerating the returned field categories and stating how to treat them. It stops short of describing units, reset timing, or error behavior, but nothing essential for calling it is missing.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing parameter-related for the description to clarify.

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 resource (this workspace's allowances for the current billing period) and enumerates exactly what it returns: training runs, predictions, pictures, and remaining amounts. No sibling tool covers billing/allowance data, so it is naturally distinguishable, though no explicit verb (get/retrieve) is used.

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

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

Usage is only implied: an agent infers it should call this when it needs allowance or quota figures for the workspace. There is no explicit when-to-use statement, no when-not-to-use condition, and no named alternative among the many siblings.

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