Skip to main content
Glama

Look up an Apple serial number

lookup_mac_serial
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
serialYesThe device's serial number: 10 characters on 2021+ devices (a letter first, never a vowel), 11-12 on older ones.
contextNoOptional. 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / context
      Added 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"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / serial / description
      Previous 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."
  3. Changed1 schema field changed
    • changedInput schema / properties / serial / description
      Previous 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."
  4. Changed1 schema field changed
    • changedInput schema / properties / serial / description
      Previous 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."
  5. First observed

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.