Skip to main content
Glama
123justin123

mcp-cv

by 123justin123
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

mcp-cv

npm

My resume, queryable from your AI assistant.

A Model Context Protocol server that exposes my background, projects and contact details. Plug it into Claude, Cursor or any MCP client and just ask: "Who is Justin?", "Has he used Kafka?", "How can I reach him?".

npx -y @just1-dev/mcp-cv

Installation

Claude Desktop

In claude_desktop_config.json:

{
  "mcpServers": {
    "justin": {
      "command": "npx",
      "args": ["-y", "@just1-dev/mcp-cv"]
    }
  }
}

Claude Code

claude mcp add justin -- npx -y @just1-dev/mcp-cv

Cursor, VS Code and other clients

Same idea: command npx, arguments -y @just1-dev/mcp-cv, stdio transport.

Related MCP server: Bijon Portfolio MCP Server

What the server exposes

Tools

Tool

Input

Purpose

get_profile

none

Summary, tech stack, availability, work experience, education

get_projects

tech?, slug?

Project case studies, optionally narrowed to one technology or one project

get_contact

none

Email, LinkedIn, GitHub, website

All three are read-only, declare an outputSchema and return validated structuredContent.

Resources

  • justin://resume: the whole resume

  • justin://projects/{slug}: a single project, with listing and slug completion

Architecture

src/
├── index.ts          CLI entry point, serveStdio
├── server.ts         createServer(): wires tools and resources
├── schemas.ts        Zod schemas: types, validation and output schemas
├── data/cv.ts        single source of truth for the data
├── tools/index.ts    the three tools
├── resources.ts      resources and URI template
└── lib/
    ├── cv.ts         public view of the resume, age computation
    └── result.ts     MCP result helper

Two MCP primitives serve the same data through two channels: tools are called by the model, resources are attached by the user.

The server holds no model and no search: it serves structured data and instructs the client's model to answer only from it. createServer() is transport-agnostic: index.ts serves it over stdio, and the test suite drives it through a real MCP client and createMcpHandler, in process, on the protocol revision hosts negotiate today.

Development

npm install
npm run dev        # run the server from source
npm test           # node:test suite
npm run typecheck
npm run inspect    # build, then open the MCP Inspector in the browser

Available Tools

3 tools
get_contactContactA
Read-onlyIdempotent

How to reach Justin: email, LinkedIn, GitHub, website.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
emailNo
githubNo
websiteNo
linkedinNo

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the tool as readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds the contact channels but does not disclose additional behavioral details such as output format or data freshness. There is no contradiction between description and annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the core purpose and immediately lists the available contact channels. Every word contributes meaningful information, and there is no unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only lookup tool with an output schema and comprehensive annotations, the description is sufficient. An agent can confidently invoke get_contact knowing it returns Justin's email, LinkedIn, GitHub, and website contact information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and schema description coverage is 100%, so there are no input semantics to explain. The description appropriately focuses on the tool's purpose rather than on nonexistent parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: obtaining Justin's contact information via email, LinkedIn, GitHub, and website. It is easily distinguishable from sibling tools like get_profile and get_projects because it focuses specifically on how to reach Justin rather than on profile details or project lists.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'How to reach Justin' implies the tool is for contact info, but there is no explicit guidance about when to choose this tool over alternatives like get_profile. It provides clear context but no direct when-to-use or when-not-to-use instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_profileProfileA
Read-onlyIdempotent

Justin's background: summary, tech stack, availability, work experience and education.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
profileYes
educationYes
experienceYes

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds no behavioral details, but none are necessary for a zero-parameter, read-only profile getter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single compact sentence with no filler, front-loaded with 'Justin's background' and then listing the exact content areas. Every word contributes to the agent's understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is trivial to invoke with no parameters, annotations cover safety and idempotency, and an output schema exists for return structure. The description enumerates all content categories, so nothing essential is missing for correct selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so there is no parameter ambiguity and schema coverage is trivially complete. The description usefully lists the profile sections returned, adding semantic context beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource ('Justin's background') and enumerates its contents: summary, tech stack, availability, work experience, and education. This clearly distinguishes it from sibling tools like get_projects and get_contact, though the retrieval verb is carried by the tool name rather than the description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit guidance on when to use get_profile versus the sibling tools. The resource name and content make the intended use somewhat obvious, but there are no stated selection criteria, exclusions, or context cues.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_projectsProjectsA
Read-onlyIdempotent

Justin's projects as case studies, filterable by technology or by slug.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugNoA single project identifier, e.g. "mcp-cv"
techNoOnly keep projects using this technology, e.g. "React"

Output Schema

ParametersJSON Schema
NameRequiredDescription
projectsYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already disclose read-only, idempotent, non-destructive behavior. The description adds modest context (projects are case studies and filterable), but does not disclose additional behavioral details such as filtering semantics, ordering, or result shape. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, compact sentence conveys the resource owner, the content type, and the two filtering dimensions. Every phrase earns its place, and the most important identifying information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list tool with two optional parameters, a rich output schema, and safety annotations, the description is fully adequate. An agent can determine what the tool returns, how to filter, and that it is a safe operation without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and both parameters already have clear inline descriptions and examples. The description's mention of 'filterable by technology or by slug' lightly reinforces the schema but adds no new meaning beyond it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource ('Justin's projects'), the context ('as case studies'), and the available filtering dimensions (technology or slug). It does not restate the tool name, and the resource is distinct from the sibling profile/contact tools, though it never explicitly names those siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: use this tool to retrieve Justin's projects and filter them by tech or slug. However, it provides no explicit guidance on when to prefer this tool over siblings or when filters should be used together versus separately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv1.0.0
    • First observedget_contact
    • First observedget_profile
    • First observedget_projects
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a clearly distinct section of a CV: professional background, projects, and contact information. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a uniform get_<noun> pattern, making the API predictable and easy to navigate. The naming is fully consistent and intuitive.

Tool Count5/5

Three tools is a well-scoped size for a personal CV server, with each tool covering a natural top-level section. The count is neither too thin nor excessive.

Completeness5/5

The tool surface covers the essential aspects of a CV: profile (including experience and education), projects, and contact. There are no obvious missing operations that an agent would need to get a complete picture of the candidate.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Portfolio MCP Server

    srikanth-karthi
    A
    license
    A
    quality
    C
    maintenance
    Enables searching and retrieving portfolio data including experience, skills, and contact information through natural language queries.
    5
    MIT

  • Resume MCP Server

    Adarshcharjan
    A
    license
    Not graded
    quality
    C
    maintenance
    Exposes a structured professional resume as a set of AI-queryable tools, enabling AI clients like Claude Desktop to query summary, experience, skills, projects, and tailor resumes to job descriptions.
    1
    MIT