Used-Mac market: quality-gated listings with deep links, asking-price stats, trust checks, alerts.
Scored across 7 tools
Each tool targets a distinct resource or action: searching listings, checking a single listing's trust, creating alerts, pricing stats, serial lookup, report retrieval, and credit balance. Even where check_mac_listing and get_mac_price_stats both reference asking bands, their scopes are clearly listing-specific versus market-wide.
All tool names follow a consistent snake_case verb_noun pattern (check_, create_, get_, lookup_, search_). The verb choice maps predictably to intent, and the mac/macfax prefix is used uniformly across the set.
Seven tools is a tight, purposeful set for a used-Mac market intelligence service. Each tool covers a distinct need without redundancy or bloat.
The set covers the main workflows: search, inspect, alert, price, serial lookup, and fetching a shared report. Minor gaps exist, such as no programmatic alert management and no way to retrieve a full report directly by serial, but these are not core dead ends.
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 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.
Check a Mac serial number: whether a verified Macfax report exists for it, plus the model and year decoded from Apple's data for pre-2021 serials. 2021+ Macs have 10-character randomized serials that encode nothing, so for those the honest answer is the format check and the report cross-reference. 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 alphanumeric characters on 2021+ Macs, 11-12 on older ones. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior. The description adds further context: it only decodes pre-2021 serials, cannot verify condition or Activation Lock, and is advisory only. 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 extremely concise (two sentences) yet packed with essential information. The first sentence front-loads the main action and outputs; the second covers limitations. Every word 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?
Given the tool's simplicity (one parameter, no output schema, comprehensive annotations), the description is complete. It covers what it returns, format expectations, and what it cannot do, leaving no major gaps for an agent to misinterpret.
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's parameter description already explains the serial format. However, the tool description elaborates on the character length differences (10 for 2021+, 11-12 for older), adding useful context beyond the schema. Schema coverage is 100%, so the description adds incremental value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks a Mac serial number for an existing Macfax report and decodes model/year for pre-2021 serials. It also specifies what it does not do (verify condition, Activation Lock, possession), making the purpose very specific and 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?
The description mentions what the tool does and its limitations but provides no explicit guidance on when to use this tool over its siblings (e.g., get_mac_report, check_mac_listing). While it implies use for report existence and serial decoding, it lacks direct comparison or when-not instructions.
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_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.
GDPR-clean secondhand listings and sold comps for resale pricing research. No seller personal data.
Mechanic-grade used-car listing verdicts: risk score, failure points, repair costs, fair price.
Curated, human-reviewed deal feed for AI agents — live deal search + price watches. No auth.
