Lium GPU Cloud: live GPU prices and rent links

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

Annotations only cover the read-only/non-destructive safety profile, but the description adds real behavioral context: the earning model (95% of renter price, 30-day utilisation, validator idle rate), the fact that actual earnings and a provider middle-half range are returned, and the disclaimer 'An estimate, not a guarantee'. This goes 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?

The purpose is front-loaded and the when-to-use guidance follows, but the core sentence is a dense run-on stacking several clauses with semicolons. Every element earns its place, yet the middle section could be tightened.

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

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

With no output schema, the description carries the burden of explaining returns and does so: rental income, idle pay, actual earnings, and the middle-half range across providers. Combined with the usage trigger and the 'estimate, not a guarantee' caveat, an agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100%, so gpu and count are already documented with examples and defaults in the schema. The description only loosely references 'GPUs of a model' and never mentions the count parameter, so it adds no meaningful semantics beyond the schema.

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

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

States a specific verb and resource ('Estimate what a provider earns per month on Lium') and details the computation model, including rental income at 95% of renter price, idle pay, and the middle-half range. An agent can distinguish it from siblings like get_gpu_prices or search_gpus 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?

Explicitly states when to use it ('Use when someone asks what their GPUs could earn on Lium') and names the alternative for a different intent ('for renting GPUs use search_gpus'). Both the trigger and the exclusion 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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description adds only the USD denomination and nothing further about freshness, caching, or auth; with the annotation bar met, this is minimum viable rather than rich.

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 short sentence with no filler, and the key information (balance, USD) is front-loaded. It is efficient, though it is almost too terse to add much beyond the title.

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, parameterless tool with no output schema, the description conveys what is returned and its currency, which is the main thing an agent needs. Nothing complex is being asked of it.

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. The baseline for a parameterless tool applies, and the description correctly avoids inventing inputs.

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

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

The description names a specific resource (Lium balance) and states its unit (USD), which is enough for an agent to know it returns the account's balance. It does not need to distinguish itself from siblings, which cover unrelated resources (pods, GPUs, templates), so no differentiation is required.

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 or when-not-to-use guidance. However, for a zero-parameter balance getter the usage is strongly implied — an agent calls it when it needs the account's current balance — so this is adequate rather than absent.

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 and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: the data is live/right-now, and the count semantics caveat (a 1-GPU price can come from a node with one free GPU) warns about aggregation interpretation. It does not discuss rate limits or freshness latency, but the lower bar set by annotations makes this a solid 4.

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

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

Three tight sentences with the return shape front-loaded, followed by usage and the parameter caveat. No filler, and the most decision-relevant information leads.

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

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

There is no output schema, and the description compensates by naming the exact returned fields (min/median/max price, free GPU count). With optional params and annotations covering the safety profile, an agent has everything needed to call and interpret it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining why count matters and the subtlety that a single-GPU quote may reflect a node with only one free GPU, which affects interpretation of results. The country param gets no added semantics, keeping this from a 5.

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

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

States a specific verb+resource (live GPU prices) and enumerates exactly what is returned: min/median/max USD per GPU-hour plus free GPU count per model. It also explicitly contrasts itself with search_gpus, so an agent can distinguish it from the sibling without reading either schema.

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

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

Gives concrete use cases ("what does an H100 cost", comparing models) and names the alternative tool with its selecting condition: use search_gpus to pick a node to rent. Both when-to-use and when-to-use-something-else are covered.

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 safe read-only, non-destructive operation in a closed world. The description adds meaningful behavioral detail by noting the ssh command is only available once the pod is RUNNING, and it previews the returned cost/spend information.

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

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

The description is a single front-loaded sentence with no filler. It is efficient, though the fragment style ('One pod: ...') is slightly terse and could be marginally clearer.

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

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

With no output schema, the description usefully enumerates the main returned fields and the RUNNING condition for ssh. It omits error/not-found behavior, but for a simple read tool this is largely 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 100%, and the pod_id parameter is documented in the schema as coming from rent_pod or list_pods. The description adds no parameter-level detail beyond that, so baseline 3 is appropriate.

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

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

