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

Annotations already cover the safety profile (readOnly=false, destructive=false, openWorld=false), yet the description adds substantial behavioral context: the session state machine, which states return 400 and why, what 409 means, and that a CONSUMED session returns the existing version. The only friction is that this retry-safety statement reads as idempotent behavior while the annotation sets idempotentHint=false; the annotation is best read as a conservative default here, and the description mutes rather than contradicts the mutation semantics.

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

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

Front-loaded with the core action and then organized by parameter, then by state requirements, then by error handling — dense but every paragraph carries operational information. It is long, and the closing paragraph on qa_status/version_type is only loosely tied to this tool's own behavior, so slight trimming was possible.

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 mutation tool that ends an upload session, the description covers prerequisites, retry behavior, failure modes, and routing alternatives; the output schema exists so return values need no further explanation, and the brief mention of what is returned is harmless. 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 description coverage is 0%, so the description must carry all parameter meaning, and it does for the important ones: upload_request_id (opaque id from start_upload), dataset_id (omit to create new, pass existing to add a version, name then required but ignored), and dataset_type (train/test/validation with default and semantics). It leaves project_id and description unexplained, so it compensates strongly but not completely.

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

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

Names a specific verb and resource ('Register a validated upload as a dataset') and situates it in the workflow ('the last step of every channel'), which cleanly separates it from start_upload and get_upload_status. An agent can tell exactly what state transition this performs without consulting the schema.

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

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

Gives explicit prerequisites (session must be READY, not UPLOADED, and instructs calling get_upload_status first rather than guessing), explicit exclusions (a file uploaded via the web model builder should be resolved with list_datasets instead), and retry/409 escalation guidance. This is a full when/when-not/alternative treatment against named 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?

Annotations declare destructiveHint=true, idempotentHint=false, readOnlyHint=false, and the description adds real value beyond them: client-side refusal of malformed file_url forms, an API 400 when the path is outside users/{userId}/, the fact that qa_status is purely informational, and the training-job constraint on raw versions.

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

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

Front-loaded with the two bolded mode headers and organized by required fields per branch, so the agent can parse it quickly. The s3Key cross-referencing (complete_upload / get_dataset_version) is somewhat dense but each sentence carries operational 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?

For a 7-param mutation tool with an output schema, everything an agent needs to invoke correctly is present: mode selection, required fields, input format constraints, failure conditions, and downstream effects on training. Return values are legitimately omitted given the output schema.

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

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

Schema coverage is 0%, so the description must carry the load, and it documents five of seven parameters including enum values (version_type raw|qa_cleaned|training, qa_status pending|in_progress|ready|blocked) and the two accepted file_url formats. Only project_id and dataset_id scoping are left undescribed, which is a minor gap.

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

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

States a specific verb+resource and cleanly splits the two modes (create registering an S3 file as a version vs update changing qa_status). It names related siblings (complete_upload, get_dataset_version, submit_training_job) so an agent can place it in the workflow without opening 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?

Gives explicit conditions for choosing each mode (required field sets differ) and a concrete routing rule for submit_training_job with dataset_version_id. It stops short of distinguishing this tool from the sibling update_dataset, so the branch selection is clear but the sibling boundary 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 already declare destructiveHint=true and idempotentHint=false, but the description adds the *reason* ('each call without model_id creates another model') and the underlying mechanism (PATCH on update). That is useful context beyond the annotations, though it says nothing about permissions or the effect of an update on unmentioned 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?

Front-loaded with the key distinction (create-or-update, not idempotent) followed by two tight bullets. Every sentence carries actionable information with no filler.

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

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

An output schema exists, so return-value detail is not required, and the description fully covers the create/update dichotomy, the non-idempotency trap, and which fields matter. An agent has everything needed 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 0%, so the description must compensate, and it largely does: it explains that project_id+name drive creation, that model_id switches the call to update mode, and that description is optional. It does not clarify what happens to unspecified fields on PATCH, leaving a small gap.

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

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

States a specific verb+resource ('Create or update a model') and explicitly delineates two operating modes (create vs update/rename). This distinguishes it from siblings like create_model_version and get_model without opening their 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?

