Your store as AI tools. In minutes, not days.

The agent calls one tool. Your orchestration runs underneath — every step.

An MCP tool doesn't have to wrap a single API call. younifyd turns your existing workflow routes into MCP-compliant tools automatically — and a route can be an entire orchestrated workflow, not just one connector call.

Build a workflow that checks inventory, checks active promotions, and adds the item to cart — three steps, with the inventory and promotion checks running in parallel. That same route already answers your storefront's own "Add to Cart" call. Expose it as an MCP tool named add_to_cart on top, and an AI agent sees one simple tool with one input schema — calling it runs the identical workflow your storefront already depends on, so your business logic decides what happens, not the agent, and there's no second copy of the logic to keep in sync.

This is the same execution engine behind the visual builder and the AI Assistant, not a simplified path for agents — parallel steps, transformations, credential injection, schema validation all run in full when a tool is called. The agent never sees your service topology; it just sees a tool that works.

1 toolwraps your entire orchestrated workflow

Connect what you already have. Don't rebuild it.

younifyd ships connectors for every major commerce platform — Shopify, Stripe, BigCommerce, commercetools, Klarna, and the rest of your stack — so you're generating MCP tools from real commerce workflows on day one, not starting from a blank canvas.

If your team or a vendor already runs its own MCP server, you're not locked out of it. Register the server's URL, transport, and auth configuration, and its tools become callable directly from inside a younifyd workflow — as a step, alongside your other connectors and business logic. It works the other way too: call out to a customer's own external MCP server mid-workflow, using the same MCP client protocol either direction.

You compose your own MCP servers together with ours — you're not limited to only what younifyd generates.

either directionimport an external MCP server, or call one from a workflow

Scope access tightly — rotate or revoke without disrupting other clients

Each MCP server has its own independent set of API keys. A key grants access to that server's tools and nothing else — not other MCP servers, not the management API, not the workflow builder. This scope isolation means a compromised or leaked key affects only the tools on that one server.

Keys are shown in full exactly once — at creation time — then stored as SHA-256 hashes. The prefix is retained for identification (so you can tell which key is which in the UI) but the full value is never stored in recoverable form. If a key is compromised, revoke it and generate a replacement; existing clients using other keys on the same server are unaffected.

Multiple keys per server let you issue separate credentials to separate consumers — your Claude Desktop workspace, a CI pipeline that tests tool calls, a partner integration. When you need to rotate a key, issue the replacement before revoking the old one, giving consumers time to migrate without a service interruption.

isolatedscope per API key

Your AI tools know who is calling them — even without an external OAuth provider

Most teams that want user-aware MCP tools assume they need an external OAuth provider. They don't. If you have any endpoint that validates credentials and returns a token — a workflow calling your existing auth service, your own login API, a database lookup — that is all the MCP server needs.

Configure the custom login option: point it at a workflow route, tell it which fields in the request body contain the username and password, and specify the dot-notation path to the token in the response (e.g. "access_token" or "data.token"). The MCP server shows a branded login form to the user, POSTs the credentials to your workflow, and extracts the token from the response. That token is stored in the MCP session and forwarded as an Authorization header on every subsequent tool call.

This changes what your tools can do. Instead of anonymous tool calls where every request looks identical, your workflows receive the authenticated customer's token on every invocation — they know who is asking. A "get my orders" tool can call your orders service with the customer's bearer token and return their orders, not a generic list. The AI agent acts on behalf of the authenticated customer, with full user context, across the entire session.

For teams that do use an external OAuth provider — Auth0, AWS Cognito, Google, any OAuth 2.0 compliant IdP — the redirect login option works the same way. Both login methods produce the same outcome: an authenticated session with a user token that tools receive on every call.

any auth systemcustom login, no external OAuth required

See exactly what every AI agent requested, when, and how long it took

Every MCP tool call produces the same execution record as a regular workflow request — timestamped, with per-step timing, the connectors called, and the full response payload, in the same searchable execution history as everything else on the platform.

This matters more than it might seem. AI agents can be prolific callers — a single Claude session can trigger dozens of tool calls in a few minutes. Without visibility into each call, it is impossible to know whether an agent is calling tools correctly, whether it is making redundant calls, or whether a slow upstream service is causing it to retry. The execution record shows you exactly what happened on each call.

every callrecorded in your execution history

Stop agents asking to re-login every hour — set the right TTL for your use case

The default OAuth session lifetime is one hour — a sensible conservative default for interactive use cases. But AI agents are not interactive users. A Claude Desktop session running background tasks should not be interrupted hourly for re-authentication; a session that expires mid-task forces the user to restart the entire operation.

younifyd lets you set the session expiry per MCP server to any custom duration in seconds — an hour, a day, a week, whatever matches how that server is used. The expiry is stored with each session and reported to the MCP client in the token response — the client's internal refresh timer is set to the full configured duration rather than counting down from a partial session lifetime.

This also fixes the double re-authentication problem that occurs when clients check token validity at expiry time: because the token response carries the full session lifetime rather than the remaining seconds, clients set their refresh timer correctly from the moment the token is issued.

fully configurablesession lifetime — no more hourly prompts