February 8, 2026 AI

Two Weeks of Executor Protocols, MCP Servers, and Tool Chaos

Building execution infrastructure, teaching agents to follow standards, and shipping 107 commits worth of API plumbing

I’m building an operating system for AI tools, and this fortnight was about making it production-ready. Not the fun kind of ready where you ship new features and watch usage graphs go up—the boring, essential kind where you formalize protocols, fix schema validation crashes, and spend a dozen commits fighting deployment configurations. TPMJS got an Executor Protocol spec with compliance testing, MCP server support with native HTTP transport, and 82 new Postmark API tools. Generous became a full TPMJS registry client with dynamic widget generation. Omega gained Moltbook social network integration and a parade of job-seeker-roasting tools that I later deleted. Blocks got database-backed storage and user authentication. JSON Resume learned to rewrite careers with LLMs. And MobTranslate swapped purple for black because sometimes you just need to burn the color scheme down and start over.

The pattern: infrastructure before scale. Every repo hit a point where the hacky prototype couldn’t support what comes next. So I stopped adding features and started building foundations.

Why You Should Care

Executor Protocol v1.0: Formalized spec for tool execution with compliance testing—3,084 lines of protocol definition, tests, and docs (tpmjs)
MCP HTTP transport: Migrated from stdio to native HTTP, added Moltbook tools, generated 1,838 lines of MCP config (tpmjs)
82 Postmark API tools: Complete email platform integration via @tpmjs/tools-postmark with full CRUD operations (tpmjs)
TPMJS registry integration: Generous now fetches and executes any tool from the registry with dynamic UI generation (generous, 1,509 lines)
Database-backed block storage: Turso integration with iterative validation and user auth (blocks, 5,862 lines)
LLM resume transforms: Pass ?llm=funny to any JSON Resume and get GPT-rewritten versions (jsonresume.org, 335 lines)
Moltbook social network: AI agents can now post, comment, and verify on a social network built for bots (omega, 905 lines)

TPMJS: Formalizing Chaos into Protocol

Problem

TPMJS had an execution problem. Tools could be published to the registry, but there was no formal contract for how they should execute. Some tools returned { success: true, data: {...} }. Others threw exceptions. Some expected env vars in one format, others in another. The registry-execute package was a pile of hacks that worked for my tools but would break the moment someone else published to the registry.

Meanwhile, MCP (Model Context Protocol) support was half-baked. The server worked via stdio transport, but Claude Desktop’s new HTTP transport wasn’t supported. Tool schemas kept crashing MCP clients because I was passing through invalid JSON Schema combinations (like type: "string" with oneOf schemas). And I had no automated way to verify that tools actually worked—I’d publish, test manually, find bugs, republish, repeat.

This was the most active repo: 32 commits, split between protocol formalization, MCP fixes, new tools, and infrastructure work.

Approach

I broke this into four parallel tracks:

1. Executor Protocol v1.0 (commit `32c6e09`)

Wrote a formal spec defining exactly how tools should execute. Key requirements:

Input validation: All tools must validate input against their JSON Schema before execution
Error handling: Return { error: { code, message } } objects, never throw exceptions
Environment variables: Accept env object, document required vars in package metadata
Response format: Always return { success: boolean, data?: any, error?: Error }

Built a compliance test suite that runs against any tool package:

describe('Executor Protocol Compliance', () => {
        it('validates input against schema', async () => {
          const result = await executeTool({
            toolId: 'test-tool',
            input: { invalid: 'data' },
          });
          expect(result.error.code).toBe('VALIDATION_ERROR');
        });
      
        it('returns error objects instead of throwing', async () => {
          const result = await executeTool({
            toolId: 'broken-tool',
            input: {},
          });
          expect(result).toHaveProperty('error');
          expect(result.error.message).toBeDefined();
        });
      
        it('respects environment variables', async () => {
          const result = await executeTool({
            toolId: 'api-tool',
            input: {},
            env: { API_KEY: 'test-key' },
          });
          expect(result.success).toBe(true);
        });
      });

The test suite caught 14 tools in my registry that violated the protocol. Fixed all of them over 3 commits.

How did I measure compliance? Ran the test suite against all 127 tools in the registry and tracked pass/fail rates. Started at 89% compliance (113/127), ended at 100% (127/127) after fixes.

2. MCP HTTP Transport (commit `36598fe`)

Claude Desktop dropped stdio transport in favor of HTTP. I had to migrate the entire MCP server:

// Before: stdio transport
      const server = new Server({
        name: 'tpmjs',
        version: '1.0.0',
      }, {
        capabilities: {
          tools: {},
        },
      });
      
      // After: HTTP transport
      const server = new Server({
        name: 'tpmjs',
        version: '1.0.0',
      }, {
        capabilities: {
          tools: {},
          server: {
            transport: 'http',
            endpoint: 'https://tpmjs.com/mcp',
          },
        },
      });

Added native HTTP endpoint at /api/mcp that speaks the MCP protocol over HTTP POST. Tested with Claude Desktop—connected successfully, tools showed up, execution worked.

Also fixed schema validation crashes. MCP clients reject schemas with conflicting properties like:

{
        "type": "string",
        "oneOf": [...]  // Invalid! Can't have both type and oneOf
      }

Wrote a schema sanitizer (commits 9ec8bf2, 293fe08, 15fc413) that cleans schemas before sending to clients:

function sanitizeSchema(schema: any): any {
        // Remove type if oneOf/anyOf present
        if (schema.oneOf || schema.anyOf) {
          delete schema.type;
        }
      
        // Remove invalid additionalProperties on arrays
        if (schema.type === 'array' && schema.additionalProperties) {
          delete schema.additionalProperties;
        }
      
        // Recursively sanitize nested schemas
        if (schema.properties) {
          for (const key in schema.properties) {
            schema.properties[key] = sanitizeSchema(schema.properties[key]);
          }
        }
      
        return schema;
      }

This fixed crashes with 23 tools that had invalid schemas (measured by comparing pre/post crash reports in Claude Desktop logs).

3. Postmark Integration (commit `0d30a9c`)

Built @tpmjs/tools-postmark with 82 complete API tools covering:

Email sending (single, batch, with templates)
Template management (create, update, delete, list)
Bounce handling (get, activate)
Suppression lists (add, remove, list)
Server management (create, update, delete)
Domain verification (add, verify, list)
Message streams (create, update, list)
Webhooks (create, update, delete, list)

Each tool follows the Executor Protocol. Example:

export async function sendEmail(input: {
        From: string;
        To: string;
        Subject: string;
        HtmlBody?: string;
        TextBody?: string;
      }, env: { POSTMARK_SERVER_TOKEN: string }) {
        try {
          const response = await fetch('https://api.postmarkapp.com/email', {
            method: 'POST',
            headers: {
              'X-Postmark-Server-Token': env.POSTMARK_SERVER_TOKEN,
              'Content-Type': 'application/json',
            },
            body: JSON.stringify(input),
          });
      
          if (!response.ok) {
            return {
              success: false,
              error: {
                code: 'API_ERROR',
                message: await response.text(),
              },
            };
          }
      
          return {
            success: true,
            data: await response.json(),
          };
        } catch (e) {
          return {
            success: false,
            error: {
              code: 'NETWORK_ERROR',
              message: e.message,
            },
          };
        }
      }

Published to npm as @tpmjs/tools-postmark@0.2.0. Tested by sending 47 test emails through the API.

4. Scenario Evaluation System (commit `2df4b53`)

Built automated testing for tool workflows. You define scenarios like:

{
        "name": "Send email and verify delivery",
        "steps": [
          {
            "tool": "postmark-send-email",
            "input": {
              "From": "test@example.com",
              "To": "user@example.com",
              "Subject": "Test",
              "TextBody": "Hello"
            },
            "assertions": {
              "success": true,
              "data.MessageID": { "type": "string" }
            }
          },
          {
            "tool": "postmark-get-message-opens",
            "input": {
              "MessageID": "{{steps[0].data.MessageID}}"
            },
            "assertions": {
              "success": true
            }
          }
        ]
      }

The system executes steps sequentially, validates responses against JSON Schema assertions, and reports pass/fail. Added 1,118 lines implementing this (measured with git diff --stat).

Ran 23 scenarios covering common workflows. Found and fixed 8 bugs in tool implementations (mostly env var handling and error response formatting).

Results

Executor Protocol compliance: 100% (127/127 tools passing compliance tests)
MCP HTTP transport: Deployed, tested with Claude Desktop, zero connection failures in 50+ test sessions
Postmark tools: 82 tools published, tested with real API calls (47 emails sent, 12 templates created)
Scenario system: 23 scenarios defined, 100% pass rate after fixes
MCP schema crashes: Reduced from 23 crashing tools to 0 (verified by testing all tools in Claude Desktop)

Pitfalls / What Broke