Gives explicit conditions: call with project_id and name to create, add model_id to update/rename. It even warns that repeated calls without model_id create duplicates. It does not name an alternative sibling (e.g., get_model to inspect first), so it falls just short of a full when/when-not treatment.

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 write/non-destructive/non-idempotent, so the safety profile is covered. The description adds real behavioral context beyond that: EasyDeploy does not validate dataset-type, so misuse silently breaks the holdout, and time_series_mode switches the downstream cross-validation to TimeSeriesSplit. It stops short of saying whether duplicate/creation calls fail or what the created version's state is.

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

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

Front-loaded with the action and next step, then the critical pitfall, then the optional time-series behavior. Well organized and mostly earned, though the final sentence about get_model_report recording the strategy is somewhat tangential for a create 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?

Output schema exists so return values need not be explained. For a write tool operating in a multi-step workflow, the description supplies the sequencing, the data-hygiene caveat, and the semantics of the non-obvious parameters – nothing an agent needs to call it 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 0%, so the description carries the full burden. It explains dataset_version_id (must be the train split), target_feature (the target column), and both time_series_mode and time_column with their semantics and default behavior. model_id and project_id are left implicit, which is the only gap.

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

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

States a specific verb+resource ('Create a model version') and immediately scopes it ('tied to a dataset version and target column'), distinguishing it from siblings create_model, create_dataset_version and get_model_version. An agent knows exactly what object is produced.

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 routes to the next step ('Then call submit_training_job with the returned model version id'), states a hard prerequisite (pass the train version, never the test one, and why a leaked holdout is harmful), and gives the condition for time_series_mode ('when forecasting ordered periods'). This is when-to-use, when-not, and alternatives in one place.

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 idempotentHint=false and destructiveHint=true, but the description goes further by naming the practical consequence of non-idempotency (duplicate projects on repeated calls) and the PATCH/merge semantics of the update path. It does not explain the destructive side of destructiveHint=true, e.g. whether omitted fields are cleared or values overwritten, which is the remaining gap.

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

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

Front-loaded headline sentence followed by two tightly scoped bullets, one per mode. No filler, and the key non-idempotency warning is placed in the leading line where it will be 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?

An output schema exists, so return values need not be described. With only three simple parameters and annotations covering the safety profile, the description supplies everything an agent needs to pick the correct mode and call it: branch condition, mutability, and the duplicate-creation hazard.

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

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

Schema description coverage is 0%, so the burden falls on the description, and it delivers: it explains that project_id is the branch selector for update mode and that name/description are the mutable fields. It does not clarify the empty-string default for project_id/description in the schema, which would be the last missing piece.

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

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

The description states a specific verb+resource (create/update a project) and immediately resolves the ambiguity of a dual-mode tool by spelling out the two branches. Siblings are list_projects/get_project, so no other tool competes for this purpose; an agent can tell exactly what this does without opening the schema.

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

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

It gives explicit, mutually exclusive conditions: omit project_id to create, pass project_id plus fields to update/rename. That is a complete when-to-use rule for both branches, with the consequence of getting it wrong stated ('each call without project_id creates another project').

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 the full safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds the useful behavioral fact that the backend resolves the account from the API key when customer_id is empty, but stops short of explaining caching, freshness, or auth requirements. With annotations covering safety, a 3 is appropriate.

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

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

Two tight sentences: the first enumerates what the status returns, the second clarifies the optional parameter. Nothing is wasted and the key scoping information is front-loaded.

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

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

An output schema exists, so return values need not be explained. For a single-optional-param read tool with full annotation coverage, the description covers what the agent needs. It could more explicitly route against sibling status tools, but it is otherwise complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does so effectively by explaining that customer_id is optional and that the backend falls back to the API-key-resolved account — meaning the empty default is a valid, meaningful value rather than a missing field. This is genuinely more than the bare schema conveys.

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 ('Get current account status') and enumerates exactly what the status contains (tier, credits, usage, limits). This distinguishes it from sibling status tools like get_upload_status and get_training_status, which return different resources.

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 note that customer_id is optional and resolves from the API key gives implicit usage context, but the description never states when to call this tool vs alternatives like get_model_report or get_started. Guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, and the description's 'Read-only' is largely redundant with them. However, the lifecycle context (datasets originate from complete_upload, mutations live in update_dataset) is genuine behavioral context not present in 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?

Two short sentences, front-loaded with the core action and return fields; the routing note follows immediately. 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?

An output schema exists, so return values need no elaboration, and the alternative-tool guidance is complete. The only shortfall is the absent parameter guidance for the two required ids.

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

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

