An MCP server that can read a phone screen is the hardest kind of server to observe. The most useful thing monitoring can tell you is that a tool failed. The most dangerous thing it could hold is what the user was looking at when it did.
Melaya's MCP server lets Claude, ChatGPT, Cursor and other AI clients operate a user's real Android apps, real browser tabs, agent pipelines and connected business systems. That reach is the product. It is also why observing it is hard: every interesting tool call touches something private.
Melaya has partnered with Flowlines, the behavioral observability platform built for AI agents, to watch that server the way it deserves to be watched: per tool, per AI client and per release, with the failures nobody reports surfaced before users notice them. Flowlines already sees agent activity from Claude Code, Codex, LangSmith, Langfuse and MCP servers. Melaya brings one of the most demanding MCP servers it can observe, one whose tools act on people's own devices.
The partnership rests on one rule we set together from day one: no user's content and no user's personal metadata leaves Melaya. No screens, pages, prompts or tool results, and no names, emails or IP addresses. Flowlines works from tool health and a random account ID, and this article shows how much that is enough to learn. In the first 48 hours after going live, both teams found gaps, both shipped fixes within a day, and Flowlines was showing us release changes, contract drift, user intent and a reliability baseline across 44 tools.
The Melaya and Flowlines partnership
Melaya builds governed AI agents: scoped tools, bring-your-own model, human approval before consequential actions, and a replayable history of everything an agent did. Its MCP server hands that governed surface to the AI assistant a team already uses. Flowlines makes agent behavior visible: sessions, users and intents, releases, tool contracts and security signals, built around the failures that never become a support ticket.
Put together, the two answer a question every team connecting an AI client to real systems eventually asks: is it working, for everyone, after every release, and can we prove it without handing over our data? Melaya supplies the governed server and the privacy boundary. Flowlines supplies the behavioral lens and the product loop to improve it.
- A remote MCP server with 83 scoped tools across 8 permission domains and a governed path to 8,000+ connector tools
- Real reach: Android apps, browser tabs, pipelines and connected services
- OAuth 2.1 with PKCE, per-scope consent and verified account identity
- A metadata-only span contract enforced in code and pinned by 32 tests
- A demanding, stateless server that pushes an observability contract to its edges
- Behavioral observability designed specifically for AI agents
- Sessions, users, intents, releases, contracts and security signals
- MCP-native ingestion over OpenTelemetry
- A published span contract and an official plugin to implement it
- A team that turns field feedback into shipped product in days
- Melaya's MCP server instrumented end to end with Flowlines, live in production since 24 September 2026
- A metadata-only data contract agreed from the start: no content, no names, no emails, no IP addresses
- Release checks: tool success rates, error categories and contract changes compared across every Melaya release
- Silent-failure detection per tool and per AI client, so the fix goes to the tool that is actually breaking
- A shared feedback loop: Melaya reports what it sees on a demanding server, Flowlines ships product from it
Privacy-first MCP observability: the problem we had to solve
An MCP server exposes tools to an AI client over the Model Context Protocol. Melaya's server exposes 83 native tools across 8 permission domains, secured with OAuth 2.1 and PKCE, and through the services a user connects it reaches more than 8,000 tools across Melaya's connector catalog. A user connects their AI client once, approves the scopes they want, and from then on the client can call tools such as reading the paired phone's screen, navigating a browser tab or running a pipeline.
When a server like that misbehaves, the symptoms are quiet. A tool returns an error that a model politely works around. One client sends an argument in a shape nobody tested. A release changes a tool's contract and nobody files a bug, because the user simply assumes the AI got confused. Flowlines describes this exactly: the agent failures no one reported.
The standard answer is observability: record every tool call, its inputs, its outputs and its outcome, then analyse the stream. For most servers that is reasonable. For ours it would mean exporting the contents of people's phones and browsers to a third party. That was never an option.
So the question became precise: how much can we learn about an MCP server's health from metadata alone? Forty-eight hours of production data gave us the answer. Most of what matters.
48 hours from first span to first findings
- Build with the official pluginMelaya implemented Flowlines' MCP contract with its Claude Code plugin, then made seven privacy decisions of its own. One shared boundary covers every tool
- Go live and watch the first spans landProduction calls arrived in Flowlines with explicit success or failure, a verified pseudonymous account ID and the calling client
- Find the gaps, on both sidesCalls could not be tied to a release, the intent fields cost too many tokens, and stateless calls could not be grouped into journeys
- Ship fixes, on both sidesMelaya added release versions and cut the intent fields' token cost by about 79 percent. Flowlines shipped session inference for stateless MCP servers
- Read the first findingsReliability baseline, three releases, contract drift, intent clusters and the real shape of tool usage, all from metadata
The part we are proudest of is the middle. An integration that works on the first try teaches nobody anything. This one surfaced real gaps within hours, and each team fixed its own side the next day.
What Flowlines showed us in the first 48 hours
This window covers the first two days of production telemetry and includes our own validation traffic, some of it deliberate failures. We publish it because every figure below comes straight from Flowlines, not because two days make a trend.
A reliability baseline with no unknowns
Of 754 tool calls, 732 succeeded and 22 failed, several of them deliberate probes we sent to test the failure path. Every single call carried an explicit outcome, so Flowlines reported 100 percent outcome coverage and zero calls of unknown status. Median latency was 66 milliseconds. The slow tail, about 6 seconds at the 95th percentile, is where we are looking next.
- SucceededExplicitly marked as a success by the tool73297.1%
- FailedEach with a bounded error category, several of them deliberate probes222.9%
- Unknown outcomeNo call was ever left without a status00%
Every call tied to the release that served it
Each span now names the exact build that answered it. Flowlines tracked three Melaya releases across the window without anyone tagging a deploy by hand. When a tool regresses, the question "which release did this" has an answer before anyone asks it.
Contract drift, caught without an announcement
Flowlines keeps a baseline of every tool's published description and schema and compares each new version against it. When a release changed the input and output schemas of two pipeline tools, Flowlines recorded the change on its own. For an AI client, a tool's schema is its API. Seeing it move per release is exactly the check we want before a client trips over it.
Intent, without asking anyone to change anything
Melaya advertises two optional fields, a short reason and a one-sentence user_intent, with a single line in its server instructions. Nearly half of all calls arrived carrying them, from clients we never contacted. Flowlines grouped those sessions into purposes such as capability overviews, account and device management and connection checks. The clearest product need it surfaced was simple: before anything else, people want to confirm their account is ready. That is precisely what Melaya's setup check exists for, and now we can see it being used that way.
The real shape of the tool surface
44 of Melaya's 83 tools were called in the window. The other 39 were not. Some of that is simply two days of data, but it is also the first honest map of which tools carry the load and which ones need better discovery, better descriptions or a hard look. We had opinions about this before. Now we have evidence.
Security rules armed, nothing fired
Flowlines armed prompt-injection, exposed-secret and suspicious-input detectors on every observed tool. None fired. Because Melaya sends no payloads, Flowlines rates that coverage as partial, and that is the correct label: it is the price of the privacy boundary, and we would make the same trade again.
What we fixed together
- A release version on every span, taken from the build itself, so each call names the release that served it
- Bare optional fields plus one server instruction, cutting their cost in every tool list from about 6,200 tokens to about 1,300
- A 72-token instruction that got AI clients to describe the user's goal on nearly half of all calls
- A validation pass that fed concrete, reproducible findings back to Flowlines
- Session inference for stateless MCP servers, whose modern protocol has no transport session to group calls by
- An updated integration skill with clear guidance on session identity
- Ingestion and access fixes surfaced during the validation pass
- Per-tool contract baselines and release tracking, ready the moment spans arrived
The session problem is the best example of how this partnership works. The newest version of the MCP protocol is stateless: there is no connection-level session for a server to report, so a stream of calls from one conversation arrives as unrelated events. We told Flowlines, with examples. The next day, Flowlines was inferring sessions from the calls themselves and grouping them into journeys with a stated intent. Every stateless MCP server Flowlines observes benefits from that change, not only ours.
We wanted to know when a tool breaks, for whom and after which release. We never needed to know what was on the screen when it did.
How we instrumented 83 MCP tools through one boundary
The simplest integration would have added telemetry to every tool handler. It would also have produced 83 slightly different implementations and 83 places for a privacy mistake to hide. We did the opposite.
- Validate firstScope, argument names, argument types and quota are checked before any span exists. A rejected call did no work and is not recorded as one
- Open one spanA single wrapper around tool execution starts a server span with a fresh call ID, independent of the protocol request ID
- Run the toolThe handler runs exactly as it did before telemetry existed, including its public error mapping
- Record the outcomeThe span is closed with an explicit success or failure and, on failure, a short error category
- Export in the backgroundSpans are batched and sent asynchronously. An export failure is absorbed and can never change what the tool returned
The tool description and input schema on each span come from the same function that serves the tool list to clients. That detail is what made contract drift detection work on day one: the contract Flowlines records for a tool can never drift from the contract an AI client actually sees.
Seven engineering decisions behind metadata-only observability
Flowlines publishes a thorough contract for MCP servers, and its MCP OpenTelemetry instrumentation guide is the right starting point for anyone doing this. We followed it closely, and made seven deliberate choices where our situation demanded something different.
1. The payload is someone else's data
The contract asks for full tool arguments and results, and for most servers that is the richest evidence available. On Melaya those payloads are other people's phone screens, browser pages and business records. We send neither. Every span carries tool health and identity metadata only, and a test fails the build if an argument or result ever appears on one.
2. A required field is a breaking change, and a verbose one is a tax
Flowlines asks MCP clients to send a short reason and a user_intent with each call. Making them mandatory would have broken every MCP client in use today. They are optional on Melaya: never grounds to refuse a call, and removed before the tool itself runs. Our first version also described both fields on every tool, which quietly added about 6,200 tokens to every tool list a client loads. We moved the explanation into one server instruction and kept the fields bare. The cost fell by about 79 percent, and clients kept filling them in.
3. Identity comes from the token, never the request
A client can put anything in a request's metadata, including someone else's user ID. The only identity on a Melaya span is the verified subject of the OAuth token. Client-supplied identity is ignored outright, and a test sends a spoofed ID, name and email to prove none of them survive.
4. Unknown is not success
OpenTelemetry leaves a span's status unset by default, and an unset call is reported as unknown rather than successful. Every completed Melaya call is marked explicitly. That is why Flowlines could report 100 percent outcome coverage from the very first hour.
5. Errors carry a category, not a message
Exception messages are where internal detail leaks. A failed call records one of a handful of fixed categories, such as a tool error, an access refusal or a plan limit, and nothing else. Stack traces and exception events never reach a span.
6. Credentials belong to one service
The obvious way to configure an OpenTelemetry exporter is with its standard environment variables. We noticed in review that those variables are read by every process that loads them, so in a shared environment a second service with its own tracing could have picked up the Flowlines credential and attached it to traffic we never intended. The integration reads settings scoped to the MCP server alone. A test proves the standard variables cannot switch it on.
7. Observability must never change the answer
The integration is inert until two explicit settings are present. When it is on, it is fail-open: a broken exporter, a slow network or a span that fails to build cannot alter a tool's result. Our own existing tests enforced that from day one. They pin the exact line where every tool call is charged against a plan, and they failed our first draft, which had renamed that line. We restructured the code until they passed unchanged.
Who won what
- Teams using Melaya: an MCP server watched per tool, per client and per release, while their screens, pages, prompts and data stay inside Melaya
- Melaya: a reliability baseline, release tracking, contract drift detection, intent clusters and hard evidence about which tools matter
- Melaya: a smaller, cheaper tool list for every AI client, because measuring the intent fields exposed what they cost
- Flowlines: a production reference for metadata-only MCP observability on a server that operates real phones and browsers
- Flowlines: session inference for stateless MCP servers, driven by a real case and useful to every server it observes
- Both: proof that behavioral observability and a strict privacy boundary are not a trade-off
GDPR by design: why no user metadata leaves Melaya
Observability is a data flow, and under the GDPR every data flow needs a reason to exist. We designed this one around the regulation's principles rather than around what an observability tool could technically accept. Flowlines' contract can carry a user's name and email to enrich its profiles. We chose not to send them.
- Data minimisationEach span carries only what is needed to measure tool health: the tool, the outcome, a bounded error category, the release and the AI client. Nothing else is collected for observability
- PseudonymisationAccounts appear only as a random ID. The information that links that ID to a person never leaves Melaya, and Flowlines receives nothing that could re-identify it
- No sensitive content in transitPhone screens, browser pages and business records can hold health, financial or other sensitive data. None of it is exported, so none of it can be exposed downstream
- Erasure that holdsDelete a Melaya account and the random ID left in telemetry points to no one. There is no name, email or content on the Flowlines side to clean up
- Protection by defaultTelemetry stays off until explicitly enabled, and the privacy rules are pinned by tests that fail the build if a payload or identity field ever reaches a span
What never leaves Melaya, stated precisely: tool arguments, tool results, screen and page contents, prompts, names, email addresses, IP addresses, request metadata, authorization headers and exception messages. Identity supplied by a client in a request is discarded, and the only account identifier is the verified subject of the OAuth token.
A pseudonymous ID is still personal data under the GDPR, so we treat it as such: collected for one purpose, kept to the minimum and never joined with anything that names a person outside Melaya. This section explains how the integration is built. It is not legal advice and not a compliance certification.
The data boundary, stated plainly
| Sent with each tool call | Never sent |
|---|---|
| Tool name, published description and schema | Tool arguments |
| Success or failure, and a bounded error category | Tool results, screens and page contents |
| A verified pseudonymous account ID | Names and email addresses |
| The release that served the call | Request metadata as a whole |
| Call and request IDs, and the calling client | Exception messages, stack traces and IP addresses |
| An optional reason and user intent, length-capped | Credentials, headers or authorization claims |
The optional reason and user intent fields are short free text written by the calling AI client. They are length-capped, only recorded when a client chooses to send them, and our server instruction tells clients never to put personal data, secrets or content they read into either. A client could still describe a task in words. That is the residual risk of the design, and it is why the fields are optional rather than required.
What comes next
- The slow tail. Using per-tool latency to find what drives the 95th percentile and bring it down.
- The untouched tools. Deciding, tool by tool, whether the 39 unused tools need better discovery, better descriptions or retirement.
- Release gates. Comparing success rates and contract changes before and after each Melaya release as a standing check.
- Explicit session identity. Sending a session ID for clients that provide one, alongside Flowlines' inference for those that do not.
- Wider intent coverage. Moving from nearly half of calls explained by intent toward most of them, without ever making the fields required.
Connect Melaya to your AI client
Melaya's MCP server gives Claude, ChatGPT, Cursor and other clients governed access to your paired phone, your browser, your pipelines and your connected services through one remote endpoint, with consent per permission scope. See the Melaya MCP Server, or read how we launched it.
If you run your own MCP server, Flowlines' guide to MCP observability and its official plugin are where to start. The privacy decisions above apply to any server whose tools touch user data.
