DEV Community: Goutham Nishkal Deepu EDA

Human-in-the-Loop Is Not a Governance Strategy

Goutham Nishkal Deepu EDA — Fri, 10 Jul 2026 20:34:31 +0000

Picture the human at the end of an agent pipeline.

The agent drafts an action. A modal pops up. Approve or reject. The human has seen forty of these today, they all looked fine, and the queue is backing up. They click approve. They will click approve on the next one too.

That is "human-in-the-loop." It is on almost every agentic-AI architecture diagram, usually drawn as a small person icon standing between the model and the irreversible action, labelled governance.

It is not governance. It is a rubber stamp with a person's name on it, and its main function is to move liability from the system to the human who clicked. I want to argue that most HITL, as shipped, makes systems look accountable while making them slightly less safe, and then describe what actually works instead, with code you can adapt.

No prior background assumed beyond having built or used an agent that takes actions.

The wrong question

The phrase "human-in-the-loop" quietly smuggles in a claim: that the presence of a human constitutes oversight. So teams optimise for presence. Is there a human in the loop? Yes? Ship it.

But presence is not the variable that matters. A human who is present but cannot realistically change the outcome is not a safeguard. They are decoration, and worse, they are load-bearing decoration, because everyone downstream now assumes the action was reviewed. The audit log says "approved by a human." The incident review will say it too.

The right question is not "is there a human in the loop?" It is:

Is the human positioned to actually change the outcome?

That reframe turns governance from a checkbox into a design problem. And design problems have structure. Three parts of it matter, and then a fourth thing that sits above all three.

1. Surface the decision, not the data

The rubber-stamp modal usually shows the human the action: here is the SQL we're about to run, here is the email we're about to send. Raw output. To approve it meaningfully, the human has to reconstruct the entire context the agent already had, in the two seconds before the queue guilt-trips them into clicking.

Real review surfaces the decision, not the payload. What is the agent trying to accomplish, what did it consider, what is it unsure about, and what happens if this is wrong?

Concretely, that is the difference between handing the human this:

DELETE FROM users WHERE last_login < '2024-01-01' AND status = 'trial';

and handing them this:

{
    "doing": "delete duplicate trial user",
    "affects": "1 record",
    "risk": "irreversible",
    "agent_confidence": "60%",
    "if_wrong": "restore from nightly backup",
}

The first asks the human to be a database reviewer at queue speed. The second asks them to make a judgment they are actually equipped to make: is a 60%-confident irreversible delete of one record worth a human's attention right now? That is a question a tired person can answer well. Parsing a DELETE filter for a subtle bug is not.

If your HITL layer shows the human the same thing your logs show, you have built an audit trail, not an oversight step. The payload is for the log. The decision summary is for the human.

2. Interrupt on what matters, not on everything

Here is the naive policy almost everyone ships. Anything that writes gets a human; anything that only reads runs free.

def naive_needs_human(action) -> bool:
    return action.kind != "read_file"

It feels safe. It is actually the source of the rubber stamp, because it interrupts constantly, and constant interruption is how you train a human to approve reflexively. A gate that fires on every write is, functionally, a gate that fires on nothing, because the human behind it has stopped reading.

A better policy interrupts on the properties that actually make an action dangerous: is it reversible, how large is the blast radius, and how confident is the agent in its own decision? And it recognises a third outcome beyond allow and review: some actions should never reach a human at all, because no realistic human review makes them safe.

from dataclasses import dataclass
from enum import Enum

class Decision(Enum):
    ALLOW  = "allow"    # run without asking
    REVIEW = "review"   # surface to a human
    BLOCK  = "block"    # never automate; architectural "no"

@dataclass
class Action:
    kind: str
    reversible: bool
    blast_radius: int      # records or people affected
    confidence: float      # agent's own confidence, 0..1
    intent: str = ""       # what the agent is trying to do
    undo: str = ""         # how it gets reversed, if it can be

def govern(a, conf_floor=0.85, radius_cap=50, hard_radius=500) -> Decision:
    # Top tier: irreversible AND huge -> not an approval question, an architecture one.
    if not a.reversible and a.blast_radius > hard_radius:
        return Decision.BLOCK
    # Reversible -> let it run; you can undo.
    if a.reversible:
        return Decision.ALLOW
    # Irreversible but bounded -> review only if big or uncertain.
    if a.blast_radius > radius_cap or a.confidence < conf_floor:
        return Decision.REVIEW
    return Decision.ALLOW

