DEV Community: Namish Saxena

What I Found When I Stopped Performing My Career

Namish Saxena — Thu, 02 Apr 2026 12:11:18 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

I used to scroll LinkedIn and feel something I could not name for a long time.

Gutted is close. Not by the people. By the system we had all quietly agreed to. The over-selling of things that did not exist yet. The grief packaged as a lesson before it had been felt. The wins announced before the work was done. The performed humility that somehow always ended in a call to action.

And I understood it. That is the part I could never shake.

I understood it because I was doing it too. Not dishonestly. But with that constant low hum of awareness, of calibration. How does this land. Who is watching. Is this the right kind of visible.

Who was I to judge anyone. We were all just trying to stay real inside a system that had made performance the price of belonging.

So in 2023, I built something. A startup to reimagine professional networking. Built from that gutted feeling. Built because I believed something more honest was possible.

And for a while, that felt like enough.

Then, in early 2024, my father died.

I will not try to describe that here. Some things do not need formatting.

What I will say is this: when you lose someone at the center of your world, the performance stops. Not by choice. It just stops. The calibration goes quiet. The audience disappears, or stops mattering, or both. You are left with only what is actually there.

The startup wound down. Direction did too.

For a while, I was not building toward anything.

I was just present. Quietly. Without an arc.

What came after surprised me.

I came back to the work. But something had shifted underneath it.

Not the skill. Not the ambition. Something quieter than those. A different relationship to why.

I started solving problems that nobody was photographing. The unglamorous ones. The ones that just needed doing because they were real, not because solving them would look good.

AI agents were drowning in context. Every team building with them was creating bloated files, thousands of lines of documentation loaded into every session, mostly wasted. I built something to fix that. Scoped. Queryable. Focused. Lore.

MCP servers had no standard way to describe themselves. REST had OpenAPI. MCP had nothing. So I built mcpspec. A spec format. Interactive docs. A small piece of infrastructure that other builders could stand on.

I put both in the open. No launch. No announcement. No carefully timed reveal.

Just a README. And the quiet hope that someone, somewhere, finds it useful.

That hope felt different from the old one. The old hope had an audience in it. This one did not.

Twenty years in enterprise technology teaches you to recognise the shape of a hype cycle. The breathless keynote. The consultancy deck that arrives six months after the builders already knew. The race to announce before you have understood.

I have watched this happen with SOA, with cloud, with digital transformation, with AI. Each wave the same. Each wave louder than the last.

And in every single one, the builders who actually moved the work forward mostly did it quietly. In the background. Without the narrative. Solving the problems nobody was photographing.

I had always admired those people.

After my father died, I became a little more like them.

I am not writing this as someone who solved something.

I am writing it as someone who stopped pretending a problem did not exist.

Tech has a performance problem. And I do not mean system performance. I mean the way we have made visibility the measure of value. The way we reward the announcement over the execution. The way certain voices learn early that they will need to be twice as loud to be heard half as well, and so they master the performance out of necessity, and then they are exhausted by it, and then they leave.

The filter is not always dramatic. It is often just this: the work is real but the room does not see it. And if you cannot perform the work loudly enough, the room decides the work is not there.

I have watched this take people. Quietly. Without ceremony.

I do not have a formula for any of this.

What I have is this:

The builder who ships something useful and goes to bed without announcing it. That matters.

The engineer who writes the honest post-mortem instead of the polished retrospective. That matters.

The practitioner who shares what they actually know, without waiting for the right moment or the right audience or the right number of followers. That matters.

You do not have to announce your journey to be on one.

I am still learning this. Some weeks I get it right.

Some weeks I reach for the frame before the feeling has settled. Before I have actually lived the thing I am about to describe.

But the work itself, the actual building, is more honest than it has ever been.

And I am still here.

Not better.
Not more resonant.
Not healed.

Just here.

And for now, that is the most true thing I know how to say.

I have been thinking and writing about performance culture for a while now. The cost of it. The shape of it. What we find when we stop. If that is something you are sitting with, I would be glad to hear from you. You can find me at namishsaxena.com.

How to generate docs for your MCP server in 30 seconds

Namish Saxena — Wed, 01 Apr 2026 14:04:02 +0000

You built an MCP server. Now someone asks: "What tools does it expose?"

And you point them at a README. Or tell them to run tools/list and stare at raw JSON. Or you copy-paste the schema into a doc that will drift from reality within a week.

There's a better way. Here's how to get this instead:

Install

# TypeScript
npm install @mcpspec-dev/typescript

# Python
pip install mcpspec-dev

Add one line to your server

TypeScript:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { mcpspec } from "@mcpspec-dev/typescript";

const server = new McpServer({ name: "my-server", version: "1.0.0" });

// Your existing tools, resources, prompts — untouched

const app = mcpspec(server, {
  info: { title: "My MCP Server", version: "1.0.0" },
});

app.listen(3000);

Python (FastMCP):

