EMT Compute

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds real operational context not in structured data: the whole cluster stops on completion or cancel, billing continues during preparation, and SSH must be started locally with emt_cluster.py. That lifecycle and billing behavior is exactly the kind of thing an agent needs before calling a destructive 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?

Three tightly packed sentences, front-loaded with purpose then the two operational gotchas. No filler or restatement of the tool name.

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

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

The workflow-critical warnings (local SSH launch, cluster teardown, ongoing billing) are covered, which matters for a destructive tool, but with 12 undocumented parameters, a nested experiment union, and no output schema, an agent still lacks enough to fill the request 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% across 12 parameters, including nested objects and a three-way experiment union, yet the description explains none of them. It only hints obliquely at the ssh parameter ('your private key') and never addresses experiment kinds, level, maxMinutes, clusterOrder, or the required idempotency_key, so it fails to compensate for the documentation 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?

Names a specific verb and resource: 'Attach work to an already rented dedicated 2–4-node cluster.' The 'already rented' qualifier implicitly separates it from emt_rent_cluster and emt_start_experiment, though no sibling is named explicitly.

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

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

The precondition (cluster must already be rented) is clear, and the description explicitly states one important limitation: it does NOT start SSH remotely. It stops short of naming emt_rent_cluster or emt_start_experiment as alternatives, so the routing is inferred rather than stated.

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

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

The annotations already establish read-only, non-destructive, idempotent external access, while the description adds meaningful response behavior: USD micro-units per GPU/hour, nulls for unknown metrics, and pagination to limit response size. It does not further explain data freshness, result ordering, or how callers detect the final page.

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 compact statements front-load the resource and then convey pricing units, null handling, and pagination without filler. Each statement contributes useful information.

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

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

This is sufficient for a basic safe read and for interpreting offer prices, with annotations covering the safety profile. However, the absence of an output schema and parameter descriptions leaves offer fields, model-filter behavior, page-completion semantics, and the catalog's relationship to quoting or renting insufficiently explained.

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 0% schema description coverage, the description needed to compensate, but "Paginated" only indirectly clarifies limit and offset. It adds nothing about the model parameter beyond its schema name, leaving whether it performs exact, partial, or case-sensitive GPU-model filtering unclear.

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?

"Current GPU offers" clearly identifies the resource and its freshness, implying a catalog retrieval operation. It relies on a noun phrase rather than an explicit list/get verb and does not distinguish the catalog from siblings such as emt_quote or emt_templates.

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 emphasis on current offers and pagination implies use for browsing available GPUs and retrieving additional pages. There is no explicit when-to-use or when-not guidance, nor any routing between this tool and the quote, rent, cluster, or template 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?

Against annotations that already declare destructiveHint=false and openWorldHint=true, the description adds that this does not rent or provision resources, which is meaningful behavioral context. It still does not explain what a quote represents, whether it creates a persistent quote object despite readOnlyHint=false, or how long it remains valid.

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

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

The description is a single front-loaded sentence with no filler, so it is concise and easy to scan. Its brevity comes at the cost of missing semantics, but that is better assessed under completeness rather than conciseness.

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

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

For a tool with three required parameters, no output schema, and zero schema description coverage, one sentence is not enough. Key details an agent needs, such as what the quote returns, whether resources are held, and what the hours parameter controls, are absent.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It loosely maps 'selected whole nodes' to the nodes array and 'one fabric' to the cluster identifier, but it never explains 'hours' or clarifies units, bounds, or UUID expectations.

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 verb ('Quote') and a resource ('selected whole nodes on one fabric') and contrasts with renting, so the basic purpose is inferable. However, 'quote' is not defined (pricing, availability, reservation?) and 'fabric' is not aligned with the tool name's 'cluster', leaving ambiguity against siblings such as emt_quote and emt_experiment_quote.

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 'without renting' implies this is the non-provisioning alternative to emt_rent or emt_rent_cluster, which is useful implied guidance. But it does not explicitly say when to choose this over emt_quote or emt_experiment_quote, nor does it state prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds one domain rule — that fabric declarations do not confer EMT qualification — which is genuine extra context, but it is too terse to be actionable and omits freshness, scope, or result shape.

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?

