Identify any Apple serial and read its device record, plus used-Mac prices, listings and checks.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 8 tools
Most tools target clearly distinct objects: a single listing (check_mac_listing), a search (search_mac_listings), a report (get_mac_report), a serial (lookup_mac_serial), alerts, and credits. The main overlap is between get_mac_market_value and get_mac_price_stats, which both price a Mac and differ mainly by input (model name vs configuration) and output slicing, creating some misselection risk.
Every tool follows a clean verb_noun snake_case pattern (check_mac_listing, create_mac_alert, get_mac_market_value, lookup_mac_serial, search_mac_listings, etc.). The get_ prefix dominates for retrieval while check_, create_, lookup_, and search_ are used precisely where they add meaning, with no style mixing.
Eight tools is well-scoped for a used-Mac market-data service, with each tool earning its place across search, listing verification, pricing, serial resolution, reports, alerts, and credits. Nothing feels redundant or padded.
The surface covers the core lifecycle: search listings, check a single listing, price a Mac, resolve a serial, fetch a report, and create alerts, plus credit accounting. The notable gap is alert management (only create_mac_alert exists; listing/deleting/updating alerts relies on emailed links rather than API operations).
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 credits this API key has left, and what costs one. One credit answers one distinct serial, any Apple device and any year, and the same serial again within 24 hours is free. Answers that come back retry or unsupported, and every other tool, are free. Without credits, a free key gets 25 brand new 2021+ resolutions and 200 distinct serials a day. 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?
Annotations only declare the safe-read profile (readOnly, idempotent, non-destructive). The description adds substantial behavioral context the annotations cannot convey: credit consumption rules, the 24-hour same-serial dedup, free retries, free-tier daily limits (25 resolutions / 200 serials), and anonymous-allowance fallback 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?
The leading sentence answers the core question, but the middle is a dense run-on chain of credit rules that requires careful parsing, and the final two sentences both cover fallback/allowance behavior. Information-dense but not cleanly structured; some clauses earn their place, others could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden, and it does describe what is reported (credits remaining, cost per credit, anonymous allowance when keyless). It stops short of naming the response fields, but an agent has enough to call and interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description sensibly does not attempt to explain parameters and instead spends its words on output meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific resource (credit balance for this API key) and adds what a credit costs, which is the core question an agent has. It is clearly distinguishable from all siblings (lookup_mac_serial, get_mac_report, etc.), which the description notes are free.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance: 'Call this before a large batch of serials to find out whether it can be finished.' It also clarifies that every other tool and retry/unsupported answers are free, which implicitly tells the agent not to call this for cost estimation elsewhere. No explicit exclusion beyond that.
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, iPad or iPhone serial number to its exact model, including 2021+ randomized serials whose characters encode nothing (so no character-decoder can read them). status says what came back: resolved, unknown_serial (no such serial; check it), unsupported (a real device whose model cannot be identified yet), or retry (temporary, never charged). device_type is Apple's device class (Mac laptops, Mac desktops, iPad, iPhone). Also returns the device's record on Macfax: the month it was first seen, how often it has been looked up (first time, 2 to 5, or 6 or more), from how many countries in 30 days, and any listing, verified report or sanitization record on file. For a Mac, also returns what that model is worth (the market block: sale estimate and asking band per configuration). Lookup is advisory and cannot verify condition, Activation Lock, or possession; a Macfax report can. With credits, one credit answers one distinct serial, any Apple device and any year, and the same serial again within 24 hours is free.
| Name | Required | Description | Default |
|---|---|---|---|
| serial | Yes | The device's serial number: 10 characters on 2021+ devices (a letter first, never a vowel), 11-12 on older ones. | |
| context | No | Optional. Why the serial is being looked up: inventory (counting devices an organization holds), intake (devices arriving for refurbishment, trade-in or repair), resale (pricing or listing one to sell), buyer (checking one before buying), support, or other. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), and the description goes well beyond them: it enumerates the status outcomes (resolved, unknown_serial, unsupported, retry) and states retry is 'never charged', plus the credit model (one credit per distinct serial, same serial free within 24h) and the advisory limitation. This is exactly the kind of cost/limitation context an agent needs.
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?
Front-loads the core purpose and the differentiator (randomized serials), then layers return semantics and cost. Dense and mostly earned, though the middle sentences about Macfax record fields are long and slightly packed.
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 must carry the return contract — and it does: status enum semantics, device_type, Macfax record fields, market block for Macs, and credit behavior. An agent knows what comes back and what it means.
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 both parameters (serial format, context enum meanings) are already fully documented in the schema. The description adds no additional parameter-level detail, so the 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?
States a specific verb+resource ('Resolve a ... serial number to its exact model') and immediately differentiates itself by handling 2021+ randomized serials that character decoders cannot read. This scope is distinct from siblings like check_mac_listing or get_mac_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?
Clearly frames the tool as advisory and names the alternative path ('a Macfax report can' verify condition, Activation Lock, possession), routing the agent to get_mac_report. It also gives the credit/caching conditions for repeated lookups. No explicit exclusion list, but the when-to-use context is clear.
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.
lookup_mac_serial1 field changedInput schema / properties / contextAdded value: +{
+ "description": "Optional. Why the serial is being looked up: inventory (counting devices an organization holds), intake (devices arriving for refurbishment, trade-in or repair), resale (pricing or listing one to sell), buyer (checking one before buying), support, or other.",
+ "enum": [
+ "inventory",
+ "intake",
+ "resale",
+ "buyer",
+ "support",
+ "other"
+ ],
+ "type": "string"
+}lookup_mac_serial1 field changedInput schema / properties / serial / descriptionPrevious value: -"The Mac's serial number: 10 characters on 2021+ Macs (a letter first, never a vowel), 11-12 on older ones."New value: +"The device's serial number: 10 characters on 2021+ devices (a letter first, never a vowel), 11-12 on older ones."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_listingsRead products, sales, subscribers and offer codes; verify, enable and disable product licenses.
Know what anything is worth new, used, or resale, and get links to the best place to buy or sell it. Just name it or snap a photo.
Authenticated GPU/CPU/PSU lookup; beta power-budget estimate. Coverage/freshness vary by source.
Live second-hand price estimates with confidence for AI agents. Cached lookups free.
Add one secure layer between your agents and this server.
