Agent Access (MCP)

Your processes, queryable by any agent your company runs. Flow Myna ships a read-only MCP server: connect Claude, Copilot Studio, Bedrock agents — anything that speaks the Model Context Protocol — and they can answer process questions with the same numbers your dashboards show.

Why this exists

Your process data shouldn't only be visible inside our UI. The agents your team already uses — a support copilot, an ops assistant, an internal Claude — become dramatically more useful when they can ask "where are orders getting stuck this month?" and get a real, current, correct answer. The MCP server gives them exactly that: twenty-one read-only tools over your live process data — aggregates, the process map, and the story of any single case — with no export pipelines and no stale snapshots.

Everything is read-only and deterministic. The tools run the same query engines that power Flow Myna's charts and copilot — no LLM sits between the question and your data, nothing can write, and the numbers match the product UI to the decimal.

Connect in two minutes

Create an API key under Workspace → Data → API Keys (a key created without scopes works as it is; a scoped key must carry process:read. Keys are workspace-scoped, so the agent sees that workspace's projects and nothing else).

Claude Code:

claude mcp add --transport http flowmyna https://api.flowmyna.com/mcp \
  --header "Authorization: Bearer fm_live_YOUR_KEY"

Cursor, the Claude Agent SDK, or any client that takes an mcpServers block with headers:

{
  "mcpServers": {
    "flowmyna": {
      "type": "http",
      "url": "https://api.flowmyna.com/mcp",
      "headers": { "Authorization": "Bearer fm_live_YOUR_KEY" }
    }
  }
}

Claude.ai, Claude Desktop connectors and ChatGPT authenticate connectors with OAuth rather than an API-key header, so they can't be pointed at the server yet. OAuth sign-in for those clients is on the roadmap; today, use them through Claude Code or an agent framework that sends headers.

Then ask your agent something real:

"Using the Flow Myna tools: what are the top process variants for Sales Orders, and what's our biggest bottleneck?"

A well-behaved agent will call list_projects, learn your schema with describe_project, then answer with concrete counts, shares, and wait times — e.g. "41.6% of orders follow the happy path; the dominant bottleneck is Invoice Sent → Payment Received at a median 34 days." Ask about one case — "what happened to INC-00224?" — and it finds the object and walks you through every step and every wait.

What agents can ask

Every query tool accepts an optional cohort written in plain names — the events a case must (or must not) have, attribute values, completed or in-flight, a timeframe, specific case ids, or one of your saved filters by name — so agents can scope any question: completed cases only, one channel, orders above a value, cases that touched a rework step, last quarter. The same plain names also express the shapes that usually need a query language:

• Repeats — a step done twice or more, or never more than once (event_counts).
• Order — B happened before A, or B happened without A before it, also across linked object types (sequence).
• Waits — more than three days from A to the next B (wait), or a total cycle time over ten days (duration).
• Linked records — four or more linked items, a linked record with a given attribute, or none at all (related).
• Calendar — the step happened on a Monday, in the last five days of the month, after 6 pm, or in December (event_time).

Cohorts are validated with helpful errors (an unknown name comes back with the valid ones, never as an empty result), free to evaluate, and echoed back as a label so the agent can say exactly what it measured. The product's full structured filter schema is available too for anything a cohort can't say.

Advanced: the filter parameter

For shapes a cohort can't express, pass filter instead: the product's own filter JSON, with ids from describe_project. Which cases it keeps is one condition tree in conditions — groups that nest, around conditions:

• Groups: {"kind": "all" | "any" | "not", "children": [...]} — all must hold, at least one holds, or the one child fails. The top level is always all.
• Conditions, each tagged with its kind: attribute (a value on the case or one of its events), events (had these events, optionally at least N times), current_state (where the case is now), elapsed (time since an event, up to the data's latest event), duration (cycle time), transition_delay (time from A to the next B), related (a related object matches, through one or more relationships), path (A followed by B, or never followed by B, directly or at any time), completion (completed or in flight), timeframe (a date window), and comparison (two values compared — an event's time against a date on the case, or a related total against the case's own value).

"Direct orders that are closed, or distributor orders that are delivered":

{
  "view": {"lens_object_type_id": "<Sales Order type id>"},
  "conditions": {"kind": "all", "children": [
    {"kind": "any", "children": [
      {"kind": "all", "children": [
        {"kind": "attribute", "level": "object", "key": "channel", "op": "=", "value": "Direct"},
        {"kind": "attribute", "level": "object", "key": "order_status", "op": "=", "value": "Closed"}]},
      {"kind": "all", "children": [
        {"kind": "attribute", "level": "object", "key": "channel", "op": "=", "value": "Distributor"},
        {"kind": "attribute", "level": "object", "key": "order_status", "op": "=", "value": "Delivered"}]}]}]}
}

Unknown keys are rejected with the valid field names, so an agent can correct itself instead of silently querying everything.

Built for object-centric processes

Because Flow Myna is object-centric, agents aren't limited to one case notion. They can ask about Sales Orders, then Deliveries, then Invoices — or across them: order-to-cash cycle time spanning all three, delays between events on different object types, attributes pulled through relationships ("revenue by customer tier"). The describe_project tool hands the agent the full type/relationship graph so it can navigate on its own.

Security model

• Your existing API keys — nothing new to manage; revoke a key and agent access is gone with it
• Workspace-scoped — a key can query its workspace's projects, never anything else
• Read-only by construction — the tool registry contains no write-capable tool, enforced by an automated test on every build
• Rate-limited — per-key request budget (60/minute), and every query runs under the platform's statement timeouts
• scan_process has its own budget — it does seconds of database work per call, so each key can run at most 2 at once and start 30 per rolling hour. A call over either limit is refused with a retry_after_s the agent can wait out; repeating a scan while the data has not changed is answered from cache and does not count

Under the hood

• MCP streamable HTTP transport, stateless, JSON responses — works with every current MCP client
• scan_process checks every object type that has events for problem leads — steps repeated where they normally happen once, too many linked records, steps out of their usual sequence or skipped, activity after the end, stuck cases, unusually long or suddenly slower waits, one person doing most of a step, linked records that disagree on a value, impossible dates — each judged against what is normal in your own data, never a fixed threshold. Every lead comes with a ready-made group to dig into and the top differences that set it apart; leads are starting points to verify with the other tools.
• Tools return a one-line summary plus the same chart-shaped payload the product renders, so agents can quote numbers and reason over the full result. query_cohort_explain returns a compact form instead: findings ordered by how much of the group they account for, with conditions that merely restate how the group was defined set aside and counted, never ranked; near-perfect splits flagged as possibly the outcome itself; the calendar of the step that defines the group (weekday, month end) tested alongside attributes. Rankings, histograms and rework come back compact too, and rework tells a real repeat apart from one-per-child multiplicity
• Unknown tool arguments and unknown filter fields are rejected with the valid options — never silently ignored
• Deterministic SQL builders, shared with the in-product copilot and dashboards — one engine, one set of numbers