It is short and front-loads the primary fact about the resource. The second clause is dense, undefined terminology placed as a semicolon fragment, which costs more confusion than the brevity saves.

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 listing tool with no output schema, the description only needs to identify the resource and its scope, which it does. The missing piece is what the offer records contain and how current they are, but the annotation set covers the operational profile.

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 for a no-parameter schema applies, with the only deduction being the absence of any hint about what a call yields.

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 ("whole-node cluster offers") and implies a listing verb via "Current", so the object is identifiable. However, no explicit verb is given and the second clause ("fabric declarations do not establish independent EMT qualification") is unexplained jargon, so it does little to separate this from siblings like emt_cluster_quote or emt_rent_cluster.

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 emt_cluster_quote, emt_rent_cluster, or emt_cluster_quote's siblings, and no prerequisites are mentioned. The qualification caveat hints at a boundary condition but never says what to use instead when that condition applies.

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 open-world, so the safety profile is covered. The description does add genuinely useful context beyond that: links are authenticated and files are NOT injected into model context, which sets agent expectations about what it can actually read. It stops short of stating permission requirements or the shape of the returned links.

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. The primary action and its outputs are front-loaded, with the context limitation on files placed last as a caveat.

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

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

For a one-parameter read tool with rich annotations and no output schema, the description does cover what is returned (result, output, report links) and the file-access caveat. It is still thin on error/ownership behavior and on how to obtain a job id in the first place relative to the surrounding experiment-job tools.

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

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

One parameter with 0% schema description coverage, so the schema supplies only 'type: string, format: uuid'. The description contributes the ownership constraint ('an owned experiment'), implying the job must belong to the caller, but never explains the identifier itself or what happens on a non-owned/unknown job.

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

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

Uses a specific verb (Inspect) on a specific resource (an owned experiment) and enumerates what comes back: authenticated result, output and calculation-report download links. It implicitly contrasts with the list-style sibling emt_experiment_jobs but never names it, so differentiation is left partly 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?

Usage is only implied: the single required 'job' id and the word 'owned' suggest you call this when you already hold an experiment job UUID. There is no explicit when-to-use/when-not-to-use guidance and no mention of emt_experiment_jobs as the alternative for discovery.

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, so the safety profile is covered. The description adds one genuinely useful behavior not in the annotations: a required read scope (an auth prerequisite). It says nothing about pagination, sorting, result volume, or what 'release state' means for the caller.

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

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

Two short sentences with no filler, and the resource is stated first followed by the access prerequisite. It is close to optimally sized, though the first sentence subordinates the actual action to a noun phrase.

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

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

A parameterless read is simple, but there is no output schema, so the description is the only place an agent can learn what comes back. 'Including reports and release state' gestures at the payload without explaining its structure or whether the list is scoped to the calling user ('Owned').

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 and the schema has full coverage, so there is no parameter meaning to add. The description appropriately avoids inventing filtering options that do not exist.

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 ('Owned experiment jobs') and hints at returned content ('reports and release state'), but never supplies a verb such as list or retrieve, so the agent must infer that this is a collection read. It also does not distinguish itself from the singular sibling emt_experiment_job, which is the main ambiguity an agent would face.

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. With a near-identical sibling name (emt_experiment_job) present, the description should say it returns all jobs versus a single job, or whether a narrower sibling such as emt_monitor should be preferred for live status; it says none of this.

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, so the safety profile is covered. The description adds genuine value with the negative scope ('does not run a calculation') and by disclosing the shape of the returned detail. It says nothing about openWorldHint implications, error behavior for an unknown id, or how large the preset catalog 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?

Two tight sentences with the primary capability front-loaded and the scope limit last. No filler, no restatement of the tool name. Slightly dense packing of four return categories into one clause, but nothing 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?

A simple read-only tool with one optional parameter and no output schema; the description covers both modes, the nature of the returned detail, and the boundary against calculation execution. The only meaningful gap is identifier format and failure behavior for an unknown 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% for the single optional 'id' parameter, so the description must carry the meaning. 'Inspect one preset's ...' implies the id selects a single preset and that omitting it lists all, which is real added meaning, but it never says whether the id is a slug, name, or opaque key, nor what happens with an invalid value.

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

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

