Skip to main content
Glama
Snovak99

personal-mcp

by Snovak99
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

personal-mcp

A personal MCP server for connecting your own API integrations and exposing them as tools/resources/prompts.

Initial Scope

  • Fitness domain

  • Hevy provider integration

Related MCP server: Hevy MCP Pro

Project Structure

personal-mcp/
├── .github/
│   └── copilot-instructions.md
├── src/
│   ├── core/
│   │   ├── server/
│   │   ├── config/
│   │   ├── types/
│   │   └── utils/
│   ├── domains/
│   │   └── fitness/
│   │       ├── providers/
│   │       │   └── hevy/
│   │       ├── services/
│   │       ├── tools/
│   │       ├── resources/
│   │       ├── prompts/
│   │       └── types/
│   └── index.ts
├── tests/
│   ├── core/
│   └── domains/
│       └── fitness/
├── .env.example
├── package.json
├── tsconfig.json
└── README.md

Quick Start

  1. Install dependencies.

  2. Copy .env.example to .env and set your API key(s).

  3. Start in dev mode.

npm install
npm run dev

Next Steps

  • Implement Hevy API client methods.

  • Add MCP tools for recent workouts, exercise lookup, and training volume summaries.

  • Add domain-focused tests under tests/domains/fitness.

Available Tools

2 tools
hevy_recent_workoutsB

Return a placeholder list of recent Hevy workouts

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/5.0
Behavior3/5

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

Without annotations, the description carries the full burden. It discloses that the output is a 'placeholder list', which is a key behavioral trait, but it does not elaborate on what placeholder means or describe the exact output format. This is minimal but non-misleading.

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 sentence that directly states the tool's function. There is no wasteful wording, and it is appropriately front-loaded with the action and resource.

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

Completeness3/5

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

With no output schema, the description should explain the return value in enough detail. It mentions a 'list of recent Hevy workouts' but says 'placeholder', which is ambiguous about whether the list contains fake data. This leaves some uncertainty, but the simplicity of the tool limits the impact.

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 the schema is empty. Per the calibration guidance, a baseline of 4 is appropriate when there are no parameters to describe, so the description needs to add no extra parameter information.

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 uses a specific verb 'Return' and names the resource 'recent Hevy workouts', clearly distinguishing it from the sibling tool 'hevy_status'. The term 'placeholder' introduces some ambiguity about whether the data is real or mock, but the core purpose is understandable.

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?

No guidance is provided on when to use this tool versus the sibling 'hevy_status'. The description does not mention alternatives, exclusions, or typical use cases, leaving the agent without context for tool selection.

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

hevy_statusB

Report whether Hevy API configuration is available

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the core purpose (reporting availability) and does not mention potential errors, side effects, or output characteristics beyond the implicit yes/no.

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 directly states the tool's purpose. It is front-loaded and contains no unnecessary words.

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

Completeness4/5

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

Given the tool's simplicity (0 params, no output schema, no annotations), the description adequately conveys that it reports a boolean status. It does not mention integration with sibling tools, but this is acceptable for such a minimal tool.

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 0 parameters, so the description does not need to explain any. The baseline for 0 params is 4, and the empty schema is adequately covered.

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 function with a specific verb ('Report') and resource ('Hevy API configuration availability'). It is distinct from the sibling tool hevy_recent_workouts, which focuses on retrieving workout data.

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

Usage Guidelines1/5

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

No guidance is provided on when to use this tool versus the sibling or any alternatives. There is no mention of prerequisites or typical usage context.

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. 2 tool updatesv0.1.0
    • First observedhevy_recent_workouts
    • First observedhevy_status
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

A3.5/5.0

Scored across 2 tools

Disambiguation5/5

The two tools are clearly distinct: one reports configuration status, the other returns workout data. There is no overlap in their purposes or expected outputs.

Naming Consistency5/5

Both tool names follow a consistent pattern: 'hevy_' prefix followed by a snake_case noun. This makes the naming predictable and easy to understand.

Tool Count3/5

With only two tools, the server feels thin and borderline under-scoped. While each tool serves a purpose, a typical server for a domain like workouts would benefit from more coverage.

Completeness2/5

The tool set is significantly incomplete for a Hevy workout integration. It only provides a status check and a placeholder list, lacking any real workout retrieval, creation, update, or delete operations.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • garmin-mcp

    marcelohensantos
    F
    license
    Not graded
    quality
    D
    maintenance
    Exposes Garmin Connect data and workout management to AI agents, supporting tools, resources, and prompts for health data, workout creation, and coaching workflows.
    1
    -

  • Hevy MCP Pro

    cbotworks
    A
    license
    B
    quality
    D
    maintenance
    A production-ready MCP server for the Hevy fitness API that exposes 27 tools for reading, writing, and analyzing workout data, enabling LLM-driven personal trainer workflows.
    27
    9 npm
    MIT

  • Hevy Fitness MCP Server

    phaiel
    A
    license
    Not graded
    quality
    C
    maintenance
    A Model Context Protocol (MCP) server that provides AI assistants with access to the Hevy fitness tracking API. This allows you to log workouts, manage routines, browse exercises, and track your fitness progress directly through AI chat interfaces.
    14 npm
    MIT