Used-Mac market: quality-gated listings with deep links, asking-price stats, trust checks, alerts.
Scored across 8 tools
Most tools have clearly distinct purposes: listing checks, alerts, credit balance, market value, price stats, reports, serial lookup, and listing search. The only potential confusion is between get_mac_market_value and get_mac_price_stats, which both deal with pricing, but their descriptions clarify that one is for model-name-based estimates and the other for configuration-level sold/asking stats.
Tool names follow a consistent verb_noun pattern: check_, create_, get_, lookup_, search_. The verbs are varied but each maps to a distinct action type. Minor inconsistency: create_mac_alert uses 'create' while others use 'get'/'lookup'/'search'/'check', but the pattern is still predictable and readable.
8 tools is well-scoped for a Mac-specific market intelligence server. Each tool covers a distinct function: listing verification, alerting, credit management, valuation, pricing stats, report retrieval, serial resolution, and listing search. No tool feels redundant or unnecessary.
The surface covers the core workflow: search listings, check a listing, look up a serial, get pricing, create alerts, and fetch verified reports. Minor gaps: there's no tool to create or manage Macfax reports directly, and no way to manage/delete alerts beyond the email links, but these are likely external actions.
The trust picture for one specific listing, by URL (eBay/Craigslist/OfferUp/Swappa/Facebook/Reddit) or Macfax listing id: whether Macfax knows it, whether it still passes every quality gate, scam/junk/classified/auction flags, when a scan last verified it live, its ask against the configuration's typical asking band, the platform's own seller-reputation figures where the marketplace has them (seller_signals: eBay feedback, Swappa rating; null elsewhere), and whether a verified Macfax report is attached. Facts, not verdicts.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | A Macfax listing id (from search results). | |
| url | No | The listing's URL on the source marketplace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds rich behavioral context: returns facts not verdicts, lists specific data fields (trust flags, price band, seller reputation), and clarifies it does not modify data. No contradictions.
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 purpose. Every part adds value: supported platforms, returned data types, and the note about facts vs. verdicts. No wasted words.
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, but the description thoroughly explains what the tool returns: trust signals, price band, seller reputation, etc. This is sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds value by specifying acceptable URL formats (eBay/Craigslist/etc.) and clarifying that 'id' comes from search results, providing context 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?
The description clearly states it checks a specific listing for trustworthiness, listing supported platforms (eBay/Craigslist/etc.) and data returned. It distinguishes from sibling tools like search_mac_listings (which searches) and get_mac_report (which gets a report).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when evaluating a specific listing but does not explicitly state when to use this tool vs. alternatives like search_mac_listings or get_mac_price_stats. No 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Watch the market for a configuration: Macfax emails the given address when new matching listings appear. CONSENT CONTRACT: create an alert only for a user who explicitly asked for this alert on this email address. The first alert for a new email stays inactive until the email's owner clicks the confirmation link Macfax sends; nothing is emailed before that, and every alert email carries manage and unsubscribe links.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The user's own email address. Confirmation is required before anything sends. | ||
| config | Yes | Macfax config key: family[-screen]-chip-year, optionally -RAMgb-STORAGEgb. Examples: macbook-pro-14-m3pro-2023, mac-studio-m2ultra-2023-192gb-1024gb. | |
| ram_gb | No | ||
| min_tier | No | ||
| storage_gb | No | ||
| max_price_usd | No | Only alert under this asking price. | |
| under_typical | No | Only listings under the configuration's typical asking range. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing the consent contract, confirmation requirement, and that alerts carry manage/unsubscribe links. This provides rich behavioral context that annotations alone (readOnlyHint: false, destructiveHint: false) do not cover.
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 three sentences, front-loaded with the core purpose, and every sentence adds value. No filler or redundancy.
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 description explains the key behavioral aspects (confirmation, consent) and how the tool works. However, without an output schema, the agent might wonder about return values. The description is nearly complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 57%, but the description adds minimal meaning beyond the schema. It does not clarify the uncovered parameters (e.g., ram_gb, min_tier, storage_gb) or provide additional context for the described ones. The description fails to compensate for missing parameter explanations.
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 clearly states the tool watches the market for a configuration and emails the address when new matching listings appear. The title also says 'Create a standing used-Mac listing alert', making the verb and resource unambiguous. The purpose is distinct from siblings that search, check, or retrieve reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating alerts but does not explicitly contrast with sibling tools (e.g., search_mac_listings). It provides context about consent and confirmation but no guidance on when to use this versus other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many serial resolutions this API key has left, and what actually costs a credit. Only a brand new resolution is billed: a 2021+ (10 character) serial Macfax has never resolved and that this key has not looked up in the last 24 hours. Cached serials, pre-2021 serials, repeats within 24 hours and every other tool are free at every tier. Call this before a large batch of serials to find out whether it can be finished. Without a key it reports the anonymous allowance instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses the exact billing rule (2021+ serial, never resolved, not looked up in 24h), free categories, and anonymous allowance fallback, giving full behavioral transparency.
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 sentences pack essential information: credit count, billing rule, usage advice, and anonymous fallback. No redundancy, but slightly longer than necessary; still well-structured and 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?
Given zero params and no output schema, the description provides sufficient context on output (remaining credits), when to use, and edge cases (anonymous allowance). The credit policy detail makes it fully self-contained for an agent.
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?
Tool has no parameters; schema coverage is 100% vacuous. Baseline of 4 is appropriate, and description adds context about API key vs anonymous allowance, though no parameter syntax 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 description clearly states the tool reports remaining serial resolutions for the API key and explains what constitutes a billable resolution, distinguishing it from sibling lookup and listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call before a large batch of serials to determine feasibility, and clarifies that other tools are free, implying no need for credit checks elsewhere. Does not name specific alternatives but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a used Mac is worth, from the name Apple gives the model, e.g. "MacBook Pro (14-inch, 2021)" or "MacBook Air (13-inch, M4, 2025)". Returns every Apple Silicon configuration the name can mean, each with its sale estimate (verified sales, or the asking band scaled by a measured clearance ratio; basis labeled) and its live asking band, plus an estimate across them: a single mid when the name pins one configuration, a low-to-high range when Apple's name leaves the chip open. Apple Silicon Macs only. Use the sale estimate as the price of the Mac; asking is seller guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | The Mac's model name as Apple writes it, with a chip or a year: "MacBook Pro (14-inch, M3 Pro or M3 Max, Nov 2023)", "Mac mini (2023) with M2 Pro", "iMac (24-inch, M1, 2021)". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds substantial behavioral detail: how sale estimates are derived ('verified sales, or the asking band scaled by a measured clearance ratio; basis labeled'), that multiple configurations may be returned, and how the aggregate estimate collapses to a single mid or a low-to-high range depending on ambiguity. This goes well beyond the annotation scaffolding.
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 dense but every sentence earns its place: purpose, examples, return contents, estimate methodology, ambiguity handling, and usage guidance. It is front-loaded with the core 'what a used Mac is worth' statement and then layers in necessary detail without fluff.
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, so the description carries the full burden of explaining return values. It does so thoroughly: configurations, sale estimate with basis, live asking band, aggregate single-mid vs low-to-high range, and the sale-vs-asking distinction. Nothing needed to call or interpret the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single model parameter at 100% coverage, including format and examples. The description contributes further example strings and notes that Apple's name may leave the chip open, but this is incremental rather than essential, so the baseline score of 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 opens with 'What a used Mac is worth, from the name Apple gives the model' and then specifies exactly what is returned: configurations, sale estimates, and asking bands. It clearly identifies the resource (Mac market value) and the verb (get/return), and the Apple Silicon scope helps separate it from sibling tools like lookup_mac_serial and check_mac_listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use context by limiting the tool to 'Apple Silicon Macs only' and instructs the agent to 'Use the sale estimate as the price of the Mac; asking is seller guidance.' It does not explicitly name alternative tools or contrast with siblings, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a used Mac configuration actually sells for AND what sellers are asking right now. The sold slice is the headline: verified-sale percentiles when the config has enough recent sales (sold.basis 'direct'; n and window ride along), else the asking band scaled by a measured clearance ratio (sold.basis 'calibrated', ratio disclosed). The asking band (median/p25/p75 with sample size), per-channel medians with net-to-seller after fees, launch MSRP retention and Apple trade-in floor ride along as seller guidance. Use the sold estimate as the price of the Mac; use asking to set a list price. The slices are separate and never blended — preserve the basis label when quoting.
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes | Macfax config key: family[-screen]-chip-year, optionally -RAMgb-STORAGEgb. Examples: macbook-pro-14-m3pro-2023, mac-studio-m2ultra-2023-192gb-1024gb. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations (readOnlyHint, idempotentHint, destructiveHint) by explaining the logic behind sold estimate calculation (direct vs. calibrated with ratio disclosure), the composition of the asking band, and additional accompanying data like per-channel medians and MSRP retention. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and front-loaded with the key purpose, then delves into details. While somewhat lengthy, every sentence contributes meaning. It is well-structured for an AI agent to parse, though slightly verbose.
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?
Without an output schema, the description fully covers what the tool returns: sold estimate with basis indicator, asking band with percentiles and sample size, per-channel medians, MSRP retention, and trade-in floor. This is comprehensive for a price statistics tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single config parameter. The description adds value by providing concrete examples of valid config keys (e.g., macbook-pro-14-m3pro-2023), which helps the agent understand the format beyond the schema text.
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 clearly states the tool provides two distinct slices: what a used Mac actually sells for (sold) and what sellers are asking (asking). It uses specific terminology like 'verified-sale percentiles' and 'calibrated ratio', and the purpose is well-differentiated from sibling tools like check_mac_listing or search_mac_listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use the sold estimate as the price and asking to set a list price, and warns not to blend slices. However, it does not explicitly state when not to use this tool or mention alternative tools, but the context of price statistics is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A verified Macfax condition report as structured data: hardware-verified identity, Activation Lock / MDM / serial-match checks, coverage status, and the signing chain. Use when a listing or seller shares a macfax.com/r/ link and the buyer wants the facts behind it. status "superseded" means the same Mac was re-verified more recently under a newer report; treat the payload as historical state, not current.
| Name | Required | Description | Default |
|---|---|---|---|
| report_id | Yes | The 8-character report id from a macfax.com/r/<id> URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already disclose no side effects. Description adds value by explaining return format (structured data) and status interpretation ('superseded' means historical state). No contradictions.
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: first states purpose concisely, second provides usage guidance and status interpretation. No wasted words; front-loaded with key 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?
Given one parameter, no output schema, and annotations covering safety, the description fully explains purpose, usage, and status meaning. Nothing missing for an agent to select and invoke 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?
Only one parameter (report_id) with schema description already clear ('8-character report id'). Description doesn't add new info beyond schema, but schema coverage is 100%, 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?
Description clearly states the tool fetches a verified Macfax condition report as structured data, listing specific components (hardware identity, Activation Lock, MDM, serial-match, coverage, signing chain). It distinguishes from siblings by focusing on a specific macfax.com/r/ link.
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: when a listing or seller shares a macfax.com/r/ link and the buyer wants facts. Also explains meaning of 'superseded' status. No explicit when-not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a Mac serial number to its exact model, including 2021+ randomized serials whose characters encode nothing (so no character-decoder can read them). Also returns what that model is worth (the market block: sale estimate and asking band per configuration) and whether a verified Macfax report exists for the serial. Lookup is advisory and cannot verify condition, Activation Lock, or possession; a Macfax report can.
| Name | Required | Description | Default |
|---|---|---|---|
| serial | Yes | The Mac's serial number: 10 characters on 2021+ Macs (a letter first, never a vowel), 11-12 on older ones. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it explains that 2021+ serials are randomized and cannot be decoded, that the lookup is advisory, and that it cannot verify condition, Activation Lock, or possession. This goes beyond the annotations and helps the agent set expectations.
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 compact and front-loaded: it states the core purpose first, then the key nuance about randomized serials, then the return value, then limitations. Every sentence earns its place, and the structure is easy to scan.
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-only lookup with no output schema, the description is quite complete. It covers what the tool returns (model, market block, Macfax report existence), the serial format, and limitations. The only minor gap is not explicitly naming sibling tools for alternative actions (e.g., get_mac_report for verification), but the context signals and the description's mention of Macfax reports make the intended use clear.
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 schema already documents the 'serial' parameter well. The description adds meaningful context about the serial format (10 characters on 2021+ Macs, letter first never a vowel; 11-12 on older ones) and the significance of randomized serials. This enriches the parameter semantics beyond the schema's basic type/description.
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 clearly states the tool's function: resolving a Mac serial number to its exact model, including the 2021+ randomized serials. It also distinguishes itself from sibling tools by mentioning what it returns (model, market block, Macfax report existence) and what it cannot do (verify condition, Activation Lock, possession).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (to resolve a serial to model and market value) and explicitly notes limitations (advisory, cannot verify condition/Activation Lock/possession). It doesn't explicitly name alternative sibling tools, but the context signals and the mention of Macfax report existence imply when a Macfax report would be needed. Slight gap: no explicit 'use get_mac_report instead for verification' routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live used-Mac listings aggregated across eBay, Craigslist, OfferUp, Swappa, Facebook and Reddit, with scam clusters, junk titles, classified-ad bait, auctions and stale/sold rows already filtered out. Every result deep-links to the source listing where the purchase happens. Filter by configuration, family, chip, RAM, storage, price ceiling, and verified-report tier.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| year | No | ||
| limit | No | ||
| config | No | Macfax config key: family[-screen]-chip-year, optionally -RAMgb-STORAGEgb. Examples: macbook-pro-14-m3pro-2023, mac-studio-m2ultra-2023-192gb-1024gb. The year may be omitted when the rest pins one build: mac-studio-m3ultra resolves to mac-studio-m3ultra-2025. | |
| family | No | Coarse browse by product family. | |
| ram_gb | No | ||
| min_tier | No | free/premium = only listings with a verified Macfax report attached. | |
| chip_tier | No | e.g. m3, m3pro, m4max, m3ultra | |
| storage_gb | No | ||
| max_price_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral traits: the listings are pre-filtered to remove scams, junk, auctions, and stale listings, and results deep-link to the source. This complements the readOnlyHint and idempotentHint annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and efficiently conveys the tool's purpose, data sources, filtering, and behavior. Every phrase adds value, no redundancy.
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 description contextualizes the tool's purpose, sources, filtering, and that results are cleaned and deep-linked. For a search tool with many filters, this is fairly complete. However, it lacks details on pagination (limit parameter) and the sort parameter behavior.
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 description explains that you can filter by configuration, family, chip, RAM, storage, price ceiling, and verified-report tier, which adds semantic meaning beyond the schema's type definitions. It does not explicitly mention sort, year, or limit, but these are standard parameters. The config parameter description in the schema is already detailed with examples.
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 clearly states the tool searches for live used-Mac listings from multiple marketplaces, with pre-filtered clean data. It mentions filtering options and distinguishes from siblings like check_mac_listing (single listing) and get_mac_price_stats (statistics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding used Mac listings with various filters, but does not explicitly state when to use this tool over siblings like check_mac_listing or get_mac_report. No when-not-to-use guidance is provided.
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.
get_mac_market_valuelookup_mac_serial1 field changedInput schema / properties / serial / descriptionPrevious value: -"The Mac's serial number: 10 alphanumeric characters on 2021+ Macs, 11-12 on older ones."New value: +"The Mac's serial number: 10 characters on 2021+ Macs (a letter first, never a vowel), 11-12 on older ones."get_macfax_credit_balancesearch_mac_listings1 field changedInput schema / properties / config / descriptionPrevious value: -"Macfax config key: family[-screen]-chip-year, optionally -RAMgb-STORAGEgb. Examples: macbook-pro-14-m3pro-2023, mac-studio-m2ultra-2023-192gb-1024gb."New value: +"Macfax config key: family[-screen]-chip-year, optionally -RAMgb-STORAGEgb. Examples: macbook-pro-14-m3pro-2023, mac-studio-m2ultra-2023-192gb-1024gb. The year may be omitted when the rest pins one build: mac-studio-m3ultra resolves to mac-studio-m3ultra-2025."lookup_mac_serial1 field changedInput schema / properties / serial / descriptionPrevious value: -"The Mac's serial number (11-12 alphanumeric characters)."New value: +"The Mac's serial number: 10 alphanumeric characters on 2021+ Macs, 11-12 on older ones."check_mac_listingcreate_mac_alertget_mac_price_statsget_mac_reportlookup_mac_serialsearch_mac_listingsLive eBay market intelligence: underpriced listing scans, price distributions, flip margins.
Live second-hand price estimates with confidence for AI agents. Cached lookups free.
Search Facebook Marketplace, inspect listings and analyze deals. Paid Spottable Pro/Max required.
GDPR-clean secondhand listings and sold comps for resale pricing research. No seller personal data.
Add one secure layer between your agents and this server.