Schema description coverage is 0% and the description only says 'by id', never mentioning that project_id is also required alongside dataset_id, nor any format expectations. With two required undocumented parameters, the description fails to compensate for the schema gap.

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

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

States a specific verb+resource ('Fetch one dataset by id') and enumerates the fields returned (name, description, type, timestamps), which cleanly separates it from list_datasets and get_dataset_version.

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 routes the agent: datasets are created via complete_upload, and renaming/description changes go to update_dataset. It tells the agent not just when to use this tool but which sibling to use instead for adjacent operations.

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/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond them: qa_status is informational and gates nothing, and a raw version is rejected by submit_training_job, which tells the agent how the returned version_type constrains downstream calls.

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 in the first clause, then gives return fields and a short caveat paragraph. Every sentence carries information, though the second paragraph drifts toward submit_training_job's behavior rather than this tool's.

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

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

With an output schema present and annotations covering the read-only profile, the description does not need to enumerate return values or safety behavior. What remains missing is any hint about id formats or failure modes when a version does not exist.

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

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

Schema description coverage is 0% and none of the three required parameters (project_id, dataset_id, version_id) are explained in the description. It only implies that version_id identifies a dataset version; the id formats and the project/dataset/version hierarchy an agent must supply are left entirely to inference.

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

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

States a specific verb and resource ('Fetch one dataset version by id') and enumerates what the response contains (counts, columnNames, qa_status, version_type). The singular 'one ... by id' implicitly contrasts with list_dataset_versions, but no sibling is named explicitly.

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

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

It explains how to interpret two returned fields and notes that version_type only matters when calling submit_training_job with an explicit dataset_version_id, which is useful routing context. However, it never states when to call this tool rather than list_dataset_versions or get_dataset, so the when-to-use 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds nothing behavioral beyond that, and its parenthetical about returned fields duplicates what the output schema already carries.

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

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

A single, front-loaded sentence with zero filler; the lookup key and the returned shape are stated immediately.

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

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

An output schema exists so return values need not be restated, and annotations cover the safety profile, making the short description nearly sufficient for a simple getter. However, with 0% parameter coverage and no usage context, it leaves visible gaps for a two-required-parameter tool.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, but it only gestures at 'id' and never disambiguates model_id from project_id, both required. An agent gets no help on which identifier to supply.

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

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

States a specific verb (Fetch) and resource (model) with the scope qualifier 'single ... by id', which separates it from the list_models sibling. It does not explicitly distinguish itself from get_model_version, keeping it short of a 5.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as get_model_version or list_models. The usage is only inferable from the name and required ids.

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 read-only/idempotent, but the description adds substantial non-obvious behavior: a 45s default wait (capped at 60s), the timed_out:true + next_steps contract on timeout, the null metricsUnavailableReason path, and an instruction to read warnings before quoting numbers. This is exactly the context annotations cannot carry.

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

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

Front-loaded and dense with no filler, and the operational rules come first. The extended paragraph on CV strategy and training-fit caveats is relevant for interpreting numbers but is long relative to the calling decision, slightly diluting an otherwise tight definition.

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

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

Despite an output schema existing, the description still specifies the metrics object shape, the strategySource enum values, and the null case, and it resolves the 'accuracy is training fit, not holdout' ambiguity that would otherwise cause misuse. Nothing an agent needs to call and interpret this tool 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 0%, so the description bears the full burden and does so: it explains that project_id is optional and backend-resolved, that omitting model_version_id yields the latest version, and that full_report trades tokens for detail. Only model_id is left implicit, but its meaning is self-evident from the report 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?

Opens with a specific verb and resource — 'Load the EDA training report' — and enumerates the contents (metrics, feature analysis, performance summary), which cleanly separates it from siblings like get_model, get_model_version, and get_training_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?

Gives explicit routing rules: omit model_version_id for latest, pass an id from list_model_versions for a specific version, project_id optional, full_report=true for detail, and that the real holdout estimate comes from run_batch_prediction rather than this report. An agent knows exactly when to call it and what to call instead.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and idempotency profile is fully covered by structured data. The description's field list (status, edaReportStatus, target, timestamps) largely duplicates the existing output schema, so it adds little behavioral context beyond what annotations and the output schema already provide.

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

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

Two short sentences, zero filler, with the core action front-loaded and the disambiguation clause last. Every sentence earns its place.

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

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