Run a spread of actions through it:

read_file    -> allow
db_write     -> allow    (reversible, undo by id)
delete_row   -> review   (irreversible, only 60% confident)
send_email   -> block    (irreversible, 1,200 recipients)
wipe_table   -> block    (irreversible, 900 rows)

Notice what happened to the mass email. The naive policy would have shown it to a human for approval, which feels responsible. But "email 1,200 customers, irreversibly, right now" is not a decision you want made by whoever happens to be watching the queue. It is a decision that belongs in the architecture, made once, cold, with a rate limit and a second sign-off path, not in a modal at 4pm. Routing it to BLOCK is not ducking governance. It is putting the governance where it can be done well.

The middle tier, REVIEW, now fires rarely, on exactly the actions where a human's judgment is both needed and possible. Governance quality is not proportional to how often you stop. It is inversely proportional to how often you stop for no reason.

3. Give the human a real "no"

An approval step where "reject" has no defined path is not a decision, it is a formality. If rejecting the action just dead-ends the workflow, throws an error, or dumps the problem back on a user with no next step, everyone learns quickly that "reject" is the button that breaks things, and they stop pressing it.

A real "no" needs somewhere to go. At minimum:

A fallback the system runs instead (a safer, smaller version of the action).
A re-plan, where rejection feeds back to the agent as a signal to try a different approach rather than halting.
An escalation to someone with more context or authority, not a dead end.
Graceful degradation, where the workflow completes in a reduced but coherent state.

The human also needs time and the ability to be right: enough context to form a judgment, and a system that treats their rejection as information rather than an obstacle. If your reject path is slower, riskier, or more painful for the human than the approve path, you have not built a decision point. You have designed the human into compliance, and the approve button is the only one that works.

A quick test: pull up your agent's reject handler. If it is a raise or a return None, you do not have human-in-the-loop. You have human-in-the-way, and your operators already know it.

The counterintuitive core

Put the three together and you get a conclusion that surprises people: good human-in-the-loop design interrupts the human less, not more.

This runs against the instinct that more oversight is safer. But oversight has a capacity, and it is small. Every unnecessary approval spends down the human's attention and trains the reflex that makes the necessary approval worthless. A system that stops the human ten times a day for trivia and once a month for something that matters has all but guaranteed they will sleepwalk through the one that matters.

There is a body of human-factors research behind this, under names like automation complacency and alarm fatigue: when a signal fires constantly and is almost always benign, operators stop attending to it, and they miss the rare real one. HITL modals are alarms. The same failure mode applies. A system that cries wolf on every database write has trained its humans to ignore the wolf.

So concentrate the interruptions. Make each one rare, high-context, and consequential. That is not less governance. It is the only kind that survives contact with a tired human and a full queue.

A cleaner way to think about it: levels of autonomy

The allow / review / block split hints at a more useful mental model than "is there a human in the loop." Think of each action type your agent can take as sitting at one of a few autonomy levels:

Level 0, Blocked. The agent may propose it, but a human must initiate it through a separate, deliberate path. Reserved for irreversible, high-blast-radius actions. The governance is architectural.
Level 1, Review. The agent prepares the action and a decision summary; a human approves before execution, with a real reject path. Reserved for irreversible-but-bounded, or low-confidence actions.
Level 2, Notify. The agent acts autonomously but the action is reversible and logged loudly, so a human can catch and undo it after the fact. Most write actions live here.
Level 3, Autonomous. The agent acts freely. Reads, idempotent operations, anything with no meaningful blast radius.

The real governance work is not building the modal. It is deciding, per action type, which level it belongs to, and being honest that most teams default everything to Level 1 (approve everything) because it feels safe and requires no thought. It is the least safe option that looks the safest. Sorting your actions into these tiers, deliberately, is the work.

The honest limit

There is a case none of this solves, and pretending otherwise is how HITL became a liability blanket in the first place.

Sometimes the right answer is not "add a human." It is "do not automate this action." If an action is irreversible, high-blast-radius, and the agent's confidence is not trustworthy, no approval modal fixes that, because you have handed a human a decision they cannot make well under the conditions you have given them. That is what Level 0 is for. At the top of the risk spectrum, the governance decision is made long before any human sees a modal: you simply keep the action out of the agent's autonomous reach.

