Macfax

Create a standing used-Mac listing alert

create_mac_alert

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "email": "<email>",
      "config": "<config>"
    },
    "name": "create_mac_alert"
  }
}

Input Schema

Name	Required	Description
`email`	Yes	The user's own email address, exactly as they gave it. Confirmation is required before anything sends. Never a placeholder or an invented address: those are refused, and the per-caller limit is a few alerts a day.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedInput schema / properties / email / description

Previous value: -"The user's own email address. Confirmation is required before anything sends."New value: +"The user's own email address, exactly as they gave it. Confirmation is required before anything sends. Never a placeholder or an invented address: those are refused, and the per-caller limit is a few alerts a day."

First observedJul 10, 2026

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by disclosing the double-opt-in lifecycle: the first alert per email stays inactive until the owner clicks a confirmation link, nothing sends before that, and every email carries manage/unsubscribe links. Gaps remain: no mention of whether creating alerts consumes Macfax credits (suggested by the get_macfax_credit_balance sibling) or of what happens when the same config is submitted twice, which matters given idempotentHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads what the tool does in one clause, then a labelled CONSENT CONTRACT block for the safety-critical rules. No filler, and the confirmation constraint is repeated only once despite being the most important detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a side-effecting, email-sending tool with no output schema, the description covers consent, confirmation gating, inactivity before confirmation, and unsubscribe mechanics — the essentials. It stops short of stating cost implications or the success return, leaving the agent slightly under-informed about the result of a valid call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema coverage at 57%, three parameters (ram_gb, storage_gb, min_tier) carry no description anywhere, and the description adds no parameter meaning at all — it only restates the email confirmation constraint already present in the email schema field. The min_tier enum values ('listed', 'free', 'premium') are unexplained, as is how min_tier relates to the config key that can itself encode RAM and storage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and effect: Macfax emails the given address when new matching listings appear for a watched configuration. The 'standing' alert framing separates it cleanly from search_mac_listings (one-off search) and check_mac_listing (single listing lookup) without needing the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The consent contract gives explicit when-to-create and when-not-to-create conditions ('only for a user who explicitly asked for this alert on this email address', placeholders refused, per-caller daily limit). It never names the sibling tools as alternatives, so an agent must infer that ad-hoc lookups belong elsewhere.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Macfax tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.