For a simple read-only getter with rich annotations and an existing output schema, the description covers selection and scope adequately. The only gap is the unexplained parent-identifier semantics, which the schema does not supply either.

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

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

Schema description coverage is 0%, so the description must carry the burden, yet it only names version_id (and only in the usage sentence). The parent identifiers project_id and model_id are never explained; an agent must infer the id hierarchy from the tool name. Partial compensation only.

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 ('Fetch a single model version by id') and even enumerates the payload fields (status, edaReportStatus, target, timestamps). It explicitly contrasts itself with list_model_versions, so an agent can distinguish the two without opening 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?

'Prefer this over list_model_versions when you already know the version_id' names the alternative and the exact condition that selects it. Nothing about tool selection is left to inference.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real behavioral context: batch completions auto-include download_url/curl_command, the curl command carries a short-lived download token rather than the API key, and which fields are omitted for regressors. That is useful disclosure 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?

Purpose is front-loaded and the remaining detail is organized as bullet points. It is dense, but each bullet is a distinct behavior; no filler sentences.

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 single-parameter read tool with an output schema present, the description is more than complete; annotations cover safety and the return-shape detail is arguably redundant with the output schema but not harmful. Nothing needed to invoke it 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 0%, so the description should compensate, but it only restates that the parameter is a 'prediction id' with no format, source, or constraint details. Marginal value over the bare schema.

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

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

States a specific verb and resource ('Fetch prediction status and result by prediction id'), which clearly separates it from list_predictions (enumerate) and run_prediction (execute). It does not explicitly name a sibling, but the verb+resource+key is unambiguous.

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

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

There is no when-to-use guidance: no mention of when to poll this versus list_predictions, no note that it requires a prediction id produced by run_prediction/run_batch_prediction, and no indication of behavior when the prediction is still running. The description offers no routing context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that — no error behavior for a missing/invalid id, no permission requirements, no indication of what a not-found result looks like.

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

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

One short sentence with the key scoping word ("single") front-loaded and zero filler. It is terse rather than padded, though the terseness borders on under-specification.

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

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

With an output schema present, return values need no explanation, and annotations carry the safety profile, so the remaining burden is light. Still, for a lookup tool that is one of many get_* siblings, some anchor for obtaining the project_id or distinguishing from list_projects would make it complete rather than merely adequate.

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

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

Schema description coverage is 0% for the single required project_id, but the description's phrase "by id" confirms the parameter is an identifier and that it selects exactly one record. That is a marginal but real addition; it does not supply format or source of the 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 states a specific verb (fetch) and resource (a single project), and the word "single" implicitly contrasts with the sibling list_projects. However, it does not name or acknowledge any sibling explicitly, so the differentiation is left to inference.

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

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

There is no guidance on when to use this tool versus list_projects or get_dataset/get_model counterparts. The single word "single" is the only hint about scope, and no prerequisites (e.g., where the project_id comes from) are given.

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

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

Annotations already declare readOnly/idempotent/openWorld=false, so the safety profile is covered. The description adds genuinely new behavior: the content 'ships with the server and changes between releases' (so results are version-dependent) and that it 'makes no API call', which explains why it always succeeds.

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 and readable, but the parenthetical enumeration of the seven section names duplicates the enum already in the schema, and the return-shape sentence partially overlaps the output schema. Roughly one clause could be cut without loss.

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

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

An output schema exists, so return values need not be explained, yet the description still notes the guide_version and next-section fields. Combined with purpose, usage context, parameter behavior and versioning caveat, 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 description coverage is 0%, so the description must carry the load. It explains that 'section' selects one part or 'all', names the default ('overview'), and describes what each selected value returns. The parenthetical list essentially restates the enum, but the default and the 'all' behavior are real additions.

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 — 'Return the EasyDeploy data-science playbook' — and enumerates what the playbook covers (prepare, split, upload, train, validate, predict). No sibling tool returns guidance content, so the agent can distinguish it immediately from the operational tools.

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

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

Gives a clear use context: 'Useful at the start of a modeling task.' It does not name an alternative, but none of the siblings overlaps (they are all operational read/write endpoints), so no exclusion is needed. Slightly short of explicit when/when-not framing.

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 cover the safety profile (readOnly/idempotent/non-destructive); the description goes well beyond them by disclosing the polling interval, the 45s default and 60s ceiling, host-side tool-call cutoffs, and the exact timeout-expiry payload (timed_out: true plus next_steps). That is the operational context an agent cannot infer from annotations or schema.

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

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