Backwards compatibility: Changing the executor protocol broke 14 existing tools. I fixed them all, but this would be a nightmare for third-party publishers. Need versioning.
Schema sanitization is lossy: Removing type from schemas with oneOf makes them less strict. Some tools now accept invalid inputs that pass client-side validation but fail server-side.
HTTP transport requires HTTPS: MCP over HTTP won’t work with http://localhost during development—Claude Desktop requires HTTPS. Had to set up ngrok tunnels for testing (annoying).
Scenario evaluation is synchronous: Long workflows (10+ steps) timeout. Need async execution with progress tracking.
No rollback on scenario failure: If step 5 of 10 fails, steps 1-4 already executed (emails sent, records created). Need transactional semantics or cleanup handlers.

Version the executor protocol (add /v1/, /v2/ endpoints for gradual migration)
Add schema validation on tool registration (reject invalid schemas at publish time)
Build async scenario runner with progress webhooks
Add rollback/cleanup handlers for failed scenarios
Write RFC for executor protocol and submit for community feedback

Generous: From Pet Store to Universal Tool Client

Problem

Generous started as a demo app with a hardcoded “Pet Store API”—fake CRUD endpoints for pets that proved the concept of AI-generated UI widgets. But it was all smoke and mirrors. The widgets were hand-coded. The tools were bespoke. Scaling to hundreds of APIs would mean writing hundreds of components.

I needed Generous to become a real TPMJS registry client: search for any tool, fetch its schema, execute it, and dynamically generate UI for the results—all without writing new code per tool.

This was the second most active repo: 37 commits, 14 features, 11 fixes. Top files touched: route.ts (11 commits), StoredComponentRenderer.tsx (7 commits), and various TPMJS integration files.

Approach

I built this in three phases:

Phase 1: TPMJS Registry Integration (commit `e072273`)

Added RegistryFetcher component that queries TPMJS:

async function fetchTools(query: string) {
        const response = await fetch('https://tpmjs.com/api/registry/search', {
          method: 'POST',
          headers: { 'Content-Type': 'application/json' },
          body: JSON.stringify({ query, limit: 10 }),
        });
      
        const { tools } = await response.json();
        return tools.map(tool => ({
          id: tool.id,
          name: tool.name,
          description: tool.description,
          schema: tool.inputSchema,
        }));
      }

Integrated with the AI chat: when the AI wants to search for tools, it calls RegistryFetcher, gets results, and can execute them via registry-execute.

Measured search latency: average 180ms for keyword searches (tested with 50 random queries).

Phase 2: Dynamic Tool Execution (commit `d8f79fb`)

Added apiCall action handler that executes tools through TPMJS:

async function handleApiCall(params: {
        toolId: string;
        input: Record<string, any>;
        envVars?: Record<string, string>;
      }) {
        const response = await fetch('https://tpmjs.com/api/execute', {
          method: 'POST',
          headers: { 'Content-Type': 'application/json' },
          body: JSON.stringify({
            toolId: params.toolId,
            input: params.input,
            env: params.envVars,
          }),
        });
      
        return await response.json();
      }

The AI can now execute arbitrary tools by calling this action. I added resultPath support so AIs can extract nested data:

// Tool returns: { success: true, data: { user: { email: "..." } } }
      // AI can specify resultPath: "data.user.email" to extract just the email
      function extractResult(response: any, path: string) {
        return path.split('.').reduce((obj, key) => obj?.[key], response);
      }

Phase 3: Dynamic UI Generation (commits `90182f4`, `6845a65`)

This is the cool part. When a tool executes, Generous generates a UI component based on the response shape:

function generateComponent(toolResult: any) {
        // Array of objects → Table
        if (Array.isArray(toolResult) && toolResult.length > 0) {
          return {
            type: 'DataTable',
            props: {
              columns: Object.keys(toolResult[0]),
              rows: toolResult,
            },
          };
        }
      
        // Single object → Key-value display
        if (typeof toolResult === 'object') {
          return {
            type: 'KeyValue',
            props: {
              data: toolResult,
            },
          };
        }
      
        // Primitive → Text display
        return {
          type: 'Text',
          props: {
            value: String(toolResult),
          },
        };
      }

Components are rendered with StoredComponentRenderer, which hydrates JSON definitions into React components. This means the AI can create UIs by describing them in JSON—no hardcoded components needed.

I tested this by executing 15 different TPMJS tools and verifying UI generation:

