readygpu: hardware for local AI

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

Annotations already declare readOnly/idempotent/closed-world, so the remaining burden is light. The description still adds real value by disclosing the ordering rule (best first by largest model that fits fully in memory) and that entries carry prices, letting an agent predict result shape without a 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?

A single dense sentence that front-loads the resource and follows with the ranking rule. Every clause earns its place, though the parenthetical enumeration is slightly redundant with the schema's list description.

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

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

For a two-parameter, fully documented, read-only listing tool with no output schema, the description supplies the one thing the schema cannot: what the returned list contains and how it is ordered. 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 coverage is 100% and the enum plus full list enumeration lives in the schema, so the baseline of 3 applies. The description's parenthetical (all cards, cards under a price, used cards, Macs and mini PCs) loosely mirrors the list values but adds no 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 resource — the ranked 'best for local AI' hardware lists of a market — and defines the ranking criterion (most capable model run fully in memory) plus what's included (prices). It implicitly separates itself from find_hardware/compare_hardware by being curated ranked lists rather than search or comparison, though it never names those siblings.

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: call this to get a curated, price-annotated ranking for a market. There is no explicit statement of when to prefer it over find_hardware or compare_hardware, nor any exclusions or prerequisites.

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

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

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds genuine value by enumerating what the comparison reports (memory, price, models fully in memory, estimated speed per model) — effectively the return shape, since no output schema exists. It does not clarify that speeds are estimates subject to context length, nor how it behaves with unknown slugs.

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 a single dense sentence with the resource front-loaded, which is good. But it is a run-on that packs five concepts into one clause chain, and 'in a market' is a confusing way to say prices are market-specific.

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 does the right thing by listing the reported fields, which is the main completeness requirement here. However, in a six-tool family it omits which sibling supplies the slugs and any note on currency or units for price and speed, leaving the agent to infer call prerequisites.

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 both slugs, the market enum and the context enum are fully documented in the schema. The description only implicitly ties 'in a market' to the market parameter and 'runs fully in memory' to the context parameter, adding no syntax or guidance beyond the schema — baseline 3 applies.

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

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

The description names the resource (graphics cards or machines) and the operation (side-by-side comparison) and lists the compared dimensions, so an agent can tell it apart from find_hardware or hardware_details. It never uses a clean verb like 'compare', and the phrase 'in a market' is ambiguous, but the intent is unmistakable.

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 choose this over hardware_details (single item) or best_hardware (ranking), nor any prerequisite such as needing slugs obtained from find_hardware first. The 'two ... side by side' framing only weakly implies the pairwise use 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 readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds that prices are "today's best price", which signals live/freshly-computed data, but says nothing about result caps (limit max 30), what happens when filters exclude everything, or whether the speed estimate depends on the reference model default.

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

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

Two sentences, front-loaded with what is listed and what comes back, then the filtering/sorting controls. Dense but no filler; the parallel clauses are readable rather than padded.

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 does the necessary work of naming the return columns (memory, bandwidth, price, model-relative speed), which is exactly what an agent needs to judge relevance. The remaining gap is behavioral/positioning detail (how the gpu_card vs machine branches differ in output, and how results are capped) rather than a missing core explanation.

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 44%, so the description must carry weight; it names max_price and min_memory_gb as filters and lists sort modes, which partially compensates. However, it adds no semantics beyond the schema (the sort enum already lists those values, and it even omits "popularity"), and leaves kind, condition, context and limit entirely unaddressed.

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 graphics cards or complete machines") and enumerates the returned attributes (memory, bandwidth, price, estimated speed on a model). It is clear on its own, but never distinguishes itself from close siblings like best_hardware or hardware_for_model, so an agent cannot fully separate the browse case from the recommendation case from the description 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?

"Filter by maximum price and minimum memory; sort by price, speed, value or price per GB" implies a browse-and-filter use case but never says when to choose this over best_hardware or hardware_for_model. The only cross-reference is inside the schema (model slug "from search_models"), not the description, so no explicit alternative routing is provided.

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 read-only, idempotent, closed-world behavior, and the description adds the substantive detail that the result includes every current price (new and used) and per-model memory-fit and speed figures. With no output schema, this disclosure of return content carries real weight; it only stops short of stating price freshness, currency, 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 dense sentence, front-loaded with the resource and then the three things returned. Nothing is wasted, though the trailing 'how fast' is terse enough to be slightly ambiguous about what is being measured.

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

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

With no output schema, the description compensates by describing the returned data (specs, prices, compatibility, speed) and the schema fully covers parameters, while annotations cover the safety profile. 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 100%, so all three parameters (slug provenance, market enum, context-length enum) are already fully documented. The description gestures at 'in a market' and 'at a context length' but adds no syntax, defaults, or constraints beyond what the schema states, so baseline 3 applies.

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

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

The description names a specific resource (one graphics card or machine) and enumerates the payload: specifications, current new and used prices, and which models fit fully in memory plus speed. That is well beyond the title 'Hardware details' and separates it from search-style siblings, though it never names 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?

Usage is only implied: the schema notes the slug comes from find_hardware, so the lookup-after-search flow is inferable, but the description itself says nothing about when to use this versus compare_hardware, best_hardware, or hardware_for_model, and gives no exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond that: results are constrained to hardware that runs the model 'fully in memory', and the output bundles pricing and speed comparisons — a meaningful result-shape disclosure given there is no output 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?

A single sentence with no filler and the subject ('For one model') front-loaded. It is dense to the point of needing a re-read, since three superlative tiers plus prices and speeds are packed 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?

With 3 parameters at full schema coverage and no output schema, the description does the important remaining work of describing the return payload and the 'fully in memory' filter. The one gap is the unresolved interaction between the enumerated context-length outputs and the single context parameter.

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 maps loosely onto the parameters ('in a market' → market, 'at each context length' → context), but 'at each context length' actually sits in tension with the single-value context enum and default of 32768, leaving ambiguity about whether all context lengths or just the selected one are returned.

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 (hardware for ONE model) and enumerates what is returned: memory required at each context length, plus the cheapest, best-value and fastest hardware with prices and speeds. That is far more specific than the title. It stops short of distinguishing itself from siblings like best_hardware, find_hardware or hardware_details, so an agent cannot fully rule those out from the description 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?

The phrase 'For one model' implies a single-model scope, but there is no explicit when-to-use, when-not-to-use, or named alternative among best_hardware, compare_hardware, find_hardware and hardware_details. The only routing hint (obtain the slug from search_models) lives in the schema, not the description.

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 read-only, idempotent, closed-world behavior, so the description's job is to add return-shape and workflow context — which it does by listing slug, size, context length and licence and explaining the slug handoff. It does not disclose the limit/default or any ranking or pagination behavior, leaving a minor 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?

Two tight sentences: the first defines what it searches and what it returns, the second routes to the follow-up tool. Every clause carries information and the key scope 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?

With no output schema, the description appropriately summarizes return fields, and annotations cover the safety profile, so an agent has nearly everything needed. The unexplained limit/default and lack of ordering or pagination detail are the remaining, modest omissions.

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 33% (query alone is documented), so the description needs to compensate. It clarifies that matching is by name or task and lists the task vocabulary, but the enum values are already in the schema and it never explains the limit parameter or its default. 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 ('Find open-weight AI models') and enumerates the task categories it matches on. The hardware-oriented siblings make the resource distinction obvious, and naming hardware_for_model ties it into the surrounding toolset.

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?

Clear context for when to reach for it (looking up models by name or task) and it points to the follow-up call (hardware_for_model with the returned slug). It gives no exclusions or caveats about when another approach is preferable, but no competing model-search sibling exists.

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