The description gives specific verbs (list, inspect) paired with a specific resource (scientific presets) and enumerates what inspection returns: parameters, equations, methods, custom-input schema. The closing clause 'Does not run a calculation' separates it from the experiment-execution siblings such as emt_start_experiment, though no sibling is named explicitly.

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

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

'List ... or inspect one preset's ...' encodes the selection rule: no identifier yields a catalog listing, an identifier yields detail on a single preset. The exclusion 'Does not run a calculation' rules out a plausible misuse. It stops short of naming the alternative tool an agent should call instead when it actually wants to run a calculation.

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, the description explains the cost model (hours x hourly yields a ceiling in micro-USD) and clarifies what the resulting reserve means, an initial hold rather than total cost. That also reconciles with readOnlyHint=false, since a reservation hold is a state change, so nothing is contradicted.

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

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

Two short sentences with the scope and pricing formula front-loaded, and no filler. The second sentence is terse but still carries real information about reserve 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 8 undocumented parameters, no output schema, and several overlapping/ambiguous fields (node/nodes/count/model), the description does far too little to guide correct invocation. It explains the pricing math but not how to populate the inputs or what the response contains.

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

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

Schema description coverage is 0% across 8 parameters, and the description only hints at the node count ('1-4 nodes', matching the `nodes` parameter). It says nothing about the ambiguous overlaps between `node` vs `nodes`, `count` (max 8) vs `nodes` (max 4), `model`, `minVram`, `environment`, or how `maxMinutes` relates to the 'hours' in the formula.

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: quote 1-4 nodes for an experiment, with the pricing formula (hours x hourly, micro-USD). The 'for an experiment' qualifier separates it from sibling quote tools such as emt_quote and emt_cluster_quote, though it does not name those siblings 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?

There is no explicit when-to-use guidance: the description never says to call this before emt_rent or emt_start_experiment, nor when to prefer it over emt_quote or emt_cluster_quote. Usage is only implied by the word 'Quote'.

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 declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior, so the safety profile is largely covered. The description adds a useful behavioral caveat that missing telemetry is treated as unknown rather than zero, but it does not describe auth needs, data freshness, or what lifecycle data is returned.

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

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

The description is front-loaded and has no filler, but it is too terse for a tool with no output schema and only a single undocumented parameter. The second sentence is useful but cryptic without context.

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 0% parameter description coverage, the description should carry more burden. It does not explain what metrics or lifecycle information is returned, what happens when telemetry is missing, or any operational constraints.

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

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

The schema has one required 'order' parameter with 0% description coverage, so the description must compensate. It adds the important qualifier that the order must be owned, but it does not explain that the value is a UUID or how to obtain or validate the order identifier.

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

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

The description identifies the resource as an owned order and the domain as metrics and lifecycle, which hints at monitoring. However, it uses no clear action verb and does not distinguish the tool from siblings such as emt_orders or emt_terminate beyond the vague phrase 'metrics and lifecycle'.

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 guidance, no exclusions, and no mention of alternatives among the many sibling tools. An agent must infer that this is the monitoring tool rather than an order-listing or termination tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds the read-scope requirement and notes that lifecycle states are included, but it does not describe pagination, ordering, or return shape.

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

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

Two short sentences with no redundant wording; the resource scope is front-loaded and the auth requirement follows. It is appropriately sized for a no-parameter tool.

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

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

For a no-parameter read tool, the description covers the resource and auth requirement, but it leaves return behavior (e.g., whether all owned orders are returned, pagination, or state representation) unspecified and there is no output schema to compensate. It is minimally adequate rather than 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?

There are zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the empty schema is consistent.

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

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

The description identifies the resource ('Owned GPU orders and lifecycle states') but omits an explicit action verb such as list or get, so the agent must infer that this is a read operation. It does not explicitly differentiate from siblings like emt_rent or emt_terminate beyond the 'owned' scope.

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 states 'Requires read scope,' which is an auth prerequisite rather than when-to-use guidance. It gives no indication of when to choose this over emt_rent, emt_terminate, or other order-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?