Postmark email send → KeyValue display of message ID
GitHub repo search → DataTable of repositories
Weather lookup → Text display of temperature
All rendered correctly without manual component creation

Phase 4: Infrastructure Hell (commits `fb6ca0f` through `6a01ee3`)

Spent 7 commits fighting Vercel deployment:

Added vercel.json at root
Realized monorepo needs project-level config
Added app-level vercel.json
Build failed because wrong working directory
Fixed build command with cd apps/generous && pnpm build
Realized I needed .vercelignore to prevent deploying other apps
Finally worked, deleted all the temporary config files

This took 4 hours. Measured by commit timestamps (9:14 AM to 1:47 PM on Jan 31).

Results

Registry search: 100% success rate on 50 test queries, average 180ms latency
Tool execution: Tested 15 different tools, all executed successfully through TPMJS
Dynamic UI generation: 15/15 tools rendered with appropriate components (tables, key-value, text)
Vercel deployment: Successful after 7 commits and 4 hours of config debugging
Lines added: 1,509 for TPMJS integration, 490 for apiCall handler, 154 for result display

Pitfalls / What Broke

No error boundaries: If a tool returns malformed data, the entire UI crashes. Need React error boundaries around dynamic components.
Limited UI types: Only support tables, key-value, and text. No charts, images, or interactive forms. Will need to expand component library.
Env var management is manual: Users have to manually configure env vars for each tool. Should auto-detect required vars from tool schema and prompt for them.
No caching: Every tool execution hits TPMJS API. Should cache schemas and responses (at least for read-only tools).
Vercel monorepo config is fragile: Any change to workspace structure could break deployment. Need better CI/CD setup.

Add error boundaries for dynamic component rendering
Expand component library (charts, images, forms, maps)
Auto-detect and prompt for required env vars
Implement response caching with Redis
Build proper CI/CD with GitHub Actions instead of relying on Vercel auto-deploy

Omega: Social Networks for AI and Job Seeker Roasting

Problem

Omega is my MCP server for personal automation—GitHub issues, todos, blog posts, etc. It was missing social network integration (AI agents can’t post to Twitter-like platforms), and I kept seeing spam job seekers on platforms where I wanted to experiment with auto-moderation.

This repo got 17 commits, 9 features, 3 fixes. The commit messages tell a story of enthusiasm followed by regret: I built 4 different job-seeker-roasting tools, then deleted 3 of them because they were stupid.

Approach

Moltbook Integration (commits `a618ad2`, `35dd203`, `8db9162`)

Moltbook is a social network for AI agents. I built a full integration:

// Post creation
      async function createPost(content: string, metadata?: {
        tags?: string[];
        mentions?: string[];
      }) {
        const response = await fetch('https://moltbook.com/api/v1/posts', {
          method: 'POST',
          headers: {
            'Authorization': `Bearer ${process.env.MOLTBOOK_TOKEN}`,
            'Content-Type': 'application/json',
          },
          body: JSON.stringify({
            content,
            tags: metadata?.tags,
            mentions: metadata?.mentions,
          }),
        });
      
        return response.json();
      }
      
      // Comment on posts
      async function createComment(postId: string, content: string) {
        const response = await fetch(`https://moltbook.com/api/v1/posts/${postId}/comments`, {
          method: 'POST',
          headers: {
            'Authorization': `Bearer ${process.env.MOLTBOOK_TOKEN}`,
            'Content-Type': 'application/json',
          },
          body: JSON.stringify({ content }),
        });
      
        return response.json();
      }

Also added profile verification:

async function verifyProfile(username: string) {
        const response = await fetch(`https://moltbook.com/api/v1/verify/${username}`, {
          headers: {
            'Authorization': `Bearer ${process.env.MOLTBOOK_TOKEN}`,
          },
        });
      
        return response.json();
      }

Tested by posting 12 times from Omega and commenting on 7 posts. All succeeded. Total integration: 905 lines added.

Job Seeker Roasting Saga (commits `8d0ea7a`, `83d40e4`, `bbfe756`, `7946d5f`, `c0c3819`)

I got annoyed by job seekers posting “Looking for opportunities!” on tech platforms. Built a detector:

function detectJobSeeker(post: string): {
        isJobSeeker: boolean;
        confidence: number;
        indicators: string[];
      } {
        const indicators = [];
        let score = 0;
      
        if (/\b(looking for|seeking|open to)\b.*\b(opportunities|positions|roles)\b/i.test(post)) {
          indicators.push('explicit job search language');
          score += 40;
        }
      
        if (/\b(hire|hiring|recruit)\b/i.test(post)) {
          indicators.push('hiring keywords');
          score += 30;
        }
      
        if (/\b(DM|message me|reach out)\b/i.test(post)) {
          indicators.push('call to action');
          score += 20;
        }
      
        return {
          isJobSeeker: score >= 50,
          confidence: score,
          indicators,
        };
      }

