Showcase IDX MCP Roadmap: V1, V2, V3

This is the third note in our Showcase IDX MCP series, after how we are approaching it and what Showcase exposes. It is a status report written while we build, and we will update it as things change.

Disclosure: IDX Webmasters is the IDX division of Virtual Results, which builds this MCP. Showcase IDX is a trademark of its owner. This is an independent project, and nothing here implies that Showcase IDX endorses or sponsors this MCP.

Access state: in development. The code is on a development branch and is not deployed. Nothing connects to a Showcase account today. The planned address is https://showcase.virtualresultsplatform.com/mcp, and it is planned, not live. We have not yet created its connector.

The three versions at a glance

• V1, webhook leg (built on a development branch, not deployed): a private webhook receiver, a settings page that creates your webhook address, and read tools.
• V1, login leg (partly built, unofficial, no tools yet): the form and sign-in code are on the development branch, switched off by default. A live check and a terms review come first, and V1 ships without this leg if the check fails or it is not permitted.
• V2 (planned): approval-gated writes, new-lead alerts, and the connection address https://showcase.virtualresultsplatform.com/mcp with the 11 WordPress tools.
• V3 (planned): staff tools for Virtual Results' own clients, only through an API Showcase grants us.

These are in the order we expect to tackle them, not dates. Later versions depend on answers we do not have yet.

What V1 contains

The webhook leg (built). Showcase's documented outbound hooks send new leads and messages to us:

• A private address with a long random token in it. The token is the only credential on that path, so treat it like a password. We store only a hash of it.
• A wrong token gets a bare 404, and the receiver is rate limited.
• Received lead events are stored encrypted. In our current build they are kept for 90 days, with a cap of 500 per workspace.
• The settings page creates and shows your private webhook address, ready to paste into Zapier or Showcase.
• Five read tools: showcase_account_status, showcase_lead_inbox, showcase_hot_leads, showcase_get_lead and showcase_settings_link.
• Billing is built in at price 0, so usage is metered and free during testing.

We do not yet know Showcase's real payloads, because Showcase documents none. Our parser matches field names loosely (name, email, phone, message, listing, source, lead id) and falls back to scanning Slack-style text for an email address and a phone number. Those field names are assumptions until we see real payloads from a test account.

The login leg (partly built, unofficial). An agent would enter their own Showcase email and password on the settings page, never in chat. Lead lookup, saved searches, hot sheets and tags would then be read through the dashboard's internal API, the way the browser does. It may break, and we have not confirmed that Showcase's terms allow it. What we have verified so far is only route names and the cookie-and-token session style from Showcase's public dashboard JavaScript. We do not know request and response shapes. The form and sign-in code are on the development branch, switched off by default, and no tools use them yet. A live check and a terms review come first. V1 ships without this leg if the check fails or it is not permitted. Any stored password will be encrypted, and the leg will be rate limited.

Also in the connection: our 11 WordPress tools, so an assistant can draft a post on your own site from what it found. Billing is built in and is currently free during testing.

What V2 and V3 would add

V2 (planned). Writes behind an approval step: notes, tags and creating a lead. Creating a lead in Showcase emails that lead, so we will test it only with test addresses. Also new-lead alerts, and the connection at https://showcase.virtualresultsplatform.com/mcp, which is planned, not live, with the 11 WordPress tools.

V3 (planned). Staff tools for Virtual Results' own clients, only through an API Showcase grants us. Our request to Showcase is drafted and has not been sent.

What we will not do

• Write to real clients' accounts while testing.
• Send notifications to real leads.
• Store anyone's password unencrypted.
• Use reseller impersonation tokens.
• Create, edit or delete leads through the webhook path. Showcase has no inbound API for it.
• Claim an official Showcase API, or a partnership.

What we are working through

• Real payloads. We need to see what Showcase actually sends before we can document it.
• The unofficial leg. Whether it works, and whether it is acceptable to use at all.
• A partner API. We intend to ask Showcase about their partner program. That request is a draft and has not been sent.
• A test account. Showcase offers demo data, and we need a safe way to test without notifying real leads.

How to test it

Nothing is open yet, so here is how to get involved now:

1. Join the early-access list and tell us which Showcase plan you are on and what you want the assistant to do.
2. If you can, tell us whether you use the Zapier or the Slack integration today. Both are candidates for the inbox.
3. When a build is ready to test, you will connect your own account. We will never ask you to email credentials.

What would make this easier

A documented Showcase partner API with a key model, a sandbox, rate limits and documented webhook payloads would replace the unofficial leg. If you have a contact at Showcase, an introduction would help.

Feedback wanted

Which tools would you use first: the lead inbox, hot leads, follow-up drafts, or something we have not listed? What did we get wrong? Use the early-access form, read the Showcase page, or browse the journal.