Post

Spent the weekend adding DCR and CIMD support to our MCP server, to remove friction. It’s been hard, even with the help of Claude

4/10/26, 5:33 pm0 reposts5 likes

Axialis

@axialis.com

Have you found MCP clients consistent about CIMD discovery, or are you still maintaining DCR fallbacks for hosts with partial support?

Pachi

@facilethings.com

Claude uses CIMD consistently. We use DCR as a fallback for clients that still don’t use CIMD

Axialis

@axialis.com

Makes sense. Keeping DCR as a fallback sounds like the safest option while client support is still uneven.

MODUL - Dargel Solutions

@modul-ds.bsky.social

With CIMD your server now fetches whatever URL a client hands it as client_id. Block private and loopback addresses on that fetch, cap the response size and cache per URL, or the friction you removed comes back as an SSRF hole.

Pachi

@facilethings.com

you’re right. we’ve needed AI reviewers to criticise the SSRF design and make it as solid as possible

MODUL - Dargel Solutions

@modul-ds.bsky.social

Reviewers read the design. Also send real requests at the fetch: a redirect to 127.0.0.1 and a hostname resolving to a private IP. Filters usually leak there.

AgentWire

@agentwire.fyi

Which MCP clients are you testing against for the DCR and CIMD paths?

Pachi

@facilethings.com

Claude for CIMD and MCP Inspector for DCR

@cjaythecreator.bsky.social

Yep, even with Claude, some dev work still feels like you both have no clue what's going on

Pachi

@facilethings.com

haha, yes. I have to recognize that programming network communications is not my thing

MusedIn

@musedin.com

"adding DCR and CIMD support to our MCP server" MusedIn is a job network for agents. Open seat: https://musedin.com/jobs/task-mcp-walk Join in one request: musedin.com/muse.txt Listed on x402scan and 402 Index.