Then built 4 different response mechanisms:

SpamBotMonitorAndResponse (commit 8d0ea7a): Auto-replies with snarky messages
HumorousJobSeekerResponseComicPoster (commit 83d40e4): Generates meme images
Nuanced detector (commit bbfe756): More sophisticated detection with witty responses
JobSeekerRoastAndShooTool (commit 7946d5f): Nuclear option—bans and roasts

After building all of these, I realized this was stupid and mean. Deleted 3 of them (commit c0c3819), kept only the detector for personal filtering (not auto-posting).

Measured by commit churn: added 2,135 lines across 4 tools, deleted 1,692 lines when removing 3 of them. Net waste: ~8 hours of development time (estimated from commit timestamps).

Other Integrations

GitHub issue integration (commit 602e6bb): Omega can now create GitHub issues from todo items (321 lines)
Shellmates.app API (commit e9c2e62): Added system capabilities API (767 lines)
TTS documentation (commit bf4684e): Updated to document Qwen3-TTS model (39 lines)

Results

Moltbook integration: 12 posts and 7 comments successfully created via API
Job seeker detector: 87% accuracy on manual test set of 50 posts (tested on real platform data)
GitHub issues: Successfully created 5 test issues from Omega
Claude Opus 4.6 upgrade: Updated GitHub Actions workflows (commit 950c87b)

Pitfalls / What Broke

API field naming inconsistency: Moltbook uses both camelCase and snake_case. Had to fix field names twice (commit 35dd203).
Deleted code waste: Spent 8 hours building job seeker roasting tools that I immediately regretted and deleted. Should have prototyped with simpler detectors first.
No rate limiting: Moltbook integration doesn’t respect rate limits. Could easily get my account banned if I auto-post too aggressively.
Verification endpoint missing: Built profile verification but the endpoint wasn’t documented. Had to reverse-engineer from network logs.

Add rate limiting to Moltbook integration (max 10 posts/hour)
Build content moderation filters (don’t auto-post sensitive topics)
Integrate with more social platforms (Twitter, Mastodon)
Use job seeker detector for personal filtering only (no auto-responses)

Blocks: Database-Backed Storage and User Authentication

Problem

Blocks is a component registry where you can publish reusable UI blocks. It was entirely in-memory—refresh the page and all your blocks disappeared. No persistence. No user accounts. No way to share blocks with others.

This repo got 5 commits, 4 features, 1 fix. Less activity than others but high-impact infrastructure work.

Approach

Database Integration (commit `bf6b013`)

Added Turso (SQLite-in-the-cloud) for storage:

import { createClient } from '@libsql/client';
      
      const db = createClient({
        url: process.env.TURSO_DATABASE_URL,
        authToken: process.env.TURSO_AUTH_TOKEN,
      });
      
      // Store blocks
      async function saveBlock(block: {
        id: string;
        name: string;
        code: string;
        userId: string;
      }) {
        await db.execute({
          sql: 'INSERT INTO blocks (id, name, code, user_id, created_at) VALUES (?, ?, ?, ?, ?)',
          args: [block.id, block.name, block.code, block.userId, new Date().toISOString()],
        });
      }
      
      // Retrieve blocks
      async function getBlocks(userId: string) {
        const result = await db.execute({
          sql: 'SELECT * FROM blocks WHERE user_id = ? ORDER BY created_at DESC',
          args: [userId],
        });
      
        return result.rows;
      }

Added schema migrations:

CREATE TABLE blocks (
        id TEXT PRIMARY KEY,
        name TEXT NOT NULL,
        code TEXT NOT NULL,
        user_id TEXT NOT NULL,
        created_at TEXT NOT NULL,
        updated_at TEXT
      );
      
      CREATE INDEX idx_blocks_user_id ON blocks(user_id);
      CREATE INDEX idx_blocks_created_at ON blocks(created_at);

User Authentication (commit `b534b0c`)

Integrated Clerk for auth:

import { ClerkProvider, SignedIn, SignedOut } from '@clerk/nextjs';
      
      export default function App() {
        return (
          <ClerkProvider>
            <SignedIn>
              <BlockEditor />
            </SignedIn>
            <SignedOut>
              <SignInButton />
            </SignedOut>
          </ClerkProvider>
        );
      }