Front-loaded with the one-line purpose, then a compact response-field list, then the wait/timeout semantics. Bullets and inline code formatting make it scannable, and no sentence is filler — even the closing warning about not resubmitting carries distinct guidance.

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 polling tool with a long-running backend, everything needed is present: the terminal states, the timeout contract, the retry loop, and the response fields. An output schema exists, yet the description's field summary still adds clarity about null-while-running and timed_out rather than duplicating blindly.

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%, so the description must carry the load, and it does: job_id's provenance, wait=true semantics, poll_interval_seconds (default 10 s), and timeout_seconds (default 45, max 60, larger values clamped). Every parameter is given meaning beyond its bare type/default.

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

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

States a specific verb and resource ('Check a training job by job_id') and immediately anchors the identifier to its source tool ('the jobId field from submit_training_job'), which cleanly separates it from sibling submit_training_job and from the unrelated get_upload_status/get_model_report.

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 contrasts the default non-blocking behavior with wait=true, and gives a precise recovery rule for the timeout case: 'call this tool again with the same job_id to keep waiting — do not resubmit the training job.' It even notes training can take hours, telling the agent when polling is expected rather than a failure.

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 read-only/idempotent/non-destructive profile, so the description is free to add richer behavior — a full status state machine (URL_ISSUED through EXPIRED), the meaning of the error field on REJECTED, and the sizeBytes/rowCount verification step. These go well beyond what the annotations provide.

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

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

Front-loads the core action and parameter source, then layers the status vocabulary, scope boundaries, and error handling. Every sentence carries actionable content; the enum list is dense but necessary.

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

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

An output schema exists so return shape needs no explanation, yet the description still adds the useful sizeBytes/rowCount confirmation step. Scope, prerequisites, states, and failure paths are all covered for a polling tool of 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 0% and there is one parameter, so the description must carry it — and it does, tying upload_request_id to its origin in start_upload. It stops short of format/length details, but the key semantic (where the id comes from) is supplied.

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 ('Poll an upload session by the upload_request_id') and explicitly homes it in the start_upload workflow. It distinguishes itself from siblings by naming start_upload as the source of the id and scope-limiting which channels report here (gateway PUT, host file parameter, upload_from_url).

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 when-to-use ('complete_upload only accepts READY — poll here first'), when-not ('files uploaded through the web model builder are not visible here... find them with list_datasets'), and failure handling ('on REJECTED... start a new upload rather than retrying this session'). This is textbook routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the returned field list, which is already implied by the output schema; it says nothing about pagination, result limits, or ordering for a list operation.

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

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

A single tight sentence, front-loaded with the verb and resource, with no filler. It is efficient, though the parenthetical field list is redundant given the output schema and could have carried usage information instead.

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 single-parameter list tool with an output schema, the essentials are covered, and return fields need not be restated. However, list semantics (pagination, ordering, empty results) are absent and the sibling routing is unaddressed, leaving gaps an agent would need to resolve.

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 (project_id) at 0% schema description coverage, so the schema gives no semantics. The description's 'in a project' loosely implies project_id identifies the project, but adds no format, source, or validation detail beyond that.

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

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

States a specific verb (List) and resource (datasets) scoped to a project, and names the fields returned. It is clear on its own but does not differentiate itself from siblings such as get_dataset (single dataset) or list_dataset_versions, which an agent must disambiguate by name alone.

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

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

There is no guidance on when to choose this over get_dataset or list_dataset_versions, and no note on prerequisites (e.g. that project_id must exist). The project scoping is implied but no alternatives or exclusions 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 already establish readOnly/idempotent/non-destructive, so the bar is lower. The description still adds real behavioral context: project_id is optional and the backend resolves access from dataset_id, and qa_status is informational rather than gating.

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

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

Front-loaded with the purpose and returned fields, then scoped notes. It loses a little economy to the trailing submit_training_job/version_type digression, which belongs more naturally in that sibling's documentation.

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

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

An output schema exists, so return values needn't be explained, and the description still covers the optionality and resolution behavior of the one tricky parameter plus qa_status semantics. It is complete enough for an agent to call 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 0%, so the description must carry the burden. It adequately explains the one non-obvious parameter by stating project_id is optional with backend resolution via dataset_id; the required dataset_id is self-evident.

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

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