Annotations already disclose that this is a non-read-only, non-idempotent, non-destructive, open-world operation. The description usefully adds that the quote is expiring and incurs no charge, but it omits the quote TTL, whether capacity is held, and what state or identifier is returned.

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

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

A single front-loaded sentence with no filler. Every phrase contributes either the action, the object, or a key constraint.

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

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

The tool is structurally simple, but the description leaves node semantics unexplained and does not say how the expiring quote is returned or how long it lasts. For a 3-parameter required tool with no output schema, this is adequate but incomplete.

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 all three required parameters. The description's 'GPU quote' context weakly implies that count is a GPU quantity and hours is a duration, but it says nothing about the required node UUID or acceptable ranges.

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

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

The description gives a specific verb and resource: 'Create a fresh expiring GPU quote,' and clarifies it does not rent or charge. This distinguishes it from emt_rent, though it does not explicitly differentiate it from sibling quote tools like emt_cluster_quote or emt_experiment_quote.

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?

'Without renting or charging' implies the tool is for pricing-only use, which gives useful context. However, no sibling alternatives are named and there is no explicit guidance on when to prefer this over emt_rent or the other quote tools.

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

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

Annotations already establish this is a non-read-only, open-world, non-destructive mutation. The description adds value beyond them: it is a money-spending operation requiring authorization and credit, and it warns that payload and key must be stored before requesting — implying credentials are returned once and the call is not safely repeatable. Return shape and failure/charge semantics remain unstated.

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 operation and its gating requirements. It is dense but slightly cryptic — 'store payload and key' never says what payload, costing a small amount of clarity for its brevity.

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 10-parameter, paid, irreversible-flavored provisioning call with no output schema and no parameter documentation, the definition is under-specified: it omits how name/template/ssh/ports/backups/volume map to a rental and says nothing about what comes back or how charges accrue.

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

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

Schema description coverage is 0% across 10 parameters, so the description must carry the load. It only gestures at three of them (quote via 'fresh quote', idempotency_key via 'key', confirm_paid_rental via 'spending authorization'), leaving ssh, ports, volume, backups, jupyter, name, and template with no meaning anywhere in the definition.

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

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

States a specific verb and resource: 'Start a PAID GPU rental'. This is clear and distinct from sibling emt_rent_cluster only by implication (GPU vs cluster); the description never explicitly contrasts the two, so an agent must infer the split from names.

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?

Lists concrete preconditions for invoking it: explicit spending authorization, a fresh quote, rent scope, credit, and accepted terms. This is real context that gates use, but it gives no explicit when-not-to-use guidance or named alternative (e.g., emt_rent_cluster or emt_quote for obtaining the quote first).

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 this is a non-read-only, open-world, non-destructive mutation, and the description usefully adds that the rental is paid, that only a public SSH key is accepted, and that user confirmation is required. It does not explain the cost/commitment consequences, provisioning duration, or cancellation path. It also does not reconcile the required idempotency_key with idempotentHint=false, leaving a semantic ambiguity for a money-spending call.

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, and the paid nature is stated before the constraints. 'Fabric limits' is an internal term that costs a little clarity in 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?

Given a paid, irreversible-ish provisioning mutation with five required params, 0% schema coverage, and no output schema, the description should say what is created and returned (cluster identifier) and how the quote ties in. The safety-relevant prerequisites are covered, but the parameter surface and result shape are not.

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

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

Schema description coverage is 0% across six parameters, so the description carries the full burden and adds meaning only for ssh ('public SSH key only'). The quote UUID, name, confirm_paid_rental, idempotency_key format, and especially the optional acknowledgeSlowNetwork const-true flag are entirely unexplained anywhere.

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

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