The description makes clear this retrieves a single pod and names the key fields returned (status, ssh command, price, spend). It is specific about the resource, though it does not explicitly contrast with the sibling list_pods tool.

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

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

There is no statement of when to use this tool versus list_pods or other alternatives. The schema note that pod_id comes from rent_pod or list_pods offers indirect context, but the description itself provides no usage 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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral content by disclosing the return fields (status, ssh command, hourly price), which is meaningful since no output schema exists. It does not address ordering or pagination.

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 with the resource front-loaded and no filler. Every element earns its place.

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

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

For a zero-parameter read tool with annotations covering safety and no output schema, the description supplies the key return contents. Missing only minor details like ordering or whether all pods or a page are returned.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies an unfiltered 'your pods' listing with no input semantics to explain.

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

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

States the resource (your Lium pods) and the payload it returns (status, ssh command, price per hour), plus the title supplies the verb 'List'. It contrasts implicitly with the singular get_pod sibling, though it never names 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?

There is no explicit when-to-use guidance, no mention of the get_pod alternative, and no statement that it takes no filters and simply returns everything. The agent must infer usage from the name alone.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral value beyond that: it discloses the result scope (official, your own, and other users' public templates) and that official and owned entries are marked in the response, which matters for parsing results. Return format and pagination are still 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?

One dense sentence with no filler, and the resource is front-loaded. The nested parenthetical makes it slightly harder to parse than a clean two-clause sentence would be.

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

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

There is no output schema, but the description compensates by describing what the listing contains and how entries are marked, and the single parameter is schema-documented. Only return shape/format details are missing, which is a minor gap for a simple read-only list.

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

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

Schema description coverage is 100% and the single search parameter is fully documented in the schema with examples (pytorch, vllm). The description mentions no parameters at all, so it adds nothing beyond the structured data; baseline 3 applies.

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

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

The description states the resource concretely (Docker templates a pod can start from) and its scope (official, your own, other users' public), and ties it to the sibling rent_pod's template_id. It lacks an explicit verb in the sentence, relying on the tool name for the action, so it falls short of the crisp verb+resource ideal.

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 rent_pod template_id' implies this is the discovery step that feeds rent_pod, which gives an agent a usable cue. However, it never states when to call this versus not, nor does it mention prerequisites or ordering explicitly.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false, destructiveHint=false), so the bar is lower. The description adds real behavior beyond that: the output is raw Markdown, and ambiguous basenames resolve deterministically via an audience order. It omits not-found/error behavior, which keeps 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 sentences, front-loaded with the return value, then input forms, then the edge-case rule. No filler and nothing that could be cut.

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 no output schema, the description tells the agent what comes back (raw Markdown) and how inputs resolve. Only error/not-found behavior is unaddressed, a minor gap given the simplicity.

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

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

Schema coverage is 100% so the three accepted formats are already documented, but the description adds resolution semantics the schema cannot express — the audience precedence order used when basenames tie. That is meaningfully more than the schema provides.

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

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

States a specific verb and resource — 'Return the raw Markdown source for a documentation page' — which immediately separates it from every sibling (pods, GPUs, balance, templates). The accepted input forms are named concretely with examples.

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 (read docs) but there is no explicit when-to-use/when-not statement or routing to a sibling such as 'search' for finding pages. The tie-breaking rule is genuine disambiguation guidance, but it only covers one narrow case.

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=true, and the description still adds genuine context: billing stops when the request is accepted, deletion is asynchronous and observable via get_pod (DELETING), and pod data is lost. These are operational facts an agent cannot derive from 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?

Three short sentences, no filler, and the most consequential fact (data loss) is placed last as a clear warning while the async/billing behavior is front-loaded. Every clause earns its place.

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

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

For a destructive, async mutation with an output-schema-less response, the description covers what an agent needs: the request semantics, the billing cutoff, the eventual consistency window and how to verify it, and the destructive consequence.

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 and schema coverage is 100% — pod_id's description even names its source tools (rent_pod, list_pods). The description adds nothing about the parameter, so the baseline of 3 is appropriate.

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

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

States a specific verb+resource ('Request pod deletion') that an agent can immediately distinguish from rent_pod, get_pod, and list_pods. It does not explicitly contrast itself with siblings (e.g., no mention that this is the only teardown path), but the purpose is unambiguous.

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

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

Usage is implied by the operation itself, and the description usefully points at get_pod to observe the DELETING state. It gives no explicit when-to-use/when-not guidance, prerequisites, or confirmation of what happens on an already-terminated pod.

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

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

Goes well beyond the annotations by disclosing the financial side effect ('Spends money from your Lium balance'), per-second billing that continues while idle until remove_pod, and the mandatory idempotency key with its 24-hour retry window. These are exactly the high-stakes traits an agent needs before making an irreversible purchase.

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

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

One dense paragraph that front-loads the action, then cost, then parameter modes, then the idempotency contract. No filler sentences; every clause carries operational weight.

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

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

With no output schema, the description still names the return values (pod id, ssh command), covers cost, billing duration, idempotent retry, and both parameter modes. Nothing material to a correct invocation 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 100%, so baseline is 3, but the description adds real meaning: it explains the gpu-mode vs node_id-mode split and that country and max_price_per_gpu_hour only apply with gpu, not node_id. It omits mode guidance for template_id, name, and ssh_public_key, which are left to the schema.

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

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

States a specific verb and resource ('Rent a GPU pod on Lium'), the blocking behavior ('wait until it runs'), and the return payload ('pod id and the ssh command'). It is clearly distinguishable from siblings like remove_pod, list_pods, and search_gpus.

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 gives two mutually exclusive invocation paths ('give gpu ... or node_id from search_gpus alone'), routes the agent to sibling tools (search_gpus, list_templates), and prescribes the retry protocol with idempotency_key on failure/timeout. The when-to-use conditions are stated rather than inferred.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds non-obvious behavior: audience filtering changes result ranking and omitting it down-weights the other side's pages. It does not mention result limits or return shape, but that gap is minor against the annotation coverage.

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

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

Three tight sentences, zero filler, with the core purpose and the routing constraint front-loaded before the optional audience detail.

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

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

No output schema exists, and the description does not describe the return format or that limit controls result count, though the schema covers limit. For a simple read-only doc search, purpose, routing and audience semantics are otherwise sufficient.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema's simple 'Filter results to a specific audience section' by explaining the ranking consequence of omitting audience, which is meaningful semantic detail the schema lacks.

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 ('Search the Lium documentation for pages matching the query') and explicitly distinguishes itself from search_gpus and get_gpu_prices, which are named siblings. An agent can route correctly 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?

Explicitly says when to use it ('how-to questions (renting, SSH, templates, providing GPUs)') and names the alternatives for the excluded case (live GPU availability or prices). This is a full when/when-not/alternative statement.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), so the description's job is to add context beyond that. It does: sort order is disclosed, prices are live USD, each result carries a rent link, and 'next_step says how to rent one.' It also surfaces non-obvious node semantics (tier secure/spot, min_gpus_per_rental meaning some nodes rent only whole). Only the exact response shape/pagination behavior is left vague.

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 dense sentences, front-loaded with what the tool returns and the ordering, then usage routing, then extra result fields. Every clause carries information, though the third sentence packs several concepts (tier, reliability_score, min_gpus_per_rental, next_step) tightly.

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

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

No output schema exists, so the description must carry return semantics, and it does: ordering, live prices, rent link, tier, reliability_score, min_gpus_per_rental, next_step. Complete enough for a flexible 5-param filter tool; only result-count/pagination behavior is unspecified.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents every parameter including examples and ranges. The description echoes the filter set (GPU model, count, country, price cap) without adding syntax or constraint detail beyond the schema.

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

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

States a specific verb (List), resource (rentable GPU nodes on Lium), ordering (cheapest per GPU-hour first), and explicitly contrasts itself with the sibling get_gpu_prices. An agent can distinguish this from every other search/pricing sibling 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?

Explicitly names the trigger condition (user wants a specific machine: GPU model, count, country, price cap) and routes the alternative case to get_gpu_prices. This is textbook when/when-not guidance with a named alternative.

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