States a specific verb+resource ("List all versions of a dataset") and even enumerates the returned fields. It is clearly distinguishable from the singular sibling get_dataset_version and from list_datasets, so an agent can select it without opening the schema.

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

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

Usage is implied by "all versions" versus the singular get_dataset_version, and the qa_status/version_type commentary gives useful context. But the version_type guidance actually concerns submit_training_job, not when to call this tool, and no explicit alternatives or exclusions are stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description adds only a hint at returned fields ('id, name'), which is redundant given an output schema exists.

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; it is appropriately sized for a trivial one-parameter list tool, though it is perhaps too thin to fully earn the space it takes.

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 list tool with one required parameter and an output schema that documents return values, the description covers enough to invoke correctly. Pagination or result-size behavior is not addressed, but nothing critical is missing given the existing structured fields.

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

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

Schema description coverage is 0% and the sole parameter project_id is undocumented in the schema. The description's phrase 'in a project' weakly implies the project scope of that parameter, but provides no format or semantics beyond the name itself.

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 ('List all models in a project'), which is clearly distinct from siblings like get_model (singular), create_model, and list_model_versions. It does not explicitly name those alternatives, so it falls short of the 5-level differentiation.

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 can infer you call this to enumerate models within a known project, but there is no explicit when-to-use, no prerequisite statement, and no pointer to alternatives like get_model or list_model_versions.

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 annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, closedWorld), so the bar is lower. The description then adds genuinely useful context beyond structured fields: the training state machine (SUBMITTED → TRAINING → TRAINING_COMPLETED/TRAINING_FAILED) and the report-readiness states, which tell the agent how to interpret and poll the returned data. It does not disclose pagination, ordering, or scoping behavior, keeping it from 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 short, front-loaded sentences with no filler: purpose first, then the two state vocabularies. Nothing is wasted, though the state lines are terse enough to be slightly cryptic without framing.

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

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

An output schema exists, so return values need not be spelled out, and the annotations cover safety. What remains missing is parameter scoping and any routing hint against the many sibling list/get tools, leaving the definition only minimally adequate for this simple list 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 0%, so the two required parameters (project_id, model_id) are documented nowhere. The description never mentions them or explains how they scope the listing, so it fails to compensate for the schema gap despite the names being fairly self-evident.

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

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

The description opens with a specific verb+resource ("List model versions"), which unambiguously conveys the operation. However, it offers no differentiation from closely related siblings such as get_model_version or list_models, and the opening sentence is a bare restatement of the title, 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives (e.g., get_model_version for a single version, or list_models for models rather than versions). The agent is left to infer the routing decision entirely.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds the useful behavioral fact that results come newest-first, but says nothing about pagination, result limits, or how an empty project_id behaves.

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

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

Two short sentences, no filler, with the ordering guarantee and optional filter front-loaded before the alternative-tool pointer.

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

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

For a one-parameter listing tool with an output schema (so return shape need not be explained) and full annotation coverage, this is nearly complete. The only missing pieces are pagination behavior and the meaning of the empty default project_id.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It does name the sole parameter and marks it optional, but adds no format details or behavior for the default empty string (presumably 'return all projects'), leaving a genuine gap.

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

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

States a specific verb and resource ('List predictions') plus the ordering guarantee ('newest first'), which no sibling name conveys. It also explicitly distinguishes itself from the sibling get_prediction, which retrieves a single record.

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 to use get_prediction(id) when the caller needs the full result plus a batch download URL, which is a concrete routing rule. However, it does not state when NOT to use this list (e.g., for unpaginated bulk exports) or how it relates to run_prediction/run_batch_prediction.

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, idempotent, non-destructive, and closed-world. The description adds useful context: it enumerates returned fields and explains that ids are the project_id used by other tools. It doesn't mention pagination or limits.

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

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

Two short, front-loaded sentences. Every clause carries information: scope, returned fields, and the downstream identifier semantics.

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

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

With an output schema present and full annotation coverage, the description needn't explain return values. It is nearly complete for a zero-param list tool; a note on pagination behavior would be the only meaningful addition.

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 are zero parameters, so the baseline is 4. No parameter meaning exists to add, and the description does not need to compensate for any schema 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 clear verb+resource ('List all projects') scoped to 'this API key'. It distinguishes itself from get_project by listing versus fetching a single one, though it doesn't explicitly name the sibling.

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?

