Iridium MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.13.0
Disambiguation4/5
Most tools have clearly distinct purposes, with detailed descriptions that clarify overlaps (e.g., get_nutrition_log vs get_food_entries). A few pairs like get_workout_history/get_workout_detail and get_exercise_progress/get_personal_records could cause minor confusion, but descriptions resolve boundaries.
Naming Consistency5/5
All tools follow a consistent verb_object pattern in snake_case (e.g., get_*, log_*, update_*, list_*). No mixing of conventions like camelCase or inconsistent verb styles.
Tool Count5/5
19 tools cover the full domain of fitness tracking (training, nutrition, hydration, body measurements, profile) without feeling bloated or sparse. Each tool serves a clear purpose within the scope.
Completeness3/5
Covers nutrition and hydration entry well, but training tools are mostly read-only (no create/update workouts, no log training sessions). Body measurements are get-only. Notable gaps in data entry for training and measurements limit full lifecycle coverage.
Average 4.1/5 across 19 of 19 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It implies read-only behavior ('get') but does not explicitly state safety, authentication requirements, rate limits, or default ranges. The description adds some context (fatigue, recovery) 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence conveys the tool's purpose efficiently with no redundant information. 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.
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 could clarify return format, pagination, or default behavior (e.g., date range). It mentions fatigue and recovery but does not specify the structure. Adequate but not fully complete for a 3-parameter read tool.
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%, so baseline is 3. The description reinforces that the tool focuses on muscle groups over time, but does not add new parameter-level semantics beyond the 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 clearly states it retrieves volume adaptation records with fatigue levels and recovery decisions, which distinguishes it from sibling tools like get_training_summary or get_exercise_progress. However, no explicit differentiation from siblings is provided.
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 on when to use this tool versus alternatives. It does not specify prerequisites, common use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It does not mention authentication needs, pagination behavior, or what happens when no logs exist. The tool name implies read-only, but this is not explicitly stated.
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 sentence of 14 words that conveys the essential purpose with no redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no annotations, and the description does not explain the structure of return values (e.g., fields, types). For a tool returning analysis logs, this leaves a significant knowledge gap for the AI agent.
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% for the single parameter 'limit', which is already fully described in the schema. The description adds no additional meaning beyond the schema.
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 uses a specific verb ('Get') and resource ('weekly AI trainer analysis logs') and clearly distinguishes from sibling tools like get_weekly_schedule or get_workout_history.
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 alternatives, nor when not to use it. The description simply states what it does without contextual recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states the basic purpose. It does not disclose behavioral traits such as read-only nature, authentication needs, or data recency. The description adds no value beyond purpose.
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?
Single concise sentence that front-loads the action and resource. No wasted words.
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?
Given zero parameters and no output schema, the description is adequate but could be improved. It does not specify the time period (e.g., current week vs. any week) or whether it returns data for the authenticated user only.
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 0 parameters, so the schema coverage is trivially 100%. According to the rubric, 0 parameters yields a baseline of 4. The description does not need to add parameter details.
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 states the tool retrieves a weekly training schedule with muscle group or workout type assignments per day. The verb 'Get' and resource 'weekly training schedule' are specific and distinguish it from siblings like get_workout_history or get_training_volume.
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 on when to use this tool vs alternatives. The description does not indicate circumstances for use, exclusions, or mention of when to prefer other tools like get_workout_history for past data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It indicates a read-only operation (no side effects mentioned) and outlines returns: recent sets, weight progression, estimated 1RM. However, it does not disclose edge cases like empty history, time range limitations, or authentication needs.
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?
Two sentences front-loaded with the verb and resource ('Get performance history and 1RM trends'). No filler words, every sentence adds value.
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 one parameter, no output schema, and no annotations, the description adequately explains the tool's output (recent sets, weight progression, estimated 1RM). It could mention that progress data must exist or that it covers all time, but overall it is largely sufficient for a simple getter.
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 coverage is 100% with one parameter described as 'The exercise ID'. The description adds context by stating 'for a specific exercise' but does not provide format constraints or usage examples. Baseline 3 applies since schema already defines the parameter.
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 verb 'Get' and the resource 'performance history and 1RM trends for a specific exercise', using domain-specific terms like '1RM' and 'weight progression'. It effectively distinguishes from siblings which cover trainers, weekly schedule, workouts, nutrition, etc.
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 explicit guidance on when or when not to use this tool, nor alternatives among siblings. The description implies usage for querying progress per exercise but lacks prerequisites like 'requires logged workout data' or 'best used for strength exercises'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It accurately implies a read operation but does not mention any potential limitations, error conditions, or authorization requirements. It is adequate but not enhanced.
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 sentence that is front-loaded with the key purpose, listing specific details it returns. No unnecessary words; each part earns its place.
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 low complexity (single parameter, no output schema required), the description adequately covers the return content. It does not mention error handling or missing data cases, but for a basic retrieval tool this is acceptable.
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?
The description adds no additional meaning beyond the input schema, which already describes workout_id as 'The workout UUID'. With 100% schema description coverage, baseline score of 3 is appropriate.
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 verb 'Get' and the resource 'full details of a specific workout', listing specific included fields (exercises, sets, weights, reps, RPE, block structure). This distinguishes it from sibling tools like get_workout_history (which lists workouts) and get_exercise_progress (which focuses on progress over time).
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 explicit guidance on when to use this tool versus alternatives is provided. While the purpose is clear, the description does not mention when not to use it or suggest alternative tools for related tasks (e.g., listing workouts vs. getting details).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the returned fields (1RM, heaviest weight, most reps, date) and the filtering behavior, but does not mention authentication requirements, rate limits, or handling of empty results. This is adequate but not fully transparent.
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 two sentences, front-loaded with the main action, and contains no superfluous information. Every word serves a purpose.
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?
For a simple retrieval tool with two optional parameters and no output schema, the description adequately explains what data is returned and the two modes of use. It does not specify ordering or behavior when limit is exceeded, but these are minor gaps.
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 coverage is 100%, so the schema already documents both parameters. The description adds context by mentioning 'across all exercises or for a specific exercise', reinforcing the exercise_name parameter's purpose. No additional meaning is needed beyond the schema.
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 retrieves personal records (PRs) for all or specific exercises, and lists the specific metrics shown (1RM, heaviest weight, most reps, date). This distinguishes it from sibling tools like get_exercise_progress or get_training_summary.
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 for retrieving PR data and mentions filtering by exercise, but does not explicitly state when to use this tool versus alternatives (e.g., get_exercise_progress), nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, the description carries the burden. It discloses date parsing behavior, timezone handling, and unit semantics (mass conversion, null for circumference). It does not mention auth, rate limits, or overall read-only nature, but the verb 'get' implies safety.
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?
Two concise sentences. The first covers purpose with examples, the second adds critical data format details. No superfluous content.
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?
No output schema, but the description explains expected fields (weight, body fat, etc.) and unit behavior. It also clarifies date handling. Missing details on sorting or pagination, but sufficient for a history retrieval tool.
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 covers 100% of parameters with descriptions. The description adds value by explaining date formats and unit behavior in returned data, but does not provide additional parameter-level context beyond what the schema says.
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?
Clearly states it retrieves body measurement history with examples (weight, body fat percentage). The tool name and description align, and it is distinct from sibling tools which focus on other domains like workouts or nutrition.
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 for fetching historical body measurements but does not provide explicit guidance on when to use this tool versus alternatives like get_workout_history or get_nutrition_log. No when-not or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that results include food entries, hydration entries, and a hydrationByDay rollup. It details date format support ('today', 'yesterday', YYYY-MM-DD, ISO timestamps) and local timezone interpretation. Constraints are explicit: ranges up to 90 days, results capped at 1000 entries with a truncated flag. There is no mention of authentication or rate limits, but for a read-only tool this is generally sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of about 150 words. It front-loads the main function and then provides usage guidance and constraints. While every sentence adds value, it is somewhat verbose and could be more tightly organized. A bulleted breakdown might improve scannability, but it is not excessively long.
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 complexity (3 parameters, no output schema, no annotations), the description covers the returned data, constraints, and alternative tool. It lacks explicit mention of output structure details but does describe the rollup. The tool's behavior is well-specified for an agent to invoke correctly.
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?
Schema description coverage is 100%, so the schema already describes each parameter. The description adds value by clarifying the exclusive use of date vs. from+to, explaining that ranges are inclusive and capped at 90 days, and detailing date format nuances including timezone handling. This context goes beyond what the schema alone provides.
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 retrieves full individual food entries with macros, nutrients, hydration data, and a rollup. It provides specific use cases ('what did I eat yesterday?') and explicitly distinguishes from get_nutrition_log for daily totals. This differentiates it from siblings effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: use this for detailed entry-level queries about 'what they ate' and for analysis, while referencing get_nutrition_log as the alternative for daily totals. It also explains parameter combinations (EITHER date OR from+to). However, it doesn't list every scenario where the tool should be avoided, but the provided context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It adequately states that the tool returns aggregate statistics (summaries) and hints at the types of data included. It does not disclose data freshness or caching, but for a simple read-only operation with no parameters, this is acceptable.
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 captures the tool's core function without any redundant or extraneous information. It is front-loaded and concise.
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 has no parameters and no output schema, the description provides a reasonable overview of what the output contains (workouts, frequency, streaks, patterns). It could be slightly more detailed about the output structure, but it is sufficient for a simple aggregate 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?
There are 0 parameters and schema description coverage is 100% (trivial). Per guidelines, baseline is 4. The description adds no extra parameter info, but none is needed.
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 uses the specific verb 'Get aggregate training statistics' and lists concrete examples (total workouts, exercise frequency, streaks, workout patterns), clearly distinguishing it from sibling tools like get_workout_history (individual workouts) or get_trainer_analysis (likely more analytical).
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 the tool is for aggregate summaries, but it does not explicitly state when to use this tool over alternatives like get_workout_history or get_exercise_progress. No exclusion or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly states the tool retrieves a profile and lists what it includes, which is sufficiently transparent for a read-only operation with no parameters. No side effects or auth requirements are mentioned, but not critical here.
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 sentence that is compact and front-loaded with the action and resource, followed by a concise list of contents. No wasted words.
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?
Given no parameters, no output schema, and a simple retrieval purpose, the description fully covers what the tool does. It provides sufficient context for an AI agent to understand its function without additional details.
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 input schema has no parameters, so description does not need to add param info. Schema coverage is 100% trivially, meeting the baseline of 4 for zero-parameter tools.
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 specifies the verb 'Get' and the resource 'the user's profile', listing specific contents like demographics, training goals, etc. This clearly distinguishes it from sibling tools like get_workout_history or get_nutrition_log.
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 this is for retrieving overall user profile, but does not explicitly compare to siblings or provide context on when to use this versus more specific tools like get_training_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It discloses the output structure (byDay with consumedML, goalML, etc.) and the fact that it covers hydration only, not food water content. It is transparent about the tool's behavior without contradictions.
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 concise, using a single paragraph of about four sentences. It is front-loaded with the main purpose and efficiently adds necessary details without redundancy.
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?
Despite the absence of an output schema and annotations, the description sufficiently covers input parameters and output structure. It explains the key fields and the scope of data, though it could mention error handling or empty results.
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?
Schema coverage is 100%, but the description adds value by explaining the exclusive relationship between 'date' and the 'from'/'to' pair, and by expanding on valid date formats. This goes beyond what the schema provides.
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 retrieves the user's water intake with individual entries and per-day totals against a saved goal. The verb 'Get' and resource 'hydration' are specific, and it distinguishes itself from sibling tools like log_hydration and get_nutrition_log by focusing on hydration data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios (e.g., 'how much water have I had today?') and clarifies what the tool does not cover (food water content). It explains date formats and parameter combinations, but does not explicitly compare to sibling tools for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing date interpretation in local timezone, multiple workouts per day, and the instruction to report every workout. It lacks mention of authentication or rate limits, but the behavioral details provided are strong.
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 concise and well-structured: a clear purpose sentence, output description, date behavior details, a usage tip, and an important warning. Every sentence adds value without redundancy.
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?
The tool has 5 parameters, all documented, and no output schema. The description explains return fields (date, exercises, duration, completion status) and covers key behaviors. It is missing default sort order and error handling for invalid dates, but overall it is complete for a filtered list 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?
Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining date formats in detail, giving a usage example for single-day queries, and clarifying timezone handling, which goes beyond the schema's parameter descriptions.
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 retrieves recent workout history with optional filtering, using a specific verb (Get) and resource (workout history). It distinguishes from siblings like get_workout_detail by specifying it returns summaries, not details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (getting recent history with filters) and provides usage tips like how to query a single day and warning about multiple workouts per day. It does not explicitly state when not to use it, but the context of sibling tools implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It explains the tool lists personal foods, should be called early, and implies it returns macros and serving info. However, it does not mention pagination, rate limits, or assume a complete list, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a coherent paragraph with front-loaded purpose, then usage guidance. Each sentence adds value, though it could be slightly more terse. It is well-structured but not maximally concise.
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 no output schema and no annotations, the description covers the tool's purpose, usage context, and result handling (macros and serving scaling). It lacks explicit output format specifications but is complete for decision-making.
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 input schema has zero parameters, so the description need not add parameter details. Baseline 4 applies, and the description adds useful context about when to call the tool but no parameter information is needed.
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 it lists the user's saved reusable foods ('My Foods in Iridium') and provides concrete examples (homemade shakes, bars, salads), making the purpose unmistakable and distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit instructions to call this FIRST when the user refers to a known food by name, with examples like 'log my blueberry shake' and fallback guidance. Also details how to reuse macros and scale servings, leaving no ambiguity about when and how to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses behavioral traits: date parsing formats, deduplication (identical calls within an hour treated as same entry), mutual exclusivity of amountOz/amountML. Does not mention authentication or rate limits, but covers key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is long but well-organized with clear sections (first sentence, 'USE THIS', 'PASS EITHER', 'Common volumes', 'DATE/TIMEZONE', 'DEDUPLICATION'). Every sentence adds value and is front-loaded. Could be slightly more concise but structure is effective.
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 4 parameters, no output schema, and complexity (date parsing, dual units, deduplication), the description covers essentials: when to use, parameters with examples, date handling, dedup rules. Minor gap: no mention of return value, but overall comprehensive.
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?
Schema coverage is 100% with good descriptions. The description adds value beyond schema: common volume conversions (cup=8 oz, etc.), requirement to pass EITHER amountOz OR amountML, date format details, and deduplication hints. Adds substantial context for parameter selection.
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 logs water or hydrating drink volume into the user's hydration tracker, distinguishes from log_food_entry by explaining that the 'water' field in food entries does not count toward the hydration ring. It provides specific usage examples like 'I had a glass of water' and 'log 16 oz of water'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'USE THIS — not log_food_entry' when the user mentions drinking water. Provides scenarios for when to use both tools (e.g., protein shake should log both food and fluid). Includes guidance on date/timezone parsing and deduplication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it explains the difference between calorieGoal and calorieGoalBase, mentions that values may be stale due to sync timestamps, and describes how the goal changes throughout the day in automatic+HealthKit mode. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but well-structured with bullet points and clear sections. It front-loads the purpose and uses natural breaks. It could be slightly more concise, but the detail is justified given the complexity of the return object.
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?
Despite having no output schema, the description explains all return fields and their meanings in detail, including optional fields and usage notes. It provides sufficient context for an agent to correctly interpret the data.
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?
The input schema has zero parameters, so schema coverage is 100%. Baseline is 3. The description adds no parameter info because none is needed.
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 it retrieves the user's current nutrition intent, including goal type, weight change, and daily targets. It distinguishes from sibling tools like get_nutrition_log by focusing on the current 'intent' and explicitly suggests combining with get_food_entries for consumption data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool (coaching the user, assessing deficit/conservativeness) and when to combine with get_food_entries. It also explains nuances like the dynamic nature of calorieGoal in HealthKit mode, ensuring the agent uses the correct field.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors beyond simple mutation: only works on chat-logged entries, omitted fields remain unchanged, and calories/macros must be totals for consumed amount. With no annotations, description carries full burden and does so well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single well-structured paragraph with examples, warnings, and important notes. Slightly dense but every sentence adds value. Could benefit from bullet points for clarity but still concise.
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 tool with 36 parameters and no output schema, description covers all critical context: id requirement, field omission behavior, special rules for calories/macros, and the chat vs. app distinction. No gaps.
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?
Schema coverage at 58% means many parameters have descriptions already. Description adds overarching semantics: only pass fields to change, total vs. per-serving rule. Given 36 parameters, this meta-information is valuable.
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?
Clearly states it updates a food entry logged via log_food_entry, with explicit examples ('wait, that was 2 cheeseburgers'). Distinguishes from sibling tools by referencing the source (chat vs. app) and the required id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance (after log_food_entry), example corrections, required id from prior response, and a clear error-handling instruction (apologise and direct to app on 404).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: it discloses the 404 error for Iridium app entries, implies it performs a partial update, and notes that the id is required. No contradictions.
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?
Three efficient sentences: action+example, required param, and constraint. No wasted words; front-loaded for quick 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?
Without an output schema, the description still covers error conditions (404) and valid entry scope. For a simple update tool, this is comprehensive.
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 coverage is 80% (4 of 5 params have descriptions). The description reiterates key points (id required, amount fields are corrected volumes) but adds no new meaning beyond the schema. Baseline is 3.
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 verb 'correct' and resource 'hydration entry', and provides a concrete example ('that was a 32 oz bottle, not 16'). It distinguishes itself from log_hydration and get_hydration by specifying it updates existing entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the required id from prior log_hydration response, advice to only pass changed fields, and a critical constraint: only works on chat-logged entries, not those from the Iridium app (returns 404). This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description provides extensive behavioral details: consumed totals are live and computed on every call, includes food logged before iOS sync, explains goal variants (calorieGoal vs effectiveCalorieGoal), and handles missing data gracefully with fallback instructions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but well-structured with bullet points and clear sections. Front-loads purpose and usage, then details. Every sentence adds value, though could be slightly more concise.
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 tool with 3 params, no output schema, and no annotations, the description is exceptionally complete. It details the return structure (consumed object, goal fields, hydration), edge cases (missing goals), and interpretation instructions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant value: explains accepted date formats ('today', 'yesterday', YYYY-MM-DD, ISO 8601), local timezone interpretation, and deprecation of the 'date' parameter with alternative suggestion.
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?
Clearly states it returns daily nutrition summaries over a date range with one row per day, including consumed totals, goals, hydration, and notes. Explicitly distinguishes from sibling tool get_food_entries for individual food-level detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies use cases (daily check-ins, trends, goal checking, weekly/monthly review) and explicitly directs to get_food_entries for food-level detail. Provides guidance on comparing effectiveCalorieGoal vs calorieGoal and hydration fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: mutation (logging), deduplication within one hour, sync timing to iOS app, and date/timezone interpretation. It also warns against logging water and instructs to omit uncertain micros.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (examples, warnings, date/timezone, deduplication). While a bit lengthy, every sentence adds value. Front-loads the core purpose and required fields effectively.
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?
Given the tool's complexity (35 parameters, no output schema), the description is remarkably complete. It covers usage guidelines, deduplication, sync behavior, date handling, and explicit exclusions (water). No gaps remain for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema: it explains that required fields must be totals for consumed amount, not per-serving, and clarifies the date parameter with examples of accepted formats and timezone resolution. It also advises on optional micros and the numberOfServings parameter for deduplication, which the schema does not detail.
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 logs a single food entry into the user's Iridium food diary, with examples like cheeseburger, snack, meal. It specifies required fields (name + calories + protein + carbs + fat) and distinguishes itself from the sibling tool log_hydration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use this tool vs log_hydration (e.g., do not log water here, use log_hydration instead). It also provides guidance on handling drinks that are both food and fluid, and explains deduplication behavior and how to log multiple servings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![iridium-mcp-server MCP server](https://glama.ai/mcp/servers/RosTeHeA/iridium-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/RosTeHeA/iridium-mcp-server)

Score Badge

Copy to your README.md:

[![iridium-mcp-server MCP server](https://glama.ai/mcp/servers/RosTeHeA/iridium-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/RosTeHeA/iridium-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/RosTeHeA/iridium-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server