Layout
config.ts and http.ts. The CLI is for one-shot config commands; the MCP server is what AI tools spawn.
Entry points
- CLI:
bin: { "magic-resume": "./dist/cli.js" }inpackage.json. Subcommands:config set,config get,config print,config clear, andmcp(which boots the server). - MCP server:
magic-resume mcpbootsserver.ts, registers tools, attachesStdioServerTransport, and runs forever.
Config file
~/.magic-resume/mcp.json:
config.ts reads this lazily on first use. On Windows the path is %USERPROFILE%\.magic-resume\mcp.json.
Tool registration
server.ts uses @modelcontextprotocol/sdk to register each tool with:
- A name and description
- A Zod-derived input schema (so the model gets typed parameter hints)
- A handler delegating to
resume-tools.ts
McpError with a stable error code so AI tools can react (e.g. retry on transient network failures, abort on validation errors).
Core API contract
The MCP server is a client of the same NestJS Core API the web app talks to. Relevant endpoints:http.ts attaches Authorization: Bearer <pat> automatically. Unlike the web app, there is no Clerk involvement — PATs are a separate auth method the Core API understands.
Build and publish
publishConfig.access = "public" and uses pnpm’s workspace:* rewriting so the published package.json has real semver versions for @magic-resume/resume-schema and @magic-resume/resume-templates.
Adding a new tool
- Add the handler to
resume-tools.ts. Keep it pure and patch-based. - Register it in
server.tswith a Zod input schema and a short description. - Add a
node --testcase intest/. - If the tool reads or mutates a new field, update
get_resume_editing_guideso models know how to use it.