States a specific verb and resource: 'Start a PAID whole-node cluster rental', with the PAID emphasis signalling the cost-bearing variant. It is distinguishable from quote/catalog siblings by the verb, but it never names those siblings or explains how it differs from the generic rent tools in the list.

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 real prerequisite-lite workflow cue ('Confirm cost and fabric limits with the user first'), which implies a prior quote step and human confirmation. It does not name emt_cluster_quote as the prerequisite or state when to prefer this over emt_rent, so the routing guidance remains 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 the generic write/open-world/idempotent profile; the description adds real substance — that parameter sets are distributed across quoted nodes and do NOT parallelize a single solver, that auto-continuation can rent extra segments up to a budget, and that costs must be reviewed before confirming. This meaningfully extends the annotation profile. It does not explain why the tool is marked non-idempotent despite requiring an idempotency_key, which is a notable omission.

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 compact sentences, front-loaded with the paid/start action, then the distribution caveat, the auto-rental caveat, and a confirmation warning. No filler, though the clauses are dense enough that the parallelization warning reads slightly ambiguously.

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 13-parameter, deeply nested, paid, open-world mutation with no output schema, the description covers cost and scheduling behavior but leaves the majority of parameters and the return value entirely unexplained. An agent still needs to infer how to populate ssh, files, config, resume, and idempotency_key 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% across 13 parameters, so the description carries the burden and only partially delivers: it explains the quotes-as-nodes semantics, the auto budget/maxSegments rental behavior, and the three experiment variants. It says nothing about ssh, seed, files, level, config, resume, name, runs, or the required idempotency_key, leaving most parameters undocumented anywhere.

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

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

The description names a specific verb ("Start") and the three concrete experiment types (preset, customer script, command), plus flags the operation as PAID. It is clearly distinguishable from listing/inspection siblings like emt_experiment_jobs or emt_monitor, though it never names an alternative outright.

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: "Review all costs before confirming" hints that quotes should be obtained first (via emt_quote/emt_experiment_quote), but no sibling or prerequisite is named. There is no explicit when-not-to-use guidance, e.g. when to prefer emt_rent or emt_rent_cluster over a full experiment launch.

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, non-destructive, and open-world behavior. The description adds public-access scope and ordinary-rental applicability, but does not describe return format, pagination, or other runtime behavior.

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

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

A single efficient sentence with no filler, front-loading the resource and its scope. It is appropriately sized for a simple zero-parameter tool.

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

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

For a zero-parameter read-only listing with rich annotations, it identifies the resource but never explicitly states the action (list/retrieve) or what the response contains. This is enough to infer usage, but not fully self-contained, especially with no 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?

The tool has zero parameters, so the parameter-semantics baseline is 4. No additional parameter meaning is needed or missing.

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 concrete resource (public GPU container templates) and qualifies scope (ordinary rentals), so the purpose is clear. However, it is a noun phrase without an explicit verb and does not clearly exclude siblings such as emt_catalog or emt_experiment_presets.

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 "for ordinary rentals" implies when the tool is appropriate and distinguishes it from experiment-related siblings, but there is no explicit when-to-use statement, prerequisite, or named alternative.

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 destructive=true and idempotent=false, and the description adds real value on top: local disks are deleted while retained volumes and backups continue to be billed, which is a cost consequence an agent cannot get from structured fields. It also implies the operation is asynchronous by telling the caller to poll status, though it never states what happens on a repeat call or partial failure.

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

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

Three short sentences, front-loaded with the action and scope, then the destruction/billing consequence, then the follow-up step. No filler; nothing is buried.

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?

Covers what is destroyed and how to verify completion, which is most of what matters for a two-parameter destructive tool with no output schema. However, it leaves the caller guessing what the call returns and which tool confirms release, and the zero-coverage parameters are never unpacked.

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 parameters carry no documentation. The description indirectly motivates confirm_local_data_loss by warning that local disks are deleted, and 'owned rental' hints at what order refers to, but neither parameter is explicitly explained or constrained.

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: 'Terminate every node in an owned rental.' That is concrete and clearly different from siblings like emt_rent or emt_cancel_experiment, but it never names an alternative, so the agent must infer the boundary rather than being told it.

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

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

Implies when to use it (you hold an owned rental and want it gone) and adds useful follow-up guidance ('Inspect status until release is confirmed'), but gives no when-not conditions, prerequisites for ownership, or a pointer to whichever sibling reports release status.

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