MCP SERVERS
// 2 custom-built · 10+ integrated · TypeScript + Zod · typed bridges from Claude to any tool
What MCP actually is
MCP — Model Context Protocol is Anthropic's open standard for how AI clients talk to tools. A server exposes named tools with typed inputs; any MCP-capable client calls them like functions, and the contract stays the same if I swap the model underneath.
The MCP landscape
Two servers I built from scratch; the rest are official, vendor, or community servers I wire in. Each turns a system into a typed surface Claude can query and drive, and the agent treats them all the same.
Make.com MCP
19 tools · 5 groupsA TypeScript bridge into Make.com's REST API — scenarios, blueprints, executions, data, orgs & teams. n8n is my primary automation runtime now, but the server stays maintained so Claude keeps a typed handle on the Make workspace.
github.com/luccafaust/make-mcp-server
Second Brain MCP
9 tools · Obsidian vaultA custom server over my Obsidian vault. Nine tools — search, recall, read, write, update, query, context, link, skill — let Claude read and write across 140+ atomic notes, keeping the knowledge base alive between sessions.
~/Documents/second-brain/.mcp-server/
Non-exhaustive — the set grows as new servers ship. Because every integration speaks MCP, adding a new one is a mcpServers config entry, not a code change.
Request Lifecycle
The Make.com server is a REST wrapper with good types — not the fanciest of the two I built, but the cleanest way to trace an MCP request from prompt to response.
Pick an MCP, inspect its surface
Every server uses the same contract — Zod-validated params in, structured content out — only the verbs differ. The Make tab gets the full schema inspector; the others just list their verbs.
The full inspector — 19 tools across 5 API domains. Click a tool to see its real Zod schema and response. n8n runs the orchestration now, but this server stays Claude's read/write surface into the Make workspace.
make_list_scenarios
List all scenarios in the team. Optionally filter by folder.
z.object({folder_id: z.number().optional(),})
{"folder_id": 12345}
{"scenarios": [{ "id": 1, "name": "Lead Notification", "isActive": true },{ "id": 2, "name": "Weekly Report", "isActive": false }]}
Live Request
A complete MCP tool call end-to-end — from Claude prompt through Zod validation to the Make.com API response. The Second Brain server does the same shape against an Obsidian vault instead of a REST API.
Tools Shipped
Custom Servers
Type-Safe
Client-Integrated
Architecture
Both servers are long-lived TypeScript processes on the official @modelcontextprotocol/sdk, with a thin adapter per target. Make wraps a REST API as 19 tools across 5 groups; Second Brain wraps an Obsidian vault as 9. Every input is Zod-validated before it runs, so a bad call fails here, not in the API.
The SDK handles transport, capability negotiation, and schema export, so the server code is just business logic. Claude Code finds the servers through the mcpServers config block and exposes each tool to the model as a callable function.
Same shape, different targets
Both servers register tools with server.registerTool() — a Zod schema and an async handler. The target changes from a REST API to on-disk Markdown, but the contract every MCP client sees stays identical.
server.registerTool(
"make_list_scenarios",
{
title: "List Make Scenarios",
description: "List all scenarios in the Make.com team.",
inputSchema: {
folder_id: z.number().optional().describe("Filter by folder ID"),
},
annotations: {
readOnlyHint: true,
idempotentHint: true,
openWorldHint: true,
},
},
async ({ folder_id }) => {
let path = `/scenarios?teamId=${TEAM_ID}`;
if (folder_id !== undefined) path += `&folderId=${folder_id}`;
const result = await makeApiRequest(path);
return {
content: [{ type: "text", text: JSON.stringify(result, null, 2) }],
};
}
);server.tool(
"vault_query",
"Strukturierte Abfrage per Frontmatter-Felder.",
{
type: z.string().optional().describe("decision | learning | skill | ..."),
project: z.string().optional().describe("Projektname"),
status: z.string().optional().describe("active | archived | draft"),
tags: z.array(z.string()).optional().describe("mind. einer muss matchen"),
since: z.string().optional().describe("Nur Notes seit Datum (YYYY-MM-DD)"),
},
async ({ type, project, status, tags, since }) => {
const results = queryNotes(VAULT_PATH, { type, project, status, tags, since });
const summary = results.map(n => ({
path: n.path,
title: n.title,
frontmatter: n.frontmatter,
}));
return {
content: [{ type: "text", text: JSON.stringify({ results: summary }, null, 2) }],
};
}
);How These Servers Are Built
- →MCP SDK over a custom protocol
A standard protocol means any agent can use the server, not just Claude Code. The SDK handles transport and serialization, so I only write business logic.
- →Zod for runtime validation
TypeScript types help while I write the code; Zod catches bad inputs at runtime before they hit the API. Both come from the same schema, so they never drift apart.
- →Tool groups over a flat list
Past a handful of tools, a flat list gets unusable. On Make the 19 tools group by API domain — Scenarios, Blueprints, Executions, Data, Orgs & Teams — which keeps the surface easy to scan.
- →Build only what no server covers
Make.com and my Obsidian vault had no usable MCP option, so I built them. Asana, Linear, Notion, and Figma already have servers I just wire in.
- →Tool descriptions are part of the contract
The
.describe()on each Zod field is what the model reads to decide when to call a tool. A vague one makes the agent guess, so I write them as carefully as the schemas. - →Structured errors over thrown exceptions
When the API rate-limits or times out, the server returns a structured MCP error with a code and retry hint, so the agent can back off or escalate instead of choking on a raw stack trace.
- →Resources and tools, not just tools
MCP splits read-only resources from action-taking tools. The Second Brain server exposes the vault index as a resource and keeps writes as tools, which makes browsing cheap and side effects explicit.
- →One server per domain
The Make server speaks Make; the vault server speaks the vault. One monolithic “all my tools” server would let a single bug take everything down and bloat the surface Claude has to reason over.