Wendily MCP server

Connect

ChatGPT

1. Open Wendily in ChatGPT and click Install plugin.
2. Sign in to Wendily when asked, and click Allow.
3. In a new chat, type @Wendily and tell it about your trip.

Claude

1. Open Add custom connector in Claude, which has the name and URL filled in, and click Add.
2. Click Connect, sign in to Wendily when asked, and click Allow.

Claude Code

claude mcp add --transport http wendily https://wendily.com/mcp

Then run /mcp in a session to sign in. To use a key instead:

claude mcp add --transport http wendily https://wendily.com/mcp \
  --header "Authorization: Bearer trips_sk_…"

Other MCP clients

Add the server URL. If your client signs in over OAuth, it finds everything it needs from there, as long as its redirect URI is allowed. Otherwise, create a key on the Connections page and send it as a header. The exact format depends on your client; many use this one:

{
  "mcpServers": {
    "wendily": {
      "url": "https://wendily.com/mcp",
      "headers": {
        "Authorization": "Bearer trips_sk_…"
      }
    }
  }
}

Authentication

Every request except ping needs a credential, and every credential acts for one user. It reaches the MCP server and the REST API and nothing else, and it can read and write that user's own trips and the trips shared with them, with the role they were given. It does not expire. The user can disconnect it at any time on the Connections page, and that takes effect on the next request.

OAuth

The right choice for any client that can open a browser. A request without a credential gets 401 with a pointer to the metadata:

WWW-Authenticate: Bearer realm="wendily", resource_metadata="https://wendily.com/.well-known/oauth-protected-resource/mcp"

• Protected resource metadata (RFC 9728): https://wendily.com/.well-known/oauth-protected-resource/mcp
• Authorization server metadata (RFC 8414): https://wendily.com/.well-known/oauth-authorization-server
• Dynamic client registration (RFC 7591): https://wendily.com/oauth/register, with no approval step
• Authorization code flow with PKCE (S256), as a public client
• The one scope is trips, and there are no refresh tokens

Redirect URIs must be https:// on chatgpt.com, claude.ai, claude.com, agent.meta.ai, muse.ai, or platform.muse.ai, or a loopback address (localhost, 127.0.0.1, [::1]). Custom URL schemes are refused, so a client that needs one should use a key. To support another app, write to team@wendily.com. The full walkthrough, with every request and error, is in auth.md.

Key

For clients without OAuth. The user adds a connection on the Connections page, which shows the key once, and you send it on every request as Authorization: Bearer trips_sk_….

Protocol

• Send each JSON-RPC 2.0 message as a POST to the server URL. The reply is one JSON response. Batches are refused.
• The server is stateless: no session id and no server-to-client stream. GET is not supported.
• Methods: initialize, ping, tools/list, and tools/call. Tools are the only capability.
• Protocol versions: 2025-06-18, 2025-03-26.

curl https://wendily.com/mcp \
  -H "Authorization: Bearer trips_sk_…" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Results and errors

A successful call returns the REST response as text and as structuredContent, so data is under data as it is in the API. An operation with nothing to return, such as a delete, returns the text Done.

• A rejected call (validation, permissions, an archived trip) is a result with isError: true and the text code: message. The model can read it and correct itself. structuredContent holds the REST error.
• A missing path id is also a result with isError: true, naming the argument.
• A missing, malformed, or revoked credential is an HTTP 401 with the WWW-Authenticate header above, never a tool result. Do not retry with the same token. Ask the user to reconnect.
• An unknown tool is JSON-RPC error -32602, and an unknown method is -32601.

Workflow

Clients show their model these instructions when they connect. If you drive the server yourself, follow them too. Calling start_trip before asking anything matters most: the user sees the trip appear in Wendily straight away, rather than nothing for the minutes the conversation takes.

Wendily stores trip itineraries. You write them here as you talk to the user about a trip.

Workflow:
1. Before asking the user anything, check for a trip already in progress: if you know of one from an earlier conversation, or list_trips shows a trip that is still being planned, offer to continue it and use its id instead of starting over.
2. Otherwise call start_trip immediately, before your first reply. It creates a placeholder so the user can see in Wendily that you are working. Pass whatever you already know; nothing is required. Keep the returned id.
3. Ask the user a focused set of questions: destination, dates and flexibility, who is travelling and any practical needs, interests and pace, budget and preferences, anything already booked.
4. When you know the trip, call update_trip with the real title, destination, dates, and a cover image. Then add days with add_day and stops with add_item, including times, descriptions, locations, practical notes, travel between stops, and a photo for each place, activity, and stay when you can find a real one.
5. Keep the itinerary current as the plan changes, and after each meaningful update tell the user briefly what you changed.

Rules:
- Never invent bookings, prices, availability, reservation codes, or image URLs. Use direct links to real, publicly reachable photos, or leave the field out.
- Dates are YYYY-MM-DD; times are HH:MM in the trip's local time.
- Only the trip owner can invite people, and invitations must be accepted by the invitee before they see the trip.

Tools

There are 19 tools, each one REST operation. The arguments are the request body plus the path ids, and tools that change something are marked so that chat apps can ask the user first.tools/list returns the full JSON Schema for each.

Testing

There is no separate sandbox. Trips are private until shared, so test against the live server and archive test trips when you are done.

See also

• API reference: the same operations as REST.
• auth.md: every step of getting a credential.
• llms.txt: what an agent needs to integrate, as plain text.