And even a well-designed review step has a ceiling. It assumes the human can evaluate the decision in the time available. For genuinely complex actions, where correctness depends on context the human cannot absorb at a glance, "surface the decision" is not enough, and the answer is either better tooling to make the decision legible or a demotion to Level 0. HITL is a control for the middle of the spectrum. It is not a universal solvent, and treating it as one is the original mistake.

The takeaway

"Is there a human in the loop?" is the wrong question, and it is dangerous precisely because it is so easy to answer yes.

The questions that matter are harder. Can the human see the decision, or just the data? Are they interrupted for reasons, or reflexively? Do they have a real "no"? Which autonomy level does this action actually belong at? And should it have been automated at all?

Human-in-the-loop is not a governance strategy. It is one control, useful in a specific band of risk, and only when it is designed so the human can actually govern. A person positioned to change nothing is not oversight. They are the place the accountability goes to disappear.

A Kalman Filter Is a Memory System

Goutham Nishkal Deepu EDA — Fri, 10 Jul 2026 20:14:19 +0000

Three problems that look unrelated:

A vibration sensor on a motor gives you a jittery reading every second. You want to know the actual wear on the bearing inside, which you can't measure directly.
An AI agent has a long conversation with a user. It has to decide what to remember and what to drop, or it either forgets what you told it or drowns in its own history.
A video model watches a ball roll behind a wall. When the ball reappears, the model has to know it's the same ball, that it existed the whole time, unseen.

These are usually filed under three different fields: signal processing, LLM engineering, and computer vision. But they are the same problem. All three come down to one question:

Given everything I've seen so far, and one new noisy observation, what do I now believe, and how much of my history do I keep versus throw away?

That question has a sixty-year-old answer that most people learn as control theory and never think about again: the Kalman filter. I want to show you that it isn't really a control-theory tool. It's the cleanest, oldest instance we have of a memory system. And once you see it that way, the connection to agent memory and video models stops being a metaphor and becomes the same math wearing different clothes.

No prior knowledge of Kalman filters or agent memory assumed. We'll build both from scratch.

The setup: a state you can't see

Start with the bearing. There's a hidden quantity you actually care about. Call it the wear, a number from 0 (brand new) to 1 (failed). You can't measure wear directly. You can only measure a proxy: vibration, current draw, temperature. Those readings correlate with wear, but they're noisy. Any single reading might be high just because the sensor twitched.

So you have two sources of information, and both are unreliable:

A model of how the world changes. Wear only goes up, and slowly. That's a prediction: "whatever the wear was last second, it's about the same now, maybe a hair higher."
A measurement. The sensor just gave you a number. It's informative, but noisy.

Naively, you could just trust the sensor and plot the raw readings. But that throws away everything you knew a moment ago. Or you could trust your model and ignore the sensor, but then you're not learning from reality at all.

The Kalman filter is the principled way to blend the two, weighting each by how much you trust it. And that weight is the whole story.

Two moves: predict and update

A Kalman filter holds two things:

x: its current best belief about the hidden state (the wear).
P: its uncertainty about that belief (how sure it is).

Every time step, it does two moves.

Predict. Carry the belief forward using the model of the dynamics. If wear persists, x stays roughly where it was. But uncertainty grows, because time passed and things could have drifted:

x = F * x          # carry the state forward
P = F * P * F + Q  # uncertainty grows by process noise Q

Update. A new measurement z arrives. Fold it in, but only partly, weighted by a factor K called the Kalman gain:

K = P / (P + R)        # how much to trust the measurement vs. your belief
x = x + K * (z - x)    # nudge belief toward the measurement, scaled by K
P = (1 - K) * P        # uncertainty shrinks, you just learned something

Look closely at K, because K is a memory knob.

R is the measurement noise, i.e. how unreliable the sensor is.
P is your current uncertainty.

If your belief is very uncertain (P large) relative to the sensor noise, K approaches 1: trust the new measurement, discard your prior. If your belief is confident (P small) and the sensor is noisy (R large), K approaches 0: keep your history, ignore the twitchy reading.

That's it. That's the entire mechanism. K is a continuously-adjusted answer to "how much of the past do I carry forward, and how much of this new observation do I let overwrite it?"

Watch it run

Here's a complete 1D filter tracking bearing wear from a noisy sensor. It runs as-is:

import numpy as np

