Used-Mac market: quality-gated listings with deep links, asking-price stats, trust checks, alerts.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 6 of 6 tools scored.
Each tool targets a distinct function: checking listing trust, creating alerts, fetching price stats, retrieving reports, serial lookup, and searching listings. No overlap.
All tools follow a consistent verb_noun pattern (check, create, get, get, lookup, search) with clear, descriptive names.
6 tools cover the core domain of used Mac market info without being excessive or insufficient.
Covers search, trust check, pricing, reports, serial identification, and alerts. Minor gap: no tool to list or delete alerts, but core workflows are supported.
check_mac_listingCheck a used-Mac listing before trusting itAThe 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.
create_mac_alertCreate a standing used-Mac listing alertAInspectWatch 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.
get_mac_price_statsGet used-Mac price statisticsAWhat 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.
get_mac_reportFetch a verified Macfax reportAA 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.
lookup_mac_serialLook up a Mac serial numberACheck 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.
search_mac_listingsSearch live used-Mac listingsALive 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.