Reference

MCP server.

The same MAC/OUI vendor lookup as tools an AI agent can call directly, over Model Context Protocol. Same data, same API key, no separate account.

Endpoint: https://mcp.macadress.com/mcp, Streamable HTTP transport, stateless, no session to manage.

Connecting

Point any MCP-compatible client at the endpoint above and authenticate with the same API key the REST API uses (sign up for one, visible any time on your account page): send it as an Authorization: Bearer header. There's no separate OAuth connect flow: the MCP spec makes authorization optional for HTTP transports, and a bearer token is spec-legal without running a full OAuth 2.1 authorization server. If your client supports a raw JSON config, this is the shape most expect:

{
  "mcpServers": {
    "macadress": {
      "url": "https://mcp.macadress.com/mcp",
      "headers": { "Authorization": "Bearer mk_your_api_key" }
    }
  }
}

Tools

Tool	What it does	Counts against quota
`lookup_mac`	Look up a single MAC address or OUI: vendor, IEEE assignment type, block range, address capacity, country, transmission/administration type, randomization indicators, derived EUI-64/IPv6 link-local, and everything else the REST API returns.	Yes, 1 per call
`batch_lookup_mac`	Same, for up to 100 addresses in one call.	Yes, per address resolved
`search_vendors`	Search the registered vendor/block directory by organization name substring and/or ISO 3166-1 alpha-2 country code.	Yes, 1 per call
`get_vendor_block`	Full detail on one registered block by its ID, including other blocks registered to the same organization.	Yes, 1 per call

Every tool call is authenticated and billable; there's no free tier of tools here the way /v1/healthz is free on the REST API.

Quota and rate limits

Enforced against the same per-plan numbers as the REST API (see pricing and the API docs' rate-limit/quota sections). A key's monthly lookup budget and requests-per-minute cap are shared concepts across both surfaces, even though each runs as its own process and converges its usage count independently rather than sharing one live counter.

Why no OAuth

MCP's authorization spec is optional for HTTP transports, not required. Implementing it (PKCE, dynamic client registration, a resource-metadata endpoint) buys one-click "connect your account" provisioning in clients that support it, at the cost of running a real authorization server. Pasting an existing API key works today in every MCP client we're aware of and is exactly as secure as the header the REST API already accepts.