Used prices for GPUs, CPUs, RAM, consoles, iPhones, MacBooks and more from live eBay listings.
Scored across 7 tools
Most tools have clearly distinct purposes: search, category listing, price lookup, history, deal evaluation, and market movers. The only mild overlap is between get_price and check_price, and between list_categories and list_category, but descriptions clarify the difference.
All names follow a consistent snake_case convention using predictable verb_noun or noun-phrase patterns. The singular/plural distinction between list_category and list_categories is intentional and readable.
Seven tools are well-scoped for a used-tech price lookup server. Each tool covers a distinct workflow such as discovery, current pricing, history, deal checking, and market movement.
The surface covers the core read-only domain comprehensively: search, category browsing, current price, price history, deal evaluation, and market movers. No obvious lifecycle gap exists for a market-data lookup service.
Is this asking price a good deal? Compares a USD price (including shipping) with the current used market for the model.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model id (e.g. rtx-3080) or name (e.g. 'RTX 3080', 'iPhone 15 Pro 128GB') | |
| price | Yes | Asking price in USD incl. shipping |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is known. The description adds that the comparison is against the current used market and that shipping must be included in the price, but it does not describe the returned assessment format, thresholds, or data recency.
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 zero waste. The use-case question is front-loaded and immediately followed by the comparison basis.
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 two-parameter read-only tool with full schema coverage, the essentials are present. Still, with no output schema, the description could say more about what result the agent should expect, such as a deal rating or comparison summary.
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 parameters are already documented. The description reinforces that price is USD including shipping but adds no syntax, format, or interpretation details 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 evaluation task: comparing an asking price (including shipping) against the current used market for a model. This distinguishes it from raw price-getting siblings like get_price and get_price_history, though it does not explicitly name them.
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 framing question 'Is this asking price a good deal?' implies when to use it rather than a sibling. However, there is no explicit when-not-to-use guidance or direct reference to alternatives such as get_price.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current typical used price, fair range, lowest listing, new price, 7/30-day change and 90-day low for one model.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model id (e.g. rtx-3080) or name (e.g. 'RTX 3080', 'iPhone 15 Pro 128GB') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and closed-world scope, so the safety profile is covered. The description's real contribution is disclosing the exact metrics returned (spot, range, low, deltas), which is substantial behavioral context given there is no output schema. It stops short of noting currency, region, or behavior for unknown/unpriced models.
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 primary value (typical used price) and proceeds through the secondary metrics. No filler, though the comma-list style is slightly harder to scan than a short structured clause 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?
With no output schema, the description usefully enumerates the returned fields and the time horizons (7/30-day, 90-day). Gaps remain around currency/region and what happens when a model has no listings, but nothing needed to invoke the tool 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 single `model` parameter already documents accepted forms (id or name with examples). The description only reinforces the single-model scope, adding no format or matching detail beyond the schema; 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 enumerates exactly what is returned (typical used price, fair range, lowest listing, new price, 7/30-day change, 90-day low) for a single model, which makes the resource and scope unambiguous. It doesn't distinguish itself from siblings like check_price or get_price_history, so an agent can't route between them from text 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?
No statement of when to use this versus check_price or get_price_history, and no prerequisites or exclusions. The 'one model' phrasing implies single-item lookup, but that's inference rather than guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily typical used price and fair range for a model. Free: last 30 days; with an Orbit API key: up to 365 days.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days of history (default 30) | |
| model | Yes | Model id (e.g. rtx-3080) or name (e.g. 'RTX 3080', 'iPhone 15 Pro 128GB') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds meaningful behavioral context beyond that: the output granularity (daily typical used price and fair range) and access tiers that limit history to 30 days without an API key and 365 days with one.
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 no waste. The core output is front-loaded, followed by the access constraint, so an agent can parse the key facts immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only tool, the description covers what is returned, the granularity, and the tier-based history limits. Annotations and the schema already handle safety and parameter definitions, so nothing essential 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 the baseline is 3. The description earns an extra point by clarifying that the 'days' parameter is constrained by access tier: 30 days free, up to 365 days with an API key, which is not stated in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and output: daily typical used price and fair range for a model. It is clear what the tool returns but does not explicitly distinguish itself from siblings like get_price or check_price, which likely return current rather than historical pricing.
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 word 'history' and the daily output, but the description never says when to use this tool instead of get_price or check_price. The tier constraints (free 30 days, API key up to 365 days) are useful context, but there are no explicit inclusion or exclusion rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tracked categories and how many models each has.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful detail that each category includes a model count, but says nothing about ordering, aggregation scope, or what 'tracked' means operationally.
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, front-loading the resource and the returned data. It is efficient, though the fragmentary noun-phrase style leaves the action verb implicit.
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-only list tool with no output schema, the description conveys the essential return shape (categories plus counts). The only meaningful gap is the lack of differentiation from the near-identically named sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies since no parameter explanation is needed.
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 phrase 'Tracked categories and how many models each has' identifies the resource and the returned content (model counts), so an agent can infer it lists categories. However, it does not distinguish itself from the sibling 'list_category', which sounds nearly identical, leaving the agent to guess which one to call.
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_category', 'search_models', or any other sibling. The description gives no context, prerequisites, or exclusions — only what the tool returns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current used prices for every tracked model in a category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | gpu, cpu, ram, ssd, monitor, console, phone, laptop, mac, handheld or camera |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that returned prices are 'current' and 'used', which is useful freshness/domain context, but says nothing about ordering, result volume, or empty-category 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 front-loaded sentence with no redundant clauses. It is efficient, though it could have spent a few words on routing guidance instead of stopping after the content statement.
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 one required param, full schema coverage, and no output schema, the description should at least outline the shape of the return. It does so minimally (prices per tracked model in a category), leaving ordering, result size, and empty results 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%, and the enum-style list of valid categories is already given in the schema. The description only mirrors this with 'in a category' and adds no format or constraint detail beyond it, 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 states a specific verb-and-resource outcome: current used prices for every tracked model within a given category. It is distinguishable from siblings like get_price (single model) and list_categories (enumerate categories), though the 'list_' name prefix slightly understates that prices are returned, not just identifiers.
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, and no mention of alternatives such as search_models for filtering or get_price for a single model. The scope ('in a category') implies the use case, but the agent must infer all routing decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Biggest 7-day used price drops and rises.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context the annotations do not carry: the 7-day window, that prices are used-market, and that both decreases and increases are returned. It stops short of saying how many movers come back, whether they are ranked, or how they are scoped to a market.
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 eight-word sentence with the time window and both movement directions front-loaded. Nothing is wasted, and there is no filler to remove.
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 parameterless read with no output schema, the description should still indicate roughly what comes back (e.g. a ranked list of N models with percentage change). It conveys the concept but leaves result size, ordering, and market scope unspecified, which an agent needs to know to trust the output.
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 and the baseline is 4. The description correctly implies a no-argument call, though it could have noted that the result size is fixed and uncontrollable.
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: the top 7-day movers in used prices, in both directions (drops and rises). An agent can tell this is a leaderboard rather than a per-model price lookup, but nothing states how it differs from get_price_history, which could plausibly surface the same movement data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of alternatives such as get_price_history, and no exclusions. The agent must infer the use case purely from the phrase 'biggest 7-day drops and rises'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find tracked models by name or category. Returns ids, names and typical used prices.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Words to match, e.g. 'rtx 40', 'macbook air' | |
| category | No | gpu, cpu, ram, ssd, monitor, console, phone, laptop, mac, handheld or camera |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds value by disclosing the return payload (ids, names, typical used prices), which tells the agent this is a discovery call that returns approximate pricing rather than live quotes. It does not cover match behavior (fuzzy vs exact) or result limits, keeping it below 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?
Two sentences, zero waste: purpose first, return shape second. Nothing could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-optional-parameter read-only search with no output schema, the description covers purpose and return fields adequately. Minor gaps remain around matching behavior and whether empty results are possible, but nothing critical to invoking 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 both parameters are documented with examples and a category list, so the schema carries the load. The description's 'by name or category' restates the filter intent but adds no syntax, combination, or matching-semantics detail beyond the schema — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Find tracked models') and narrows scope to name or category lookup, which separates it in spirit from the price-lookup siblings (get_price, check_price). It stops short of explicitly naming how it differs from those siblings, so an agent still infers the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing 'Find tracked models by name or category' implies a discovery/resolution use case that precedes price lookups, but there is no explicit when-to-use statement, no mention of get_price/check_price as alternatives, and no guidance on whether both filters can be combined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_priceget_priceget_price_historylist_categorieslist_categorymarket_moverssearch_modelsReal eBay sold prices for used GPUs, CPUs, RAM and more in 7 markets, and eBay listing price checks.
Live UK, Germany, Canada and US prices for GPUs and Macs that run open AI models. No sign-up.
Live second-hand price estimates with confidence for AI agents. Cached lookups free.
Live eBay sold comps for AI agents: median sold price, middle range and recent sales for any item.
Add one secure layer between your agents and this server.