np.random.seed(1)
T = 60
# True hidden wear: rises steadily toward failure (we don't get to see this)
true_wear = np.clip(np.linspace(0.05, 0.85, T), 0, 1)
# Noisy sensor: correlates with wear but jittery
measurements = true_wear + np.random.normal(0, 0.08, T)

x, P = 0.0, 1.0     # belief, and uncertainty in it
Q = 2e-3            # process noise: how much wear can drift per step
R = 0.08**2         # measurement noise: how noisy the sensor is
F = 1.0             # dynamics: wear persists

estimates, gains = [], []
for z in measurements:
    # PREDICT
    x = F * x
    P = F * P * F + Q
    # UPDATE
    K = P / (P + R)            # the memory knob
    x = x + K * (z - x)
    P = (1 - K) * P
    estimates.append(x)
    gains.append(K)

gains = np.array(gains)
print("gain, first 3 steps:", np.round(gains[:3], 3))   # -> [0.994 0.566 0.468]
print("gain, steady state :", round(gains[-1], 3))       # -> 0.424

The interesting output isn't the wear estimate. It's the gain trajectory: 0.994 → 0.566 → 0.468 → ... → 0.424.

On the very first step, the filter knows nothing (P is huge), so K ≈ 0.99: it essentially adopts the first measurement wholesale. It has no memory yet, so it trusts the sensor completely. Then, step by step, as it accumulates history, P shrinks and the gain settles toward 0.42. At steady state it says: blend about 42% of each new reading with 58% of what I already believed.

That settling curve is the memory forming. A system with no history trusts the present entirely. A system with accumulated belief holds its ground and treats new data as a partial correction. The filter cuts the tracking error roughly in half versus the raw sensor, not by having a better sensor, but by remembering.

The same shape, three times

Now the payoff. Hold that structure in your head (a belief carried forward, a new observation folded in, a gain deciding the mix) and look at the other two problems.

Agent memory

An AI agent in a long conversation is running the same loop, informally. Its "state" is its working understanding of you: your goals, your preferences, the facts you've established. Each new message is a noisy measurement, noisy because a single message can be sarcastic, a typo, a one-off, or a genuine lasting signal.

A naive agent that just embeds every message and retrieves by similarity has no gain. It treats every observation as equally weighted, forever. That's why it surfaces a preference you abandoned months ago, or lets one stray message overwrite a stable fact. It has storage, not memory.

A real memory system needs the equivalent of K: a judgment about how much each new message should update the persistent picture versus how much accumulated history to preserve. Promote the durable, down-weight the transient, and, crucially, let uncertainty decay so old, unconfirmed beliefs loosen their grip. That's a Kalman gain in disguise.

Video object permanence

A video model watching that ball roll behind a wall has a hidden state too: what objects exist in this scene and where. Each frame is a measurement. When the ball is occluded, there's no measurement for it, and this is exactly the predict step with no update. A model with real state carries the ball forward through the occlusion (x = F * x), holds its position with growing uncertainty (P grows), and re-acquires it when it reappears.

A model without persistent state does the opposite: with no measurement, the ball ceases to exist, and when it reappears the model hallucinates a fresh object or invents a physics story to explain the "teleport." That failure mode is well documented in current video LLMs. It's not a perception failure. It's a missing predict step, no memory to carry the object through the moment it couldn't be seen.

Object-centric architectures (slot attention) and state-space models (Mamba and kin) are, in effect, learned generalizations of this same predict/update loop, one keeping a slot per object, the other keeping a compressed running state, both deciding per-step what to write and what to ignore. Mamba's "selective" update, where the model learns what to fold into state and what to skip, is the Kalman gain grown up and made learnable.

Where the analogy breaks (the honest part)

If I stopped here I'd be overselling it, so here's where the equivalence is real and where it's a useful loose metaphor.

Real: the structure is genuinely shared. Predict-then-update, a persistent belief with quantified uncertainty, and a gain that trades history against observation. That recurrence shows up in all three, and it's not a coincidence. It's what optimal recursive estimation looks like.

Loose: the classic Kalman filter assumes linear dynamics and Gaussian noise. Bearing wear is roughly fine with that. Conversations and video are not. The state is high-dimensional, the dynamics are nonlinear, the noise isn't Gaussian. LLMs and video models do not literally compute a Kalman gain. They learn something functionally analogous through attention and gating, which is far more expressive and far less interpretable. The extended and unscented Kalman filters stretch the math toward nonlinearity, but nobody's running a literal EKF inside a transformer.