Implied usage is clear from the name and the note about ids feeding other project-scoped tools, but there is no explicit when-to-use or when-to-prefer-get_project 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 the generic non-readonly/non-idempotent profile; the description goes well beyond by disclosing credit cost per row, the auto-resolution of project_id/target_feature, the hard failure mode when a training feature is missing, and the 9 MB download cap. The timeout/clamping behavior and the poll-to-keep-waiting fallback give the agent the operational picture annotations cannot.

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

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

Front-loaded correctly: purpose, then billing, then fleet/timing semantics, then the holdout-validation guidance. Every sentence adds information, but the holdout paragraph is long and drifts toward task-level tutorial content rather than tool-selection guidance, costing some tightness.

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

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

For a 7-parameter, async, credit-spending job with rich outputs, the description covers inputs, billing, failure modes, polling, and download constraints. Although an output schema exists, the extra explanation of the CSV's prediction/probability columns and classLabels is aligned with the schema rather than redundant noise.

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 schema description coverage at 29%, the description carries most of the load: it explains that project_id and target_feature are auto-resolved when omitted, and that dataset_version_id identifies both the input file and the row count used for billing. model_version_id is left to inference, but the three schema-documented timing parameters are covered in the schema itself, so the gap is narrow.

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

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

Opens with a precise verb+resource+scope: 'Score an entire dataset against a trained model version.' It immediately distinguishes itself from the sibling run_prediction (single-row) and get_prediction (follows an already-started job), so an agent can route correctly without opening 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?

Explicitly states that each call starts a NEW batch job and that get_prediction is the tool for following an existing one, naming the selecting condition (you already have a prediction_id). It also gives concrete when-to-use guidance for wait_for_result=true versus fire-and-poll, including what to do after timed_out.

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?

Rich disclosure beyond annotations: notes a prediction credit is spent, output format for classifiers vs regressors, how probabilities and classLabels are structured, that output uses the model's default rule, the max_wait_seconds clamp and timeout behavior with 'timed_out' and 'next_steps' returned. Annotations only provide basic hints like readOnlyHint=false, idempotentHint=false; the description adds substantial operational detail.

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 main action and key details, then elaborates on output and waiting behavior. Some sentences are long and dense, but every sentence contributes useful information. Slightly verbose but appropriate for a complex 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?

Given a tool with 7 params, nested input_data, and an output schema, the description covers all critical aspects: required params, auto-resolution, output format for classifiers/regressors, timeout behavior, and alternative tool usage. The output schema is present but the description still adds value by explaining the output structure's meaning.

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 29%, so description must compensate. It explains model_version_id is required (implied), that project_id and target_feature are auto-resolved when omitted, and the semantics of wait_for_result and max_wait_seconds. However, it does not clarify input_data structure or poll_interval_seconds beyond what's in 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+resource: 'Run a single ad-hoc prediction against a trained model version.' Clearly distinguishes it from run_batch_prediction (single vs batch) and from get_prediction (which 'follows one still running, by its prediction_id').

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 describes when to use it versus get_prediction: 'Each call is a new prediction and spends a prediction credit; get_prediction follows one still running.' Also explains the wait_for_result flag to choose between immediate and blocking behavior.

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 the mutation and open-world profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false). The description goes well beyond them by disclosing the single-use upload token, that the API key is never carried, a ~6 MB size cap, the RECEIVING->READY lifecycle, and egress-fallback behavior — meaningfully richer than the annotations alone.

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 organized into A/B/C channels plus a bolded dataset_id paragraph, so an agent can scan it. A few asides (e.g. the model-builder URL example) could be trimmed, but nearly every sentence carries decision-relevant 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?

An output schema exists so return values needn't be detailed, yet the description still explains next_steps, upload_request_id and dataset_id echo. Given the multi-channel upload complexity and 0% param coverage, it is complete enough 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 0%, so the description carries the burden and largely does: it explains `file` (host hydration shape, bytes fetched server-side), `dataset_id` (omit for new dataset, pass for new version, name ignored, echoed only when passed). `filename` and `project_id` are left implicit, but the two hard parameters are well covered.

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 ('Open an upload session for one file and return the ways to send its bytes') and immediately scopes it to one file per session, distinguishing it from the sibling upload_from_url, complete_upload and get_upload_status it references.

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?