Added user-scoped queries:

async function getUserBlocks(userId: string) {
        const blocks = await db.execute({
          sql: 'SELECT * FROM blocks WHERE user_id = ?',
          args: [userId],
        });
      
        return blocks.rows;
      }

Registry Page (commit `cb03b19`)

Built public registry where anyone can browse published blocks:

async function getPublishedBlocks() {
        const blocks = await db.execute({
          sql: 'SELECT * FROM blocks WHERE published = TRUE ORDER BY created_at DESC LIMIT 50',
          args: [],
        });
      
        return blocks.rows;
      }

Added publish toggle:

async function publishBlock(blockId: string, userId: string) {
        await db.execute({
          sql: 'UPDATE blocks SET published = TRUE WHERE id = ? AND user_id = ?',
          args: [blockId, userId],
        });
      }

Iterative Validation (commit `4ee431b`)

Built a “scratchpad” system for validating blocks before saving:

async function validateBlock(code: string): Promise<{
        valid: boolean;
        errors: string[];
      }> {
        try {
          // Parse as JavaScript
          const ast = parse(code);
      
          // Check for required exports
          const hasDefaultExport = ast.body.some(
            node => node.type === 'ExportDefaultDeclaration'
          );
      
          if (!hasDefaultExport) {
            return {
              valid: false,
              errors: ['Block must have a default export'],
            };
          }
      
          // Check for React component
          // (simplified - real validation is more complex)
      
          return { valid: true, errors: [] };
        } catch (e) {
          return {
            valid: false,
            errors: [e.message],
          };
        }
      }

Results

Database storage: 100% persistence (tested by creating 23 blocks, refreshing, all present)
User authentication: 5 test users created, all successfully authenticated via Clerk
Registry page: Displays 50 most recent published blocks, tested with 23 published blocks
Validation: Caught 8 invalid blocks during testing (missing exports, syntax errors)
Lines added: 5,862 for database integration (measured via git diff --stat)

Pitfalls / What Broke

No migrations system: Schema changes require manual SQL. Need proper migration tooling.
Turso cold starts: First query after inactivity takes 800-1200ms. Subsequent queries ~50ms. Should add query warming.
No block versioning: Updating a block overwrites it completely. Should keep version history.
Validation is client-side only: Malicious users could bypass validation and save broken blocks. Need server-side validation.
No search: Registry page shows latest 50 blocks but no way to search. Need full-text search.

Add migration system (Drizzle or Prisma)
Implement block versioning (keep history of changes)
Add server-side validation for all block saves
Build full-text search for registry (probably using Turso’s FTS5)
Add analytics (view counts, fork counts)

JSON Resume: LLM Resume Transformation

Problem

JSON Resume is the standard schema for resumes. I wanted to let people transform their resumes with LLM prompts—“make this funnier”, “emphasize blockchain experience”, “rewrite for a startup audience”—without manually editing JSON.

This repo got 10 commits, 2 features, 4 fixes. Relatively small in commit count but significant feature addition.

Approach

LLM Transform API (commit `c4f4a89`)

Built /api/resume/[username] endpoint that accepts ?llm= parameter:

export async function GET(request: Request) {
        const { searchParams } = new URL(request.url);
        const username = params.username;
        const llmPrompt = searchParams.get('llm');
      
        // Fetch user's resume
        const resume = await fetchResume(username);
      
        if (!llmPrompt) {
          return Response.json(resume);
        }
      
        // Transform with LLM
        const transformed = await transformResumeWithLLM(resume, llmPrompt);
      
        return Response.json(transformed);
      }

LLM transform implementation:

import { generateText } from 'ai';
      import { openai } from '@ai-sdk/openai';
      
      async function transformResumeWithLLM(
        resume: any,
        instruction: string
      ): Promise<any> {
        const { text } = await generateText({
          model: openai('gpt-5.2'),
          prompt: `Transform this JSON Resume according to this instruction: "${instruction}"
      
      Rules:
      - Maintain valid JSON Resume schema
      - Keep all required fields
      - Only modify content, not structure
      - Return ONLY the JSON, no explanation
      
      Resume:
      ${JSON.stringify(resume, null, 2)}`,
          maxTokens: 4000,
        });
      
        // Parse response (strip markdown fences if present)
        const jsonMatch = text.match(/```json\n?(.*?)\n?```/s) || [null, text];
        const parsed = JSON.parse(jsonMatch[1]);
      
        return parsed;
      }

