Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@musclesworked-mcp Analyze my push day: bench press, overhead press, and tricep pushdown"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for the musclesworked.com exercise-to-muscle mapping API.
Connects Claude Desktop, Claude Code, Cursor, and other MCP clients to 856 exercises and 65 muscles with detailed primary/secondary/stabilizer activation data across 14 muscle groups.
Get an API key at musclesworked.com/dashboard.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"musclesworked": {
"command": "npx",
"args": ["-y", "musclesworked-mcp"],
"env": {
"MUSCLESWORKED_API_KEY": "mw_live_..."
}
}
}
}claude mcp add musclesworked -- npx -y musclesworked-mcp --api-key mw_live_...Or add to .mcp.json:
{
"mcpServers": {
"musclesworked": {
"command": "npx",
"args": ["-y", "musclesworked-mcp", "--api-key", "mw_live_..."]
}
}
}Add to .cursor/mcp.json:
{
"mcpServers": {
"musclesworked": {
"command": "npx",
"args": ["-y", "musclesworked-mcp"],
"env": {
"MUSCLESWORKED_API_KEY": "mw_live_..."
}
}
}
}Related MCP server: mcp-academia-server
Tool | Description |
| Get primary, secondary, and stabilizer muscles for an exercise |
| Find exercises targeting a specific muscle with optional filters |
| Analyze a workout for coverage, gaps, and imbalances |
| Find alternative exercises ranked by muscle overlap |
| Search exercises by name to discover IDs |
| Search muscles by name to discover IDs |
"What muscles does the barbell bench press work?"
"Find bodyweight exercises for my chest"
"Analyze my push day: bench press, overhead press, tricep pushdown, lateral raise"
"What are some alternatives to barbell squats?"
"Search for exercises that target the hamstrings"
Option | Description |
| API key (or set |
| Override base URL (default: |
git clone https://github.com/csjoblom/musclesworked-mcp.git
cd musclesworked-mcp
npm install
npm run build
# Test with MCP Inspector
MUSCLESWORKED_API_KEY=mw_live_... npx @modelcontextprotocol/inspector node dist/index.jsMIT
Analyze a workout for muscle coverage, gaps, and imbalances. Pass a list of exercise names or IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| exercises | Yes | List of exercise IDs or names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It successfully identifies the analytical dimensions (coverage, gaps, imbalances) but omits critical operational details such as whether results are cached, any rate limits, or whether the analysis is deterministic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently deliver the tool's purpose and input requirements with zero redundancy or filler content. The structure front-loads the value proposition (analysis for gaps/imbalances) before mentioning mechanics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter analytical tool, the description adequately covers the input intent but fails to compensate for the missing output schema. It does not describe the return format (structured data vs narrative) or analysis depth, leaving agents uncertain about result handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('List of exercise IDs or names'), the parameter is already well-documented. The description's 'Pass a list of exercise names or IDs' adds no new semantic information beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the analytical operation ('Analyze') and the exact dimensions evaluated (muscle coverage, gaps, imbalances), which distinguishes this from simple retrieval siblings like get_muscles_worked. However, it does not explicitly state that this tool analyzes a *collection* of exercises as a workout plan, leaving subtle ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the second sentence ('Pass a list of exercise names or IDs') provides basic invocation syntax, there is no guidance on when to select this tool versus siblings like get_muscles_worked or find_exercises, nor any mention of prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find exercises that target a specific muscle, with optional filters. Use search_muscles first if you don't know the muscle ID.
| Name | Required | Description | Default |
|---|---|---|---|
| muscle | Yes | Muscle ID or name (e.g. 'pectoralis_major_sternal') | |
| equipment | No | Filter by equipment type | |
| difficulty | No | Filter by difficulty level | |
| movement_pattern | No | Filter by movement pattern | |
| exercise_type | No | Filter by exercise type | |
| role | No | Filter by muscle role | |
| limit | No | Max results (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states basic operation ('Find exercises') without disclosing return format, pagination behavior beyond the limit parameter, read-only nature, or error handling. Does not mention what data structure is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First sentence establishes purpose and capability; second provides prerequisite workflow. Well-structured and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 7-parameter lookup tool with no output schema or annotations. Covers primary use case and prerequisite workflow. Lacks output format disclosure and error scenario documentation, which is notable given the rich enum parameter set (5 enums) and absence of structured behavioral metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, establishing baseline 3. Description mentions 'optional filters' generally but adds no semantic depth beyond the schema's existing enum descriptions and type definitions. Second sentence clarifies muscle accepts ID or name, which aligns with parameter description but adds workflow context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Find') and resource ('exercises') with specific scope ('target a specific muscle'). Mentions prerequisite workflow with search_muscles, implicitly distinguishing from that sibling. However, does not explicitly differentiate from 'search_exercises' sibling, leaving potential ambiguity about when to use which search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite: 'Use search_muscles first if you don't know the muscle ID.' This provides clear workflow guidance. Missing explicit 'when not to use' guidance regarding 'search_exercises' alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find alternative exercises ranked by muscle overlap score. Use search_exercises first if you don't know the exercise ID.
| Name | Required | Description | Default |
|---|---|---|---|
| exercise | Yes | Exercise ID or name | |
| limit | No | Max results (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the ranking behavior (muscle overlap score) which is crucial context, but lacks safety/operational disclosure required due to missing annotations. No mention of error handling for invalid exercise IDs or whether results are cached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. First sentence establishes purpose and ranking method; second provides the critical usage prerequisite. Purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 2-parameter retrieval tool without output schema. Describes what is returned (ranked alternatives) and the ranking logic. Minor gap: no description of the alternative object structure or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions ('Exercise ID or name', 'Max results'). Description reinforces the exercise parameter usage through the ID reference in usage guidelines, but adds no syntax/format details beyond the schema. Baseline 3 appropriate for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: verb (Find) + resource (alternative exercises) + unique ranking mechanism (muscle overlap score). Clearly distinguishes from generic search siblings by specifying the muscle overlap algorithm.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit prerequisite with sibling named: 'Use search_exercises first if you don't know the exercise ID.' Perfectly clarifies the workflow dependency between this tool and search_exercises.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the primary, secondary, and stabilizer muscles worked by an exercise. Use search_exercises first if you don't know the exercise ID.
| Name | Required | Description | Default |
|---|---|---|---|
| exercise | Yes | Exercise ID or name (e.g. 'barbell_bench_press') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses output structure (three muscle categories) but does not explicitly confirm read-only safety, error handling when exercises are not found, or rate limiting. The verb 'Get' implies retrieval, but explicit behavioral guarantees are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first sentence front-loads core purpose (muscle retrieval with categorization), second sentence gives prerequisite workflow. Every word earns its place; no redundancy with schema or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately complete for a single-parameter lookup tool with 100% schema coverage. The description compensates for missing output_schema by detailing the return structure (primary/secondary/stabilizer muscles) and provides clear sibling references. Minor gap: lacks error handling description for invalid exercise IDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear description ('Exercise ID or name') and example ('barbell_bench_press'). Description references 'exercise' and 'exercise ID' but does not add semantic information beyond the schema's documentation, warranting the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb ('Get') plus granular resource scope ('primary, secondary, and stabilizer muscles worked by an exercise'). Distinguishes clearly from siblings like 'search_exercises' (which finds exercises) by focusing on retrieving detailed muscle categorization for a specific known exercise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite workflow: 'Use search_exercises first if you don't know the exercise ID.' This directly names the sibling alternative and defines the exact condition for using that tool instead, guiding correct invocation sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for exercises by name. Returns matching exercise IDs and names. Use this to discover exercise IDs before calling get_muscles_worked or get_alternatives.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g. 'bench press', 'squat') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return content ('matching exercise IDs and names') which compensates for the missing output schema. However, lacks other behavioral traits: no mention of result limits, pagination, case sensitivity, or exact vs fuzzy matching behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: 1) purpose, 2) return value, 3) workflow guidance. Each earns its place; no redundancy with structured fields. Appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter search tool with simple string input, the description adequately covers the discovery workflow and return format. Could be improved by noting result limits or error behaviors, but sufficient given the low complexity and high schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (query parameter has description with examples). The description does not add parameter-specific semantics (e.g., syntax rules, formatting), but the schema is self-documenting, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Search'), resource ('exercises'), and scope ('by name'). Mentions return values (IDs and names) to clarify output. However, does not distinguish from sibling 'find_exercises', which appears to serve a similar discovery function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the workflow position: 'Use this to discover exercise IDs before calling get_muscles_worked or get_alternatives.' This establishes prerequisites and relationships with specific sibling tools, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for muscles by name. Returns matching muscle IDs and names. Use this to discover muscle IDs before calling find_exercises.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g. 'chest', 'bicep', 'quad') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses the return format ('matching muscle IDs and names'), which is critical since no output schema exists. Does not mention error behaviors or pagination, but covers the essential output contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: action statement, return value disclosure, and usage guideline. Information is front-loaded and logically ordered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter and no output schema, the description is complete. It explains the return values and provides clear prerequisite guidance relative to siblings, which satisfies completeness requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'query' parameter fully documented (including examples like 'chest', 'bicep'). The description does not add additional parameter semantics, but with complete schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb ('Search'), resource ('muscles'), and scope ('by name'). The final sentence distinguishes this from sibling find_exercises by clarifying it returns IDs needed for that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'Use this to discover muscle IDs before calling find_exercises.' This directly addresses the workflow relationship with a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0analyze_workoutfind_exercisesget_alternativesget_muscles_workedsearch_exercisessearch_musclesScored across 6 tools
Each tool has a clearly distinct purpose with no overlap: analyze_workout evaluates workouts, find_exercises locates exercises by muscle, get_alternatives suggests substitutes, get_muscles_worked details muscle involvement, search_exercises finds exercises by name, and search_muscles finds muscles by name. The descriptions explicitly differentiate their functions, preventing agent confusion.
All tools follow a consistent verb_noun pattern with snake_case throughout (e.g., analyze_workout, find_exercises, get_muscles_worked). The naming is predictable and readable, using clear verbs like 'analyze', 'find', 'get', and 'search' that accurately reflect each tool's action.
With 6 tools, this server is well-scoped for its fitness/bodybuilding domain. Each tool earns its place by covering key workflows: discovering muscles and exercises, analyzing muscle involvement, finding alternatives, and evaluating workouts. The count is neither too sparse nor bloated, fitting typical agent needs efficiently.
The tool set provides strong coverage for core muscle and exercise analysis tasks, including search, retrieval, and workout evaluation. A minor gap exists in update or management operations (e.g., no tools for creating or modifying exercise/muscle data), but this is reasonable for a lookup-oriented server, and agents can work around it with the provided tools.
MCP server exposing supplements database used by iNutriPlan.com
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Strength Standards Calc: the site's own MCP server — dataset, enquiry (enquiry = a human...
Wger MCP — wraps wger Workout Manager REST API (free, no auth for read)
