Trunkville MCP server

Overview

Trunkville is the global directory of bespoke makers (tailors, shoemakers, shirtmakers and other artisans) and the trunk shows where they travel to see clients. The MCP server gives an AI assistant the same directory and the same appointment-request flow as the website, as structured tools.

Why use it instead of browsing

• Answers the real question in one call. “Who makes shoes and comes near Chicago, under $2,000?” combines home cities, upcoming dates and past visits; on the site that’s many pages.
• Structured, current data. Dates, cities, venues, prices and open appointment times as JSON, read live from the directory, with each time’s slot_id.
• Past visits. Makers who’ve been to a city in the last two years but have nothing scheduled are included, so an assistant can offer to ask them to come again; the site doesn’t surface this in one place.
• A real request flow, not form-filling. Requests go to the maker with your assistant named, the client gets every update by email, and the assistant can check status or withdraw later.

Request-only by design. Bespoke makers confirm every appointment personally. There is deliberately no “book” tool: nothing is an appointment until the maker accepts.

Endpoint, transport and authentication

• URL: https://www.trunkville.com/api/mcp
• Transport: Streamable HTTP (MCP over HTTP POST, JSON-RPC 2.0).
• Authentication: none. No sign-in, API key or OAuth. Requests act for the client whose name and email the assistant supplies; the status_token returned with each request is the only credential, and only for that request.
• Server name: trunkville. Tools: search_makers, get_maker, list_trunk_shows, request_appointment, ask_maker, get_request, cancel_request.
• The same data is available as a JSON API, described at /openapi.json, and summarised for AI crawlers at /llms.txt.

Setup

Add Trunkville as a remote MCP server in any client that supports Streamable HTTP:

{
  "mcpServers": {
    "trunkville": { "url": "https://www.trunkville.com/api/mcp" }
  }
}

For clients that only speak stdio, use a bridge such as mcp-remote:

{
  "mcpServers": {
    "trunkville": { "command": "npx", "args": ["-y", "mcp-remote", "https://www.trunkville.com/api/mcp"] }
  }
}

To check it from a terminal:

curl -s https://www.trunkville.com/api/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

A good first call is search_makers with a city, then get_maker on a result to see their open times.

Tools

Every tool returns its result as JSON text. Failures set isError: true with { "error": "…" }. Annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) and titles are declared on every tool.

Read tools change nothing. Sensitive write tools email a real maker on the client’s behalf, so an assistant should confirm with the client before calling them. Write changes the client’s own request.

search_makers({ "near": "Chicago", "craft": "shoes", "limit": 1 })
→ { "count": 1, "total": 8,
    "place": { "label": "Chicago", "radius_km": 150, ... },
    "makers": [{ "slug": "catella-shoemaker", "name": "Catella Shoemaker",
      "based_in": "Kettering, England, UK",
      "match": { "summary": "Coming to Chicago 2026-11-05", ... },
      "request_url": "https://trunkville.com/book/catella-shoemaker" }] }

get_maker({ "slug": "trunkville-test-atelier" })
→ { "slug": "trunkville-test-atelier", "name": "Trunkville Test Atelier",
    "open_times": [{ "slot_id": "…", "starts_at": "2027-01-05T10:00:00Z",
                     "ends_at": "2027-01-05T11:00:00Z", "city": "New York", ... }],
    "booking": { "policy": "request_only", ... } }

list_trunk_shows({ "city": "London" })
→ { "count": 1, "shows": [{ "maker": { "slug": "valstar", "name": "Valstar" },
    "city": "London", "venue": "Trunk London",
    "from": "2026-11-05", "to": "2026-11-08", ... }] }

request_appointment({ "maker": "trunkville-test-atelier", "name": "Alex Reviewer",
  "email": "alex@example.com", "commission": "a navy two-piece suit",
  "slot_id": "<slot_id from get_maker>", "agent_name": "Muse" })
→ { "id": "…", "status": "pending", "awaiting": "maker",
    "held_until": "2026-11-05T12:00:00.000Z",
    "thread_url": "https://www.trunkville.com/r/…", "status_token": "…",
    "note": "Nothing is booked until the maker accepts. …" }

