A public Model Context Protocol server that exposes the GetXPersonal directory to AI agents. Connect Claude Desktop, Claude Code, OpenAI ChatGPT, OpenClaw, or any MCP-compatible client over Streamable HTTP — no API key, no SDK, three tools, one endpoint.
A short technical orientation for developers integrating the GetXPersonal directory into agentic workflows.
The Model Context Protocol is an open standard for connecting AI applications to external systems through a uniform interface. An MCP server exposes a fixed set of tools — named, schema-described functions — that any compatible client can discover at runtime and call on behalf of a language model. Specification details are at modelcontextprotocol.io.
This server publishes three tools backed by the live GetXPersonal directory:
GetCities for discovering valid city keys, SearchProfiles for
querying listings by city and category, and GetAdDetails for fetching the
canonical record of a single listing. All tools are read-only. No tool exposed by this
server creates, modifies, or deletes data.
The transport is Streamable HTTP — the modern single-endpoint
replacement for the older HTTP+SSE dual-endpoint design. Requests are JSON-RPC 2.0
over HTTPS POST. Responses are either single JSON objects or SSE event streams,
depending on what the model and tool need. Everything terminates on a single URL:
https://mcp.getxpersonal.com/ads.
There is no authentication. The server is intended to be safe to expose publicly: every tool is read-only, only public listing data is returned, and a 10 requests-per-minute per-IP limit caps abuse. Higher-volume integrations should contact the GetXPersonal team for a dedicated arrangement.
Pick your client and follow the steps. Every client connects to the same endpoint — only the configuration syntax differs.
In Claude Desktop, go to Settings → Developer → Edit Config. This opens claude_desktop_config.json.
Add the following inside the "mcpServers" object:
{
"mcpServers": {
"getxpersonal": {
"type": "streamable-http",
"url": "https://mcp.getxpersonal.com/ads"
}
}
}Save the file and restart Claude Desktop. The GetXPersonal tools will appear in the tools menu.
Open your terminal and run:
claude mcp add getxpersonal \
--transport http \
https://mcp.getxpersonal.com/adsThe tools are immediately available. Verify with:
claude mcp listIn ChatGPT, open Settings → Connected apps → Add MCP server.
https://mcp.getxpersonal.com/adsClick Connect. The GetXPersonal tools will appear when you start a new conversation.
OpenClaw is an open-source local AI assistant that connects to messaging apps like WhatsApp, Telegram, and Discord.
Since the GetXPersonal MCP server uses Streamable HTTP, you can connect it through OpenClaw's
MCP plugin or by configuring it directly in your openclaw.json.
Open your OpenClaw config file at ~/.openclaw/openclaw.json and add a mcpServers entry:
{
"mcpServers": {
"getxpersonal": {
"transport": "streamable-http",
"url": "https://mcp.getxpersonal.com/ads"
}
}
}Restart your OpenClaw gateway so it picks up the new server:
openclaw gateway restartConfirm the server is registered and tools are available:
openclaw mcp listUse the OpenClaw CLI to add the server without editing files directly:
openclaw config set mcpServers.getxpersonal.transport "streamable-http"
openclaw config set mcpServers.getxpersonal.url "https://mcp.getxpersonal.com/ads"Restart the gateway and verify as above.
If you're using the OpenClaw MCP Plugin for Streamable HTTP support, install it into your extensions directory:
cd ~/.openclaw/extensions/
git clone https://github.com/lunarpulse/openclaw-mcp-plugin.git mcp-integration
cd mcp-integration
npm installAdd GetXPersonal to the plugin's config in config/openclaw.plugin.json:
{
"mcpServers": {
"getxpersonal": {
"baseUrl": "https://mcp.getxpersonal.com/ads"
}
}
}Restart the OpenClaw gateway: openclaw gateway restart
Any MCP-compatible client that supports Streamable HTTP transport can connect:
// Generic MCP client configuration
{
"name": "getxpersonal",
"transport": "streamable-http",
"url": "https://mcp.getxpersonal.com/ads"
}No authentication is required. The server is publicly accessible with a rate limit of 10 requests per minute per IP.
If you prefer to call the server without an MCP SDK, send a JSON-RPC 2.0 initialize handshake followed by tools/list and tools/call requests:
curl -X POST https://mcp.getxpersonal.com/ads \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'What actually happens on the wire when an MCP client calls a GetXPersonal tool.
The server speaks the Streamable HTTP variant of the MCP transport, finalized in the
2025-03-26 revision of the specification. A single endpoint — POST /ads —
handles every JSON-RPC method. There is no separate SSE channel and no session-cookie
handshake; the client opens a request, sends its JSON-RPC payload, and reads the response.
The server inspects the Accept header on each request to decide the response
framing. A client that accepts application/json and not text/event-stream
receives a single JSON object. A client that accepts text/event-stream receives
a streamed SSE response — useful when a tool returns large or progressive content.
Either framing is conformant; clients should accept both and let the server choose.
Three JSON-RPC methods matter in normal use. initialize negotiates protocol
version and capabilities and is sent once per session. tools/list returns the
JSON Schema for every exposed tool. tools/call invokes a tool by name with a
JSON arguments object and returns either a content array (success) or a structured error.
All three are documented in the MCP specification.
Errors follow JSON-RPC 2.0 conventions. Tool-level failures — bad arguments, unknown
city key, missing ad ID — return an error object with a structured
message rather than an HTTP non-2xx. Transport-level failures — rate limit exceeded,
malformed JSON, oversized request — return the appropriate HTTP status: 429
when the per-IP limit is hit, 400 for parse errors, 413 for payloads
above 64 KB. Clients should treat 429 as retriable with backoff.
The server does not implement the optional MCP resources or prompts capabilities. It does not support stdio transport, the deprecated HTTP+SSE dual-endpoint transport, or WebSocket framing. It does not issue notifications back to the client. If a future feature requires any of these, this page will be updated.
Three tools, all read-only, all returning JSON. Names are case-sensitive and match the schema returned by tools/list.
SearchProfiles.
City keys are slug-style and stable.
| Parameter | Type | Notes |
|---|---|---|
| pageNumber | integer | 1-based. Defaults to 1. |
| pageSize | integer | Defaults to 50. Max 200. |
| Parameter | Type | Notes |
|---|---|---|
| city req | string | City key from GetCities. |
| category | string | Enum value. See below. |
| pageNumber | integer | 1-based. |
| latitude | number | Optional, sort by distance. |
| longitude | number | Optional, paired with latitude. |
| Parameter | Type | Notes |
|---|---|---|
| adId req | string | Returned by SearchProfiles. |
SearchProfiles
Pass any of these as the category argument. Omit the argument to search across all categories. Values are case-sensitive.
SearchProfiles
{
"jsonrpc": "2.0",
"id": 42,
"method": "tools/call",
"params": {
"name": "SearchProfiles",
"arguments": {
"city": "los-angeles-california",
"category": "activity-partner",
"pageNumber": 1
}
}
}A few concrete patterns where the three-tool surface is enough to power a real workflow.
A chat agent that takes a free-text city name from the user, normalizes it to a key, paginates through listings, and presents the top matches with rich previews.
An assistant given the user's coordinates ranks activity-partner listings by
distance, then enriches the top three with full details for a side-by-side comparison.
A drafting tool fetches the full details of a referenced ad, then helps the user compose a contextual, tone-matched reply based on the listing's actual content.
A research agent walks the city catalog, samples listing volume per category in each metro, and produces a coverage table or a small ranked report on regional activity.
An OpenClaw-powered bot accepts a slash command, calls
SearchProfiles against the user's city, and replies inline with a
short, formatted result list and follow-up commands.
A staff-side agent surfaces recent listings in a given city for human review, highlighting fields that warrant attention and linking back to the canonical page on the main site.
Once a client is connected, these prompts exercise each of the three tools end-to-end.
Because the server is unauthenticated and called by AI agents on behalf of users, it is worth being explicit about the data flow.
Every exposed tool is read-only. Nothing on this server can post, modify, or delete a listing.
The directory data returned is the same data already public on the main site. No private profile fields are surfaced.
The server never sees the user's prompt or the model's reasoning — only the JSON-RPC tool call constructed by the client.
Request metadata (timestamp, IP, tool name, status) is retained for rate limiting and abuse detection. Tool arguments are not persisted.
10 requests per minute per IP, hard. Excess requests return HTTP 429 with a Retry-After header.
Posting, replying, contacting, or messaging through the directory is intentionally not exposed. Those actions remain on the main site behind authentication.
Quick answers to the most common questions about the protocol, the endpoint, and the data.
https://mcp.getxpersonal.com/ads with no authentication. A 10 requests-per-minute rate limit is applied per client IP address. Higher-volume integrations should contact the GetXPersonal team for a dedicated arrangement.
GetCities returns a paginated list of valid city keys. SearchProfiles searches listings by city key, category, and optional latitude/longitude for geo-sorted results. GetAdDetails returns the full record of a single ad by ID, including title, description, image URLs, and the canonical link on the main site.
los-angeles-california) so that ambiguous names — Springfield, Portland, Glendale — resolve deterministically. Always call GetCities first to discover the valid key for the user's intended city, or pass latitude and longitude to let the server pick the nearest one.