So the claim isn't "these systems are Kalman filters." The claim is that the Kalman filter is the simplest, most transparent member of a family, and studying it teaches you the question every member of that family must answer. When you understand why the gain settles, you understand what agent memory and video permanence are reaching for, and why "just store everything and retrieve by similarity" was never going to be memory.

The takeaway

Memory is not storage. Storage is keeping everything. Memory is judgment about what to keep: carrying a belief forward, weighing each new observation against it, and letting uncertainty decide the mix.

The Kalman filter is the oldest clean instance of that judgment we have. It's sixty years old, it's twenty lines of Python, and it's quietly the same thing the newest agent-memory stacks and video world-models are trying to relearn at scale.

If you build agents, the filter is worth an afternoon. Not because you'll implement one (you won't) but because it makes one question concrete and unforgettable: for every new thing your system sees, what is it keeping, and what is it letting go?

If you found this useful, the same lens (hidden state, noisy observation, what to carry forward) is how I think about predictive maintenance on industrial machinery, where the "hidden state" is a machine's health and the "measurement" is its power signature. Different domain, identical question.

Stop Building MCP Wrappers — Build Domain-Specific Tools Instead

Goutham Nishkal Deepu EDA — Tue, 23 Jun 2026 15:16:53 +0000

A few weeks ago, Pinterest engineering published numbers from their production MCP deployment: ~66,000 monthly tool invocations, 844 active users, an estimated 7,000 engineering hours saved per month. (source)

What stood out wasn't the scale. It was what they didn't skip — every server passed security, legal, privacy, and compliance review before going to production. Sensitive operations required human approval.

That's the part most MCP tutorials skip. Most guides show you how to wrap an API in five minutes. Almost none show you how to design a tool that's actually safe and useful for an AI agent to call autonomously.

This post walks through that gap — using a generic incident/log-analysis domain as the example — with working FastMCP 3.x code.

The wrapper instinct

The fastest way to build an MCP server is to take an existing API and expose every endpoint as a tool, 1:1. It looks something like this:

from fastmcp import FastMCP

mcp = FastMCP("incidents")

@mcp.tool
def get_incident(incident_id: str) -> dict:
    """Fetch a single incident by ID."""
    return db.query("SELECT * FROM incidents WHERE id = ?", incident_id)

@mcp.tool
def list_incidents() -> list[dict]:
    """List all incidents."""
    return db.query("SELECT * FROM incidents")

@mcp.tool
def update_incident(incident_id: str, status: str) -> dict:
    """Update an incident's status."""
    return db.execute("UPDATE incidents SET status = ? WHERE id = ?", status, incident_id)

This works. It'll pass a demo. It's also exactly the pattern that causes problems in production:

No domain semantics. The model has to infer what "status" values are valid, what counts as a duplicate incident, what severity actually means in your system — none of that is encoded anywhere.
No governance. update_incident can be called with zero friction. An agent that misreads a request can silently change production state.
Context bloat. One developer building on GitHub's MCP server described it as dumping over 40 tools into context before doing anything — which measurably degrades agent performance, since the model has to reason over every tool description on every turn.

A thin 1:1 wrapper is a fast way to get a demo. It is rarely the right shape for a tool an agent calls unsupervised.

Designing a domain-specific tool instead

The alternative isn't more tools — it's fewer, smarter tools that encode the judgment a domain expert would apply by hand.

Here's the same incident-analysis domain, redesigned:

from fastmcp import FastMCP
from pydantic import BaseModel, Field
from enum import Enum
from datetime import datetime, timedelta

mcp = FastMCP("incident-analysis")

class Severity(str, Enum):
    LOW = "low"
    MEDIUM = "medium"
    HIGH = "high"
    CRITICAL = "critical"

class IncidentSummary(BaseModel):
    total: int
    by_severity: dict[str, int]
    likely_duplicates: list[str] = Field(
        description="Incident IDs that may be duplicates based on time/error-signature clustering"
    )
    needs_human_review: bool