ask_maker({ "maker": "trunkville-test-atelier", "name": "Alex Reviewer",
  "email": "alex@example.com", "message": "Do you make double-breasted overcoats?",
  "agent_name": "Muse" })
→ { "id": "…", "kind": "message", "status": "pending", "status_token": "…", ... }

get_request({ "id": "…", "token": "…" })
→ { "status": "pending", "awaiting": "maker",
    "held": { "starts_at": "2027-01-05T10:00:00Z", ... },
    "held_until": "…", "messages": [] }

cancel_request({ "id": "…", "token": "…" })
→ { "id": "…", "status": "withdrawn",
    "note": "Withdrawn. Any held time was released and the maker has been told." }

Request lifecycle

A request (from request_appointment) or message (from ask_maker) has one of these status values:

• pending: open. awaiting says whose move it is: maker (they haven’t answered yet, or the client replied) or client (the maker suggested a time, or asked a question, and the client needs to answer). Questions and replies go back and forth on the thread while it stays pending.
• accepted: the maker accepted, or the client confirmed a time the maker suggested. This is the only state that is an appointment. The client gets a calendar invite and get_request returns the appointment.
• declined: the maker declined (for a message, the maker closed the conversation).
• withdrawn: the client withdrew it, on their request page or with cancel_request.

The status list in the API schema also includes expired, but nothing sets it today: an unanswered request stays pending and only its held time is released (below).

The 72-hour hold

When a request names one of the maker’s open times (slot_id), that time is held for that client so nobody else can take it, for up to 72 hours (held_until). The same applies to a time the maker suggests while it waits for the client. If nobody acts within 72 hours, the time is released back to the maker’s calendar, the client is emailed, and the request stays open so the maker can still answer. Releases are applied when that maker’s times are next loaded. Decline and withdrawal release the hold at once.

Duplicates and idempotency

• A client (by email address) can have at most 3 pending requests or messages with one maker. A fourth is refused with “You already have requests waiting with this maker” (HTTP 429 in the JSON API).
• A held time can only be held once: a second request for the same slot_id is refused with conflict: true.
• request_appointment and ask_maker take no idempotency key: each call creates a new request and sends new emails. Don’t retry a call that returned an id; use get_request to check it. cancel_request is safe to repeat.

Nothing is a booking until it is accepted. Assistants should describe a pending request as a request, never as a confirmed appointment.

Rate limits

These are the limits the server enforces today:

• 3 pending requests per client per maker, as above. This is the only limit that refuses a new request.
• Maker email batching. Requests are never refused because a maker is busy. When a maker gets more than 5 requests in an hour, individual emails pause and they get one summary an hour instead. Past 60 in an hour, they move to a daily summary for the next 24 hours. Answers can take longer as a result.
• Thread messages: 12 messages per hour from each side of one request’s thread; beyond that, sending is refused until the hour passes.
• Message emails to a maker: at most 20 an hour across all their threads. Further messages are saved to the thread but not emailed.
• The read tools have no per-client quota. Please keep automated traffic reasonable and follow the terms for automated access.

Testing

To try the write tools without contacting a real maker, use the test maker trunkville-test-atelier. It is hidden from search_makers, list_trunk_shows and the public directory, but get_maker returns its profile and open times, and request_appointment, ask_maker and cancel_request work on it normally. Its emails go to Trunkville staff, not to a maker. Use a real inbox you control as the client email: receipts and updates are sent to it.

Data handling

• Read tools take no personal information. Beyond our host’s standard request logs (see the Privacy Policy), we keep no record of which assistant called them.
• request_appointment and ask_maker send the client’s name, email, and optional phone and message to the maker, and store them with the request; the maker sees the agent_name too. The client is emailed at every step. Requests and their threads are anonymized 24 months after their last activity.
• Only send a client’s details with their permission. The status_token gives access to that request’s thread: keep it private to the client.
• Full details: Privacy Policy and Terms of Service.

Support

Questions, problems or a maker to add: christian@trunkville.com. Trunkville is operated by Trunkville LLC.