Streamable HTTP · JSON-RPC 2.0 · 7 tools
ecentic MCP server.
Claude, ChatGPT, and any Model Context Protocol client can call ecentic natively over JSON-RPC 2.0. This page is the connection reference: the endpoint, the transport, the handshake, and every tool it exposes.
Connect
One endpoint, two paths, no session to manage.
Content-Type: application/json
Accept: application/json, text/event-stream
{"jsonrpc":"2.0","id":1,"method":"tools/list"}The server is reachable at /mcp and at /api/mcp. Both are the same handler; the bare path exists because most clients and scanners probe it first.
The transport is Streamable HTTP. Every request is a POST carrying JSON-RPC 2.0, and every response arrives on that same POST. ecentic opens no server-initiated stream, so a GET with Accept: text/event-stream answers 405 rather than hanging your client on a stream that will never emit.
There is no session. ecentic issues no Mcp-Session-Id, and DELETE — the session-termination verb — answers 405 for the same reason. Nothing needs to be torn down.
Handshake
Initialize, then send the initialized notification.
2025-06-18, 2025-03-26, 2024-11-05initialize returns the negotiated protocol version, the server identity, its capabilities, and an instructions string describing what ecentic is for. If you ask for a version ecentic speaks, you get that version back; anything else falls back to the version it advertises.
The notifications/initialized message that follows is a JSON-RPC notification — it has no id and draws no reply. ecentic answers it with 202 Accepted and an empty body, as the transport requires. A server that answers a notification with a JSON-RPC error breaks the handshake, so this is the one exchange worth checking first when a client will not connect.
→ {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26"}}
← 200 {"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-03-26", ...}}
→ {"jsonrpc":"2.0","method":"notifications/initialized"}
← 202 (no body)Tools
What the server exposes, and which calls need a key.
| Tool | Auth | What it does |
|---|---|---|
| list_plans | none | Returns the public plan catalog with prices, billing mode, and performance-fee terms. |
| create_api_key | bearer | Mints a long-lived agent API key on the caller's account. Shown once. |
| create_checkout | bearer | Opens a Stripe checkout session for a subscription plan. |
| connect_shopify | bearer | Starts the Shopify OAuth install for a shop domain. |
| connect_woocommerce | bearer | Connects a WooCommerce store with REST consumer credentials. |
| connect_feed | bearer | Connects a product feed by URL, auto-detecting XML or JSON. |
| get_onboarding_status | bearer | Reports which onboarding steps the account has completed. |
Authentication
Read-only tools are open; anything touching an account takes a bearer key.
Authorization: Bearer ecentic_sk_…Send Authorization: Bearer ecentic_sk_… on tool calls that change account state. A call that needs a credential and does not have one returns HTTP 401 with a WWW-Authenticate header naming the Protected Resource Metadata document, so a client can re-run discovery from the failure itself.
Keys are self-serve: create an account, then mint one from the dashboard or by calling create_api_key over an authenticated session. No sales contact is involved at any point.
Errors
Two error surfaces, and which one you are looking at.
A JSON-RPC error — an unknown method, bad params, a tool that refused — arrives as HTTP 200 with an error member, exactly as JSON-RPC specifies. Branch on error.code.
A transport error — a method the endpoint does not offer — arrives as an RFC 9457 problem document with Content-Type: application/problem+json and a machine-readable code. That is the same error model the REST surface uses.
The one exception is 401: it carries the JSON-RPC envelope so a client already parsing JSON-RPC does not need a second parser, plus the WWW-Authenticate header for discovery.