@mcp.tool
def summarize_recent_incidents(
    hours: int = 24,
    min_severity: Severity = Severity.MEDIUM,
) -> IncidentSummary:
    """
    Summarize incidents from the last N hours at or above a severity threshold.

    Applies domain logic to flag likely duplicates (same error signature within
    a 10-minute window) rather than returning raw rows for the model to interpret.
    Returns needs_human_review=True if any CRITICAL incidents are unresolved,
    signaling the caller should not auto-close or auto-triage without a human.
    """
    cutoff = datetime.utcnow() - timedelta(hours=hours)
    rows = db.query(
        "SELECT * FROM incidents WHERE created_at >= ? AND severity >= ?",
        cutoff, min_severity.value
    )

    duplicates = _cluster_by_signature(rows, window_minutes=10)
    has_unresolved_critical = any(
        r["severity"] == "critical" and r["status"] != "resolved" for r in rows
    )

    return IncidentSummary(
        total=len(rows),
        by_severity=_count_by_severity(rows),
        likely_duplicates=duplicates,
        needs_human_review=has_unresolved_critical,
    )


@mcp.tool
def propose_incident_resolution(incident_id: str) -> dict:
    """
    Propose (but do not apply) a resolution for an incident based on
    similar past incidents and their resolutions.

    This tool is read-only by design. It never mutates incident state —
    use apply_resolution() separately, which requires explicit human
    confirmation, to actually close anything out.
    """
    incident = db.query_one("SELECT * FROM incidents WHERE id = ?", incident_id)
    similar = _find_similar_resolved(incident, limit=3)
    return {
        "incident_id": incident_id,
        "proposed_resolution": _summarize_resolution_pattern(similar),
        "based_on": [s["id"] for s in similar],
        "confidence": _resolution_confidence(similar),
    }


@mcp.tool
def apply_resolution(incident_id: str, resolution_note: str, confirmed_by_human: bool) -> dict:
    """
    Apply a resolution to an incident. Requires confirmed_by_human=True.

    This is the only tool in this server that mutates incident state.
    It exists separately from propose_incident_resolution() so that an
    agent can never go from "read" to "write" in a single unsupervised call.
    """
    if not confirmed_by_human:
        raise ValueError(
            "apply_resolution requires confirmed_by_human=True. "
            "Use propose_incident_resolution() first and surface it to a person."
        )
    return db.execute(
        "UPDATE incidents SET status='resolved', resolution=? WHERE id=?",
        resolution_note, incident_id
    )

A few things changed, deliberately:

Domain logic moved into the tool, not the prompt. "What counts as a likely duplicate" is a judgment call specific to this domain — clustering by error signature within a time window. Encoding it in the tool means every caller gets the same correct answer instead of the model re-deriving (or guessing at) the logic every time.

Read and write are different tools. propose_incident_resolution can never mutate anything — it's structurally read-only. apply_resolution is the single narrow path to a state change, and it refuses to run without an explicit human-confirmation flag. This is a simplified version of the human-in-the-loop pattern Pinterest's writeup describes for sensitive operations.

Return types are structured, not raw rows. The IncidentSummary Pydantic model gives the agent (and you) a typed, predictable contract — and the needs_human_review flag does some of the model's reasoning for it, rather than hoping it infers urgency correctly from a list of dicts.

Three tools, not three-times-N. Instead of exposing every table operation, this server exposes three tools that map to how a human on-call engineer actually thinks: "what's going on," "what would I do about it," "okay, do that." Fewer tools in context, each carrying more domain weight.

Why this matters more than the protocol choice

MCP itself is becoming infrastructure — it went from an internal Anthropic spec to a Linux Foundation standard backed by OpenAI, Google, and Microsoft in about 16 months. (source) That convergence means the protocol layer is rapidly commoditizing. Every team will have access to the same transport, the same SDKs, the same client support.

What won't commoditize is tool design. The difference between a server that's safe to hand to an autonomous agent and one that isn't comes down to exactly the choices above — what's read-only, what requires confirmation, what domain logic gets encoded once instead of re-derived every call.

If you're building an MCP server right now, the protocol decisions are mostly made for you. The judgment calls aren't.

Quick start, if you want to try this yourself

uv add fastmcp

# server.py — minimal runnable version
from fastmcp import FastMCP

mcp = FastMCP("incident-analysis")

@mcp.tool
def ping() -> str:
    """Health check."""
    return "pong"

if __name__ == "__main__":
    mcp.run()

fastmcp dev server.py

That spins up the MCP Inspector so you can see raw tool calls and responses before wiring it into Claude Desktop, Cursor, or any other MCP client.

This is a companion piece to a short series I've been writing on LinkedIn about what's actually missing in how organizations adopt AI — from training-time limitations to why "owning" your AI capabilities means doing the unglamorous design work, not just picking a model.