What most people get wrong about audit logs and observability for MCP trading agents

Most developers assume that storing every MCP tool call and order response in an audit log is sufficient to understand what an agent did. In practice, logs without structured context, real-time signal latency, and actionable revocation paths create a false sense of security. Observability for an MCP trading agent requires correlating intent, execution, and outcome across market types, not just archiving raw messages. Without that correlation, you can reconstruct a failure but not prevent the next one.

Why do developers confuse audit logs with safety controls?

Many teams come from enterprise software where a comprehensive audit log is treated as proof of due diligence. If a system misbehaves, the standard playbook is to review the logs, identify the root cause, and patch the code. That approach works when the cost of a bad request is a failed database write or a slow web page. It does not work when the cost is an unintended leveraged position that moves against the account within seconds.

An audit log is a forensic record. It tells you that the agent called a tool at 14:03:22 and that the order filled at 14:03:23. It does not tell you why the agent decided to call that tool, whether the decision aligned with the strategy, or how to stop the next bad call. Suppose an agent is instructed to maintain a 50 percent cash reserve. The log may show a perfect timestamped record of the agent spending 90 percent of the wallet. The record is accurate, but the money is already gone. Trading can lose money, including everything, and a log entry cannot reverse a trade.

Real safety comes from controls that operate before execution. Scoped API keys limit what an agent can touch. Hard budget caps prevent cumulative drift. Position limits enforce maximum exposure. These are the guardrails, and logs are merely the cameras pointed at the guardrails. When builders treat logging as a substitute for prevention, they optimize for forensic clarity instead of survival. The goal is not to produce a beautiful log of a bankruptcy. The goal is to stop the agent before the loss occurs.

What does observability actually mean for an MCP trading agent?

Observability in agentic trading is not a flat file of API requests. It is the ability to infer the internal state of the agent from its external outputs and to act on that inference before damage accumulates. For an MCP trading agent, this means tracing the full chain from high-level prompt to market execution.

The chain starts with the agent's intent. A prompt might instruct the agent to reduce exposure to a specific asset class. The agent translates that intent into a series of MCP tool calls. Those tool calls hit a single API that normalizes orders into plain dollar sizes. The API routes the order to a stock broker, a crypto venue, a perps venue, an options venue, or a prediction market. The venue responds with a fill, a partial fill, or an error. Finally, the position and balance update in the owner's non-custodial wallet.

Each step in that chain must be visible. If you only log the final API response, you miss the critical gap between what the user asked and what the agent interpreted. A log that captures the MCP tool name, the arguments, the normalized dollar size, and the resulting position change gives you a trace. A trace lets you detect when the agent's reasoning diverges from the strategy, which is the earliest possible moment to intervene.

True observability also requires metrics. You need to measure the burn rate of the budget, the concentration of the portfolio, and the error rate of tool calls. Logs show discrete events, but metrics show trends. A series of small increases in position size might look harmless in individual log lines, but a metric tracking total exposure can reveal a dangerous drift. Because the wallet is non-custodial and owner controlled, the agent's view of the world must be reconciled against the actual wallet state. If the metrics disagree with the logs, the logs are incomplete.

Why is log completeness harder across multiple market types?

Logging a stock trade is different from logging a perpetual futures position, which is different from logging an options spread or a prediction market outcome. A single API hides much of this complexity by accepting orders in plain US dollars and handling venue-specific contract math, but the settlement and confirmation semantics still differ across every market type.

A stock trade might settle on a T+1 cycle and later generate a dividend or be affected by a corporate action. A crypto trade might depend on on-chain confirmation and network fees. A perps venue introduces funding payments that accrue while the position is open. An options venue might trigger assignment, exercise, or expiration. A prediction market resolves to a binary payout when an external event concludes. If your logs only capture the initial order request and a single fill event, you miss the ongoing cost of carry, the greeks, or the final resolution.

Complete observability requires logging the full lifecycle of every position. That means order creation, fill updates, position changes, funding or dividend events, and final settlement or closure. Without this, reconciliation is impossible. You might see a log that says the agent bought 500 dollars of exposure, but you will not know whether that exposure later became 600 dollars due to leverage or dropped to zero because the option expired worthless. You need both the normalized dollar value that the API provided and the venue-specific metadata that explains how that value changed over time.

