This server provides comprehensive integration with the Boostcamp fitness platform, enabling you to manage workouts, track progress, and discover content.
Profile & Account
Retrieve your user profile and settings (get_my_profile)
View your payment/subscription history (get_payment_history)
Workout & Training History
Access and filter detailed training history by date range (start_date, end_date), with options for compact summaries or full details including sets, reps, and RPE (get_training_history)
Paginate through extensive workout histories (page, page_size)
List custom exercises you've created (list_custom_exercises)
Programs
List all fitness programs you're currently enrolled in (list_enrolled_programs)
Browse the full program catalog with keyword search and pagination (list_all_programs)
Get detailed workout plans (sets, reps, coach notes) for a specific program (get_program_details)
Dashboard & Analytics
View dashboard stats including total workouts, total weight moved, and current streak (get_home_summary)
See summaries of your active/recent programs (get_home_programs)
Access training volume chart data over time (get_home_chart)
Analyze muscle group distribution to see which muscles you've been targeting (get_home_muscle)
Content Discovery
Browse Boostcamp blog posts and training guides with pagination (list_blogs)
All tools that depend on timezone accept a timezone_offset parameter (default: -300 minutes from UTC).
Click on "Install 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., "@Boostcamp MCP Server Show my recent workout history"
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.
A Model Context Protocol (MCP) server for integrating with the Boostcamp fitness platform. It gives Claude Desktop and Claude Code seamless access to your training history, workout programs, custom exercises, and analytics.
Built on the boostcamp-api Python library — a wrapper around Boostcamp's private API.
Attribution: This project began as a fork of
Alex-Keyes/boostcamp-mcpand builds onAlex-Keyes/boostcamp-apiby Alex Keyes. It is now maintained as a standalone project. See Credits.
Clone this repository:
git clone https://github.com/dcaslin/boostcamp-mcp.git
cd boostcamp-mcpInstall dependencies with uv:
uv syncAuthentication runs through a standalone script so your credentials are never handled by the MCP client. From the project directory:
uv run loginFollow the prompts:
Enter your Boostcamp email and password.
The script authenticates against the Boostcamp API and saves your session token as BOOSTCAMP_AUTH_TOKEN in a local .env file (ignored by git).
Your email and password are only used to obtain the token and are never stored.
Claude Code (CLI):
claude mcp add boostcamp -- uv run --directory /path/to/your/boostcamp-mcp boostcamp-mcpClaude Desktop: add this to your config file —
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"boostcamp": {
"command": "uv",
"args": [
"run",
"--directory",
"/path/to/your/boostcamp-mcp",
"boostcamp-mcp"
]
}
}
}Important: Replace /path/to/your/boostcamp-mcp with the actual path to your clone. The server reads .env from that directory, so it must match where you ran uv run login. Restart Claude Desktop after editing the config.
Once connected, ask Claude to use the tools directly, e.g.:
"Show my Boostcamp profile" → get_my_profile
"What programs am I enrolled in?" → list_enrolled_programs
"Review my recent workouts" → get_training_history
"What's my dashboard streak and totals?" → get_home_summary
Related MCP server: Arvo MCP Server
Home Summary: total workouts, total weight moved, and current week streak.
Volume Charts: training volume over time.
Muscle Distribution: which muscle groups you've been targeting.
Program Details: full workout plans, including sets, reps, and coach notes.
Enrolled Programs: track your progress in active training plans.
Custom Exercises: access exercises you've manually created.
Program Catalog: search and list programs available on the platform.
Blog Access: read the latest articles and training guides from the Boostcamp blog.
Tool | Description | Parameters |
| Get user profile and settings | None |
| List your active programs | None |
| Workout history, compact by default. Returns JSON with pagination metadata and a |
|
| View your subscription/orders | None |
| List your custom exercises | None |
| Search the program catalog |
|
| Get the full plan for a program ID |
|
| List recent blog posts |
|
| Dashboard stats (streak/totals) |
|
| Active/recent program summary |
|
| Training volume chart data |
|
| Muscle group distribution |
|
timezone_offset is in minutes from UTC and defaults to -300.
get_training_history is built to keep responses small enough for any MCP
client. By default it returns a summary of your 50 most recent workouts
(date, program, exercises, and total volume) plus pagination metadata:
{
"workouts": [ { "date": "2026-06-10", "program_name": "...",
"exercises": ["Squat (Barbell)", "..."],
"total_volume": 11570, "volume_unit": "lbs" } ],
"pagination": {"page": 1, "page_size": 50, "total": 231,
"returned": 50, "has_more": true},
"filters": {"start_date": null, "end_date": null, "detail": "summary"},
"hint": "231 workouts match. Showing 50 (page 1, summary). Use page=2 ..."
}Filter by date: start_date / end_date as YYYY-MM-DD (inclusive),
e.g. "my workouts since 2026-04-07".
Page through history: bump page while pagination.has_more is true
(page_size caps at 100 for summary, 25 for full).
Get every set and rep: detail="full" adds per-exercise records with each
set's weight, reps, target, and RPE. Use a small page_size here.
Supersets are flattened: each exercise inside a superset is listed individually
(with its sets counted toward total_volume), and in full detail those
exercises carry a superset id so the grouping is still visible.
If a tool returns an "Authentication Error" or your token has expired:
Re-run the login command from the project directory: uv run login
Restart your MCP client (Claude Desktop or Claude Code).
Sessions are stored in .boostcamp/session.pickle as {token, refresh_token}.
The Firebase refresh token (not your password) is persisted, so an expired
ID token is renewed automatically on the next request — no re-login needed for
routine expiry.
A BOOSTCAMP_AUTH_TOKEN is also saved to .env and used as a fallback for
logins that predate refresh-token support (token-only, no auto-renewal).
Upgrading: if you logged in before refresh-token support was added, run
uv run login once to store the refresh token and enable auto-renewal.
You only need to re-run uv run login if the refresh token itself becomes
invalid (e.g. after a password change).
Security Note: Never commit your .env or .boostcamp/ folder. They are included in .gitignore by default.
Released under the MIT License.
Original MCP server: Alex-Keyes/boostcamp-mcp by Alex Keyes.
Underlying API library: Alex-Keyes/boostcamp-api by Alex Keyes, maintained here as dcaslin/boostcamp-api.
Get training volume chart data.
| Name | Required | Description | Default |
|---|---|---|---|
| timezone_offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states a generic action. It does not disclose behavioral traits like data freshness, auth needs, or side effects.
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?
Very concise at 5 words, but it sacrifices informativeness. Could be improved with a bit more detail without becoming verbose.
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?
Given the tool has an output schema and one parameter, the description is insufficient. It doesn't explain the chart data scope or the timezone parameter's role, leaving the agent underinformed.
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 0%, and the description adds no meaning to the sole parameter 'timezone_offset'. The agent gets no help on what this offset does or how to use it.
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 states the verb 'Get' and the resource 'training volume chart data', which is specific. However, it does not differentiate from siblings like 'get_home_summary' or 'get_training_history', which could overlap.
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?
No guidance on when to use this tool vs alternatives. Lacks context such as prerequisites or typical use cases, making it hard for the agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get muscle group distribution data.
| Name | Required | Description | Default |
|---|---|---|---|
| timezone_offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states the action without disclosing behavioral traits like read-only, permissions, or rate limits. Minimal disclosure for a data retrieval tool.
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?
Single sentence is concise and front-loaded. However, it is too brief to convey necessary context; a bit more structure would improve clarity without bloat.
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?
Has an output schema (not shown), which reduces need to describe return values. The tool is simple (one optional param), but the description is vague about what 'muscle group distribution data' includes. Adequate but could be improved with context like scope or typical use.
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 0% (one parameter 'timezone_offset' undocumented). The description does not mention the parameter or explain its role, adding no meaning beyond the schema's default and type.
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 'Get muscle group distribution data' specifies a clear verb ('Get') and resource ('muscle group distribution data'). It distinguishes from sibling tools like get_home_chart and get_home_summary, though it could be more specific about the data scope.
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?
No guidance on when to use this tool versus alternatives (e.g., get_home_chart for charts, get_home_summary for summaries). The description does not mention context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a summary of active/recent user programs.
| Name | Required | Description | Default |
|---|---|---|---|
| timezone_offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It only states 'summary of active/recent user programs' without defining 'active' or 'recent', authentication needs, data limits, or side effects. This is insufficient for safe invocation.
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?
The description is a single sentence with no wasted words, but it is too brief to convey necessary information. It front-loads the action but omits crucial context, making it adequate in structure but lacking in content.
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?
Given a single optional parameter and the presence of an output schema (not shown), the description still leaves ambiguity about what constitutes 'active/recent', how results are scoped, and whether the timezone offset is required. It does not stand alone.
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?
The only parameter (timezone_offset) has 0% schema description coverage, and the tool description does not explain its purpose or usage. The agent has no clue what this parameter does or how it affects results.
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 states it retrieves a summary of active/recent user programs, using a specific verb and resource. It distinguishes from siblings like list_all_programs (all programs) and get_program_details (detailed view of one program).
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, session context, or compare with siblings like list_enrolled_programs or get_home_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get dashboard summary statistics (total workouts, weight, streak).
| Name | Required | Description | Default |
|---|---|---|---|
| timezone_offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behaviors. It only states what data is returned, but omits critical details such as whether the operation is read-only, auth requirements, rate limits, or the effect of the timezone_offset parameter. For a tool with zero annotations, this is insufficient.
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?
The description is a single sentence, making it concise. However, it sacrifices essential information (parameter semantics, usage context) for brevity. It is not well-structured to front-load the most critical details.
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?
The tool has a simple output schema, but the description omits the input parameter entirely. Given the low tool complexity and presence of output schema, the description is minimally adequate but lacks completeness regarding the timezone_offset parameter.
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 0%—the description does not mention the only parameter (timezone_offset). It adds no meaning beyond the schema, failing to explain its purpose or default value. With low coverage, the description should compensate but does not.
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 states the tool retrieves dashboard summary statistics, listing specific examples (total workouts, weight, streak). This differentiates it from sibling tools like get_home_chart and get_home_muscle, which likely return different data.
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?
No guidance on when to use this tool versus siblings like get_home_chart or list_enrolled_programs. No context on prerequisites, expected states, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current user's profile and settings from Boostcamp.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It indicates a read operation but does not mention authentication requirements, rate limits, or response structure. For a simple 0-parameter tool, this is minimally adequate but lacks depth.
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?
The description is a single, front-loaded sentence with no wasted words. Every part is meaningful, conveying exactly the tool's purpose.
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?
Given the tool's simplicity (0 parameters) and presence of an output schema, the description is nearly complete. It could mention that the output schema details the profile and settings, but it's not necessary. Missing some context on when to use it.
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?
There are no parameters, so schema coverage is 100%. The description does not need to compensate, and it correctly implies no input is needed. The baseline of 3 is raised to 4 because the description aligns with the schema's emptiness.
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 states the verb 'Get' and the resource 'current user's profile and settings'. It explicitly distinguishes from sibling tools which focus on home charts, muscles, programs, etc., by specifying it's about the user's own profile.
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?
The description provides no guidance on when to use this tool versus alternatives like 'get_home_summary' or 'list_enrolled_programs'. It only states what the tool does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the user's payment history.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden; it only states the action without disclosing behavioral traits like pagination, authentication, or data scope.
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?
A single sentence that is concise and focused, with no wasted words.
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?
While the tool is simple with no parameters and an output schema exists, the description lacks any contextual guidance about return value or use cases, making it just adequate.
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?
No parameters exist and schema coverage is 100%, so baseline is 4; the description adds no param info but none is needed.
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 states the verb 'Get' and the resource 'payment history', distinguishing it from sibling tools that deal with charts, muscles, programs, etc.
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?
No guidance is provided on when to use this tool versus alternatives, nor any context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific program by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| program_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only states the basic function. It doesn't disclose any behavioral traits like permissions, data freshness, or what 'detailed information' comprises, though the output schema exists.
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?
Single, succinct sentence with no filler. Every word contributes to understanding the tool's core purpose.
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 get-by-ID tool with an output schema, the description is minimally adequate. However, lacking annotations and schema descriptions, it could better set expectations about return structure or data availability.
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 0%, so the description should clarify the program_id parameter format or origin. It only mentions 'by its ID' without adding meaningful detail beyond the schema field type.
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 states the tool retrieves detailed info about a single program by ID, distinguishing it from list tools like list_all_programs and other get_* tools focusing on different resources.
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?
No guidance on when to use this tool versus alternatives. For example, it doesn't clarify that this is for specific program details while list_all_programs returns a summary list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the user's training history. Default timezone offset is -300.
| Name | Required | Description | Default |
|---|---|---|---|
| timezone_offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behaviors. It mentions a default timezone offset but omits details like data freshness, pagination, or any side effects. The behavioral coverage is minimal.
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?
The description is very short and front-loaded with the main action. While concise, it sacrifices useful information, making it minimally acceptable but not efficient.
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?
Given the tool has one parameter and an output schema, the description should fully explain the parameter's semantics and any default assumptions. It does not, leaving the agent to guess about the role of timezone_offset.
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?
The parameter 'timezone_offset' has 0% schema description coverage. The description adds the default value but fails to explain what the parameter does or how it affects the response. This is insufficient for an agent to use the parameter correctly.
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 states the verb 'Get' and the resource 'user's training history', making the purpose immediately understandable. However, it does not differentiate from sibling tools like get_home_chart or get_home_summary, which also deal with user-specific data.
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?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, typical scenarios, or conditions for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available programs with pagination and optional keyword search.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| page_size | No | ||
| keyword | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states the tool performs a list operation with pagination and keyword search, implying a read operation, but does not disclose behavior such as authentication requirements, sorting, or error handling.
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?
The description is a single, front-loaded sentence that conveys the core functionality without extraneous details. It is concise and well-structured for quick reading.
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?
Given the tool's simplicity (3 parameters, output schema present), the description is adequate but minimal. It does not address common concerns like user authentication, response structure, or limitations, though the output schema may cover return values.
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 0%, so the description must compensate. It mentions 'pagination' and 'optional keyword search' but does not explain what 'page', 'page_size', or 'keyword' mean beyond their names. The description adds minimal value over the parameter names.
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 states the verb 'list' and the resource 'all available programs', with pagination and optional keyword search. It distinguishes the tool from siblings like 'get_program_details' and 'list_enrolled_programs', which have more specific scopes.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not specify prerequisites, exclusions, or contextual conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List blog posts with pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| page_size | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. Only states 'with pagination', missing details on read-only nature, ordering, or potential side effects. For a listing tool, this is minimal.
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?
Extremely concise, single phrase. While not verbose, it is appropriately sized for a simple list operation, though it sacrifices detail.
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?
Given the existence of an output schema, the description need not detail return fields. However, it lacks usage and param guidance, making it adequate but not complete for a tool with no annotations.
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 0% description coverage for parameters. Description mentions pagination but does not explain the meaning of 'page' or 'page_size', nor their defaults. Fails to compensate for the schema's lack of documentation.
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?
Description clearly states 'List blog posts' with a specific verb and resource, clearly distinguishing it from other list tools like list_all_programs. However, it lacks specifics on filtering or sorting, which would make it a 5.
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?
No guidance on when to use this tool versus siblings. There are multiple list and get tools, but the description offers no context for when to choose list_blogs over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the custom exercises created by the user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior; it only states 'list', omitting details about pagination, ordering, or what constitutes a custom exercise.
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?
Single sentence with no wasted words; concise and front-loaded with the key action and resource.
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?
Tool is simple and output schema exists, but description lacks explanation of 'custom exercises' and how this tool fits into the broader context of sibling tools.
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?
No parameters, so schema coverage is 100%; description adds appropriate meaning by specifying the resource scope (custom exercises created by the user).
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?
Description clearly states action ('list') and resource ('custom exercises created by the user'), distinguishing it from sibling tools that list other resources like programs or blogs.
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?
No guidance on when to use this tool vs alternatives; no context about prerequisites, filtering, or intended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all fitness programs the user is currently enrolled in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description indicates a read-only operation but does not disclose any behavioral traits such as authentication requirements, data freshness, or pagination. It is adequate but minimal.
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?
Single, straightforward sentence with no unnecessary words. Perfectly structured for immediate understanding.
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?
Tool has zero parameters and an output schema, so the description sufficiently covers its purpose. No missing context given its simplicity.
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?
No parameters exist; schema coverage is 100%. No additional semantic value needed beyond what the empty schema already provides. Baseline score of 4 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?
Clearly states it lists programs the user is currently enrolled in, using a specific verb ('list') and resource ('enrolled programs'), distinguishing it from sibling tools like 'list_all_programs'.
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?
Implied usage for viewing enrolled programs, but no explicit when-to-use or when-not-to-use guidelines or mention of alternatives like 'list_all_programs' for broader scope.
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. Dates show when Glama detected each change.
v0.1.0get_home_chartget_home_muscleget_home_programsget_home_summaryget_my_profileget_payment_historyget_program_detailsget_training_historylist_all_programslist_blogslist_custom_exerciseslist_enrolled_programsEach tool targets a distinct resource or aspect (home charts, muscle, programs, summary, profile, payment, program details, training history, and various list operations). No two tools have overlapping purposes, making selection unambiguous.
All tools use a consistent verb_noun pattern: `get_` for single items or summaries and `list_` for collections. The naming is predictable and uniform.
With 12 tools, the server covers the main areas of a fitness dashboard (home, profile, programs, history, etc.) without being too few or too many. The count is well-scoped for its purpose.
The tool set is entirely read-only (all get/list). Missing common mutations like creating custom exercises, enrolling in programs, or updating profile settings. While adequate for a query interface, it lacks lifecycle operations typical for a full-featured server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create Hevy routines and analyze your training from chat. Unofficial; BYO Hevy PRO API key.
Manage fitness coaching clients, workouts, programs, chats and funnels from your assistant.
Log workouts and meals by telling your AI. 873 exercises, muscle diagrams, food lookup.
Connect ChatGPT or Claude to your Gym Plus account to log and review workouts with AI coaching.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dcaslin/boostcamp-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