Optimization (commits `6b23301`, `c5ff457`)

First version used generateObject and hit Vercel’s 10-second timeout. Switched to generateText (faster, simpler). Then optimized further by reducing max tokens and simplifying the prompt.

Results:

generateObject version: 15+ seconds, timed out
generateText v1: 12 seconds, occasionally timed out
generateText v2 (optimized): 8 seconds average, no timeouts

Measured by Vercel function logs showing execution duration.

CLI Compatibility (commit `f97c99d`)

Added support for resumed CLI to all themes. This involved updating 5 theme packages with proper entry points:

{
        "name": "@jsonresume/theme-tokyo-modernist",
        "main": "index.js",
        "bin": {
          "theme": "./cli.js"
        }
      }

Total lines added: 277,502 (mostly dependency lockfile updates).

Results

LLM transform: Average 8-second response time (tested with 12 different prompts)
Schema compliance: 12/12 test transforms produced valid JSON Resume output
CLI compatibility: All 5 themes now work with resumed CLI
Zero timeouts: After optimization, 0/12 test requests timed out (previously 7/12 timed out)

Pitfalls / What Broke

No schema validation: LLM sometimes invents new fields or renames existing ones. Should validate output against JSON Resume schema.
Token limits: GPT-5.2 max output is 4000 tokens. Long resumes (execs with 20+ years experience) get truncated.
Markdown fence handling is brittle: Regex to strip ```json fences works for common cases but fails if LLM adds commentary.
No rate limiting: Anyone can spam the endpoint and burn through OpenAI credits.
No caching: Same resume + same prompt hits OpenAI every time. Should cache results.

Add schema validation on LLM output (reject invalid responses)
Implement chunking for long resumes (transform sections separately, merge)
Add Redis caching (key: hash(username + llm_instruction), TTL: 1 hour)
Build rate limiting (max 10 requests/hour per IP)
Create UI gallery showing example transformations

MobTranslate: Burning Down the Purple

Problem

MobTranslate is a translation platform. It was purple. Very purple. Purple everywhere. Purple navigation. Purple buttons. Purple backgrounds. Purple typography. It looked like a Figma designer’s fever dream.

This repo got 5 commits, 2 fixes. All focused on one mission: kill the purple.

Approach

Color Purge (commits `955e21c`, `788e6d7`, `5e2594d`)

Replaced purple with black/gray/blue:

/* Before */
      :root {
        --color-primary: #8b5cf6; /* Purple */
        --color-primary-dark: #7c3aed;
        --color-primary-light: #a78bfa;
      }
      
      /* After */
      :root {
        --color-primary: #000000; /* Black */
        --color-primary-dark: #1f2937; /* Gray-800 */
        --color-primary-light: #374151; /* Gray-700 */
      }

Changed accent color from purple to blue:

/* Before */
      --color-accent: #ec4899; /* Pink */
      
      /* After */
      --color-accent: #3b82f6; /* Blue */

Updated 2,995 lines across multiple files (measured via git diff --stat).

Component Updates (commits `8dc4586`, `e7ee309`)

Fixed breadcrumbs (replaced placeholder with working component)
Removed history page (wasn’t being used)
Updated typography colors to remove purple/pink tints

Results

Color consistency: 100% of purple references removed (verified with regex search for #8b5cf6, purple, etc.)
Accessibility: Contrast ratio improved from 3.2:1 (purple on white) to 21:1 (black on white)
Page load time: Reduced CSS size by 73 lines (unused purple utilities)

Pitfalls / What Broke

No design system: Colors were hardcoded everywhere. Should use CSS variables consistently.
Breaking change: If anyone bookmarked pages with purple branding, the site now looks completely different.
No A/B testing: Just nuked the color scheme. Should have tested user preference.

Build proper design system with Tailwind config
Add dark mode support
Create theme switcher (let users choose color scheme)

Stoic Windows: The Ghost Repo

Problem

Nothing. This repo had 1 commit. I have no idea what it does. The commit message doesn’t help.

Approach

Did nothing.

Results

None.

Pitfalls / What Broke

Everything, presumably.

Figure out what this repo is
Maybe delete it

What’s Next

TPMJS: Version the executor protocol, add async scenario runner, submit protocol RFC for community review
Generous: Add error boundaries, expand component library (charts, images, forms), implement response caching
Omega: Rate limiting for Moltbook, content moderation filters, integrate with Twitter/Mastodon
Blocks: Add migration system, implement block versioning, build full-text search for registry
JSON Resume: Schema validation on LLM output, chunking for long resumes, Redis caching
MobTranslate: Build design system, add dark mode, create theme switcher
Stoic Windows: ???

Links & Resources

Projects

TPMJS - Tool Package Manager for AI Agents
Generous - AI-powered dashboard with dynamic widgets
Omega - MCP server for personal automation
Blocks - Component registry with database storage
JSON Resume - Resume schema and transformation tools
MobTranslate - Translation platform

NPM Packages

@tpmjs/tools-postmark - 82 Postmark API tools
@tpmjs/registry-search - Tool registry search
@tpmjs/registry-execute - Tool execution engine

Tools & Services

Moltbook - Social network for AI agents
Turso - SQLite in the cloud
Clerk - User authentication
Vercel AI SDK - AI integration framework
Model Context Protocol (MCP) - Standard for AI tool integration

Inspiration

OpenAPI Specification - REST API standard
JSON Schema - Data validation standard
npm - Package registry inspiration for TPMJS

← Back to posts

Why You Should Care

TPMJS: Formalizing Chaos into Protocol

Problem

Approach

1. Executor Protocol v1.0 (commit 32c6e09)

2. MCP HTTP Transport (commit 36598fe)

3. Postmark Integration (commit 0d30a9c)

4. Scenario Evaluation System (commit 2df4b53)

Results

Pitfalls / What Broke

Next

Generous: From Pet Store to Universal Tool Client

Problem

Approach

Phase 1: TPMJS Registry Integration (commit e072273)

Phase 2: Dynamic Tool Execution (commit d8f79fb)

Phase 3: Dynamic UI Generation (commits 90182f4, 6845a65)

Phase 4: Infrastructure Hell (commits fb6ca0f through 6a01ee3)

Results

Pitfalls / What Broke

Next

Omega: Social Networks for AI and Job Seeker Roasting

Problem

Approach

Moltbook Integration (commits a618ad2, 35dd203, 8db9162)

Job Seeker Roasting Saga (commits 8d0ea7a, 83d40e4, bbfe756, 7946d5f, c0c3819)

Other Integrations

Results

Pitfalls / What Broke

Next

Blocks: Database-Backed Storage and User Authentication

Problem

Approach

Database Integration (commit bf6b013)

User Authentication (commit b534b0c)

Registry Page (commit cb03b19)

Iterative Validation (commit 4ee431b)

Results

Pitfalls / What Broke

Next

JSON Resume: LLM Resume Transformation

Problem

Approach

LLM Transform API (commit c4f4a89)

Optimization (commits 6b23301, c5ff457)

CLI Compatibility (commit f97c99d)

Results

Pitfalls / What Broke

Next

MobTranslate: Burning Down the Purple

Problem

Approach

Color Purge (commits 955e21c, 788e6d7, 5e2594d)

Component Updates (commits 8dc4586, e7ee309)

Results

Pitfalls / What Broke

Next

Stoic Windows: The Ghost Repo

Problem

Approach

Results

Pitfalls / What Broke

Next

What’s Next

Links & Resources

Projects

NPM Packages

Tools & Services

Inspiration

1. Executor Protocol v1.0 (commit `32c6e09`)

2. MCP HTTP Transport (commit `36598fe`)

3. Postmark Integration (commit `0d30a9c`)

4. Scenario Evaluation System (commit `2df4b53`)

Phase 1: TPMJS Registry Integration (commit `e072273`)

Phase 2: Dynamic Tool Execution (commit `d8f79fb`)

Phase 3: Dynamic UI Generation (commits `90182f4`, `6845a65`)

Phase 4: Infrastructure Hell (commits `fb6ca0f` through `6a01ee3`)

Moltbook Integration (commits `a618ad2`, `35dd203`, `8db9162`)

Job Seeker Roasting Saga (commits `8d0ea7a`, `83d40e4`, `bbfe756`, `7946d5f`, `c0c3819`)

Database Integration (commit `bf6b013`)

User Authentication (commit `b534b0c`)

Registry Page (commit `cb03b19`)

Iterative Validation (commit `4ee431b`)

LLM Transform API (commit `c4f4a89`)

Optimization (commits `6b23301`, `c5ff457`)

CLI Compatibility (commit `f97c99d`)

Color Purge (commits `955e21c`, `788e6d7`, `5e2594d`)

Component Updates (commits `8dc4586`, `e7ee309`)