This is why a unified log schema matters. The schema should have a standard header that describes the agent, the market type, the dollar size, and the timestamp. It should also have a flexible payload section that captures the unique mechanics of the venue. If you try to force a stock trade log into a crypto format, or a perps log into an options format, you will lose critical details. The goal is to normalize what you can and preserve what you cannot.

How should you structure alerts and escalation paths?

Alerts that arrive in tomorrow's email are not alerts. They are obituaries. An MCP trading agent can issue dozens of tool calls per minute across multiple markets. An alert pipeline must measure rate of change, not just static thresholds.

Useful alerts track budget burn rate over a short window, position deviation from a target allocation, repeated errors from a specific venue, and unusual sequencing of tool calls. For example, if the agent issues three successive buy calls for the same underlying within a single minute, that pattern may indicate a loop or a misinterpreted prompt. The alert should fire before the fourth call. Another useful metric is the ratio of failed tool calls to successful ones. A sudden spike in failures can mean the agent is misinterpreting the API response and retrying aggressively.

Every alert needs an owner escalation path that is independent of the agent. If the agent is the only system consuming the alert, a failure in the agent can silence the alert. The owner should receive the signal through a separate channel, such as a push notification or SMS, and should have the ability to trigger a kill switch without relying on the agent's own code. Alerts should also distinguish between paper trading and live trading. An anomaly in paper mode is a rehearsal; the same anomaly in live mode is an emergency.

To avoid alert fatigue, use severity tiers. A warning might indicate that the agent is approaching 50 percent of its daily budget. A critical alert might indicate that the budget is exhausted or that a position exceeds its hard limit. Warnings should be reviewed during business hours. Criticals should wake someone up. If every alert is critical, none of them are.

What should a kill switch and revocation trail look like in practice?

Observability is incomplete if it only covers market activity. The control plane, the mechanisms that start and stop the agent, must also be auditable. A kill switch is not just a button. It is a recorded event with a clear chain of custody.

When a kill switch activates, the log should record who or what triggered it, the timestamp, the reason, and the resulting action. That action might include flattening open positions, canceling open orders, and revoking the agent's API key. Each sub-action should generate its own log entry. After revocation, the owner should verify that the agent can no longer issue tool calls and that no orphaned positions remain open. The log should show a clean sequence: alert fired, kill switch triggered, orders canceled, key revoked, confirmation of zero open exposure.

Because Felix is non-custodial, the owner controls the wallet and approves withdrawal addresses. The agent can spend within limits but can never withdraw to itself. A revocation trail proves that this boundary held. If you cannot see the exact moment an agent lost access, you cannot trust the silence that follows.

The exact request schema is in the docs; the shape looks like this:

{
  "agent_id": "your-agent-id",
  "trigger_type": "position_limit_breach",
  "market": "options",
  "dollar_exposure": 5000,
  "timestamp": "2026-08-14T12:00:00Z"
}

This is illustrative. A real alert payload would include additional context from the API and the specific venue response.

A kill switch log must also be tamper-resistant. The agent should not be able to delete or modify its own audit trail. Logs should be written to a separate stream or store that the agent's API key cannot access. If the agent compromises the logging system, the entire observability stack collapses.

How does a single API change the scope of what you log?

A fragmented system forces you to parse a different log format for every venue. One venue might report size in contracts, another in base currency, and another in notional value. A single API normalizes the request shape by sizing orders in plain US dollars, so your primary observability schema can treat a 500 dollar order the same way whether it is routed to a stock broker or a perps venue. This reduces noise and makes cross-market analysis possible.

However, normalization does not mean omission. You should still append the venue-specific response metadata to the normalized record. The single API gives you the dollar size and the side. The venue gives you the fill price, the fee, the funding rate, or the expiration date. How a single API changes safety also changes logging, because a uniform request shape makes it easier to detect anomalies. An order that is ten times larger than the agent's typical size stands out immediately when all orders are expressed in the same unit.

Before moving from paper to live trading, review your logs carefully. The paper trading stream should prove that the agent respects bounds, that alerts fire correctly, and that the kill switch terminates activity. Live trading requires an explicit owner authorization of the key, and that authorization should be logged as a distinct event. Once real money is at stake, the log is not just a debugging tool. It is evidence that the system was designed to handle risk. Trading can lose money, including everything, and a clean paper log is the minimum evidence that the agent is ready to face that reality.