from mcp.server.fastmcp import FastMCP
from mcpspec_dev import McpSpec

mcp = FastMCP("my-server")

# Your existing tools — untouched

spec = McpSpec(mcp, info={"title": "My Server", "version": "1.0.0"})
mcp.run(transport="streamable-http")

That's it. Your server now has three new endpoints.

What you get

/docs — interactive HTML documentation. Dark, light, and high-contrast themes. Collapsible tool/resource/prompt groups. Every input schema rendered with copy-to-clipboard. Generated automatically from what your server actually exposes, so it never drifts.

/mcpspec.yaml — a machine-readable spec in a standardized format. This is the portable artifact: commit it to your repo, feed it to a registry, use it for contract testing, hand it to a security team for audit.

/mcp — your original MCP endpoint, proxied through. Existing clients keep working with zero changes.

A complete example

Here's a real task manager server wired up with MCPSpec:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { mcpspec } from "@mcpspec-dev/typescript";
import { z } from "zod";

const server = new McpServer({ name: "task-manager", version: "1.0.0" });

server.tool("create_task", "Create a new task", {
  title: z.string().describe("Task title"),
  description: z.string().optional().describe("Optional details"),
  priority: z.enum(["low", "medium", "high"]).default("medium"),
}, async ({ title, description, priority }) => {
  // ... your implementation
  return { content: [{ type: "text", text: `Task created: ${title}` }] };
});

server.tool("list_tasks", "List all tasks", {
  status: z.enum(["pending", "done", "all"]).default("all"),
}, async ({ status }) => {
  // ... your implementation
  return { content: [{ type: "text", text: "[]" }] };
});

const app = mcpspec(server, {
  info: {
    title: "Task Manager",
    version: "1.0.0",
    description: "Create and track tasks via MCP",
    repository: "https://github.com/you/task-manager",
    license: "MIT",
  },
  groups: {
    "Tasks": ["create_task", "list_tasks"],
  },
  examples: {
    create_task: [{
      title: "Create a high-priority task",
      input: {
        title: "Fix production bug",
        description: "Users seeing 500 errors on /api/checkout",
        priority: "high",
      },
    }],
  },
});

app.listen(3000, () => {
  console.log("Docs: http://localhost:3000/docs");
  console.log("Spec: http://localhost:3000/mcpspec.yaml");
});

Groups let you organize tools into sections in the docs UI. Examples show up inline next to each tool's schema. Both are optional — the bare minimum is just info.title and info.version.

The spec file

The /mcpspec.yaml output looks like this:

mcpspec: 0.1.0
$schema: "https://mcpspec.dev/schema/0.1.0.json"
info:
  name: task-manager
  version: "1.0.0"
  title: Task Manager
  description: Create and track tasks via MCP
tools:
  - name: create_task
    description: Create a new task
    inputSchema:
      type: object
      properties:
        title:
          type: string
          description: Task title
        priority:
          type: string
          enum: [low, medium, high]
          default: medium
      required: [title]
  - name: list_tasks
    description: List all tasks
    inputSchema:
      type: object
      properties:
        status:
          type: string
          enum: [pending, done, all]
          default: all
resources: []
prompts: []

Commit this file to your repo. Now any agent, tool, or developer can understand your server's surface area without running it.

Filtering sensitive tools

Not every tool should be public. Use exclude with glob patterns to keep internal capabilities out of the spec:

const app = mcpspec(server, {
  info: { title: "My Server", version: "1.0.0" },
  exclude: ["internal_*", "admin_*"],
});

Or use include for allowlist mode — only the tools you explicitly name appear in the docs:

const app = mcpspec(server, {
  info: { title: "My Server", version: "1.0.0" },
  include: ["get_*", "list_*", "search_*"],
});

MCPSpec introspects via in-memory transport and only calls tools/list, resources/list, and prompts/list. It never executes tools or reads resource content. Your auth layer is completely bypassed during introspection — which means the docs endpoint stays accessible even when the MCP endpoint requires a token.

Python (low-level Server API)

If you're not using FastMCP:

from mcp.server.lowlevel import Server
from mcpspec_dev import McpSpec
import uvicorn

server = Server("my-server")

# Register tools via @server.list_tools(), @server.call_tool(), etc.

spec = McpSpec(server, info={"title": "My Server", "version": "1.0.0"})
app = spec.create_app()
uvicorn.run(app, port=3000)

Why this exists

REST APIs had the same problem before OpenAPI. Every API was documented in its own format, or not at all. OpenAPI didn't fix a broken ecosystem — it gave a working one a standard that unlocked everything else: code generators, interactive explorers, contract tests, API registries.

MCP hit 10,000 public servers in under two years. The protocol is solid. But right now every server describes itself differently, or not at all. mcpspec.yaml is the portable spec format that changes that.

The project is MIT licensed. TypeScript on npm, Python on PyPI, source on GitHub.

If you try it and something's missing, open an issue. The spec format is at v0.1.0 — early enough that real usage shapes what it becomes.