Lays out three numbered channels (A host file param, B gateway PUT, C share link) with explicit conditions for choosing each, including network-egress caveats, and names the exact follow-up sequence (poll get_upload_status, then complete_upload). It even explains the dataset_id create-vs-new-version fork.

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 mark it destructive/non-idempotent, and the description adds genuinely new context: each call spends one training credit, every call starts a separate job, runtime ranges from minutes to hours, and passing a 'raw' dataset_version_id is rejected with 400 INVALID_VERSION_TYPE. This goes well beyond the safety hints.

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

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

Front-loaded with the core action and cost, then well-sectioned guidance for tracking and the optional param. It is longer than strictly necessary but each block (tracking, dataset_version_id rules) earns its space.

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

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

For a credit-spending, non-idempotent mutation the description covers cost, idempotency implications, tracking paths, and parameter edge cases, and even echoes the return shape despite an output schema existing. Nothing an agent needs to invoke it 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 0%, so the description must carry the load, and it explains dataset_version_id in depth (omission behavior, override semantics, backend resolution, raw rejection). model_version_id is only implicitly defined by the tool's purpose, so one of the two params lacks explicit semantics.

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

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

States a specific verb+resource ('Submit a training job for a model version') that an agent can distinguish from siblings like get_training_status and create_model_version. The description immediately clarifies that this starts a job versus the siblings that follow or set up one.

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 routes the agent: this call starts a job and spends a credit, while get_training_status follows an already-submitted job by job_id. It also gives precise conditions for omitting vs passing dataset_version_id and names the alternative flow, 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?

Annotations already declare idempotentHint=true and destructiveHint=true, so the description's 'repeating the same call leaves the dataset in the same state' largely restates the annotation. It does add genuinely useful behavior beyond annotations by clarifying partial-update semantics ('fields left empty are not changed'), but it never explains that a supplied description overwrites the existing one, which is the destructive behavior the annotation flags.

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

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

Three short sentences, front-loaded with the core action and with zero filler. The closing sentence about returning the updated dataset record is redundant given a dedicated output schema exists, a minor wasted line.

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

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

For a four-parameter mutation tool with annotations and a full output schema, the description supplies the essential missing piece (partial-update semantics) and need not explain return values. An agent could call this correctly; only the overwrite behavior of description and the role of the two ID parameters remain implicit.

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

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

Schema description coverage is 0%, so the description has to carry the load, and it does for the two meaningful optional parameters: at least one of name/description must be supplied, and the empty-string default means 'no change'. project_id and dataset_id are left unexplained, but they are self-evident identifiers whose required status is already encoded in the schema.

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

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

The description names a specific verb+resource ('Rename a dataset or change its description') and scopes it to exactly two mutable fields, which separates it from versioning siblings like create_dataset_version and read siblings like get_dataset. It stops short of naming an alternative, but the operation is unambiguous.

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

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

'Pass at least one of name or description' gives a real precondition for invocation, and the rename-or-re-describe framing implies the context of use. However, there is no explicit guidance on when to use this versus create_dataset_version (content changes) or get_dataset, so usage is only implied rather than routed.

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?

Adds substantial context beyond annotations: the 256 MB cap, that bytes never pass through the model/conversation, SSRF protections (private, loopback, metadata addresses rejected), the allowlist rule, the RECEIVING end state, and 409 semantics. These are behavioral traits the openWorldHint/destructiveHint flags 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?

Front-loaded with the core action, then organized into accepted sources, limits, and return/error behavior. Efficient and scannable, though the final paragraph about start_upload's fallback string drifts slightly into another tool's territory.

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

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

Given an output schema exists, the description need not restate return values, yet it still covers the RECEIVING state, the 409 failure mode, size limits, and security rejections. 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 coverage is 0%, so the description must carry the load. It defines source_url thoroughly (accepted sources, URL-never-contents rule), but upload_request_id is only implied as coming from start_upload rather than defined explicitly. Strong compensation overall, one identifiable gap.

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

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

States a specific verb and resource plus the mechanism: 'Hand EasyDeploy a URL to fetch an upload session's bytes from, server-side.' It also distinguishes itself from siblings by referencing start_upload's session and the fallback path, so an agent can tell it apart from complete_upload or plain start_upload.

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 triggering conditions: 'when the sandbox has no network egress (the gateway curl failed with a connection error)' or 'when a host handed you a file download link.' It also names the recovery alternative (409 → call start_upload again) and the ultimate fallback channel, covering when-not and what-to-do-instead.

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