vitamind-mcp

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
Each tool targets a distinct function: city lookup, sun times, vitamin D windows (daily/annual), current status, session estimation, and user profile/history. Descriptions explicitly differentiate overlapping areas (e.g., 'for vitamin D questions use the vitamin_d tools instead'). No ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case: get_my_cities, search_city, get_sun_times, get_vitamin_d_window, get_vitamin_d_year, get_current_status, estimate_sun_session, get_my_profile, get_my_history, log_sun_session. Predictable and clear.
Tool Count5/5
10 tools is well-suited for the domain. The set covers location setup, sun data, vitamin D planning across timescales, current status, session estimation, and user management. No unnecessary tools, and the scope is focused.
Completeness4/5
The tool surface is comprehensive for vitamin D assistance: city search, sun times, daily/yearly vitamin D windows, current status, session estimation, and user profile/history. Minor gaps exist (no profile update or data deletion), but core workflows are covered.
Average 4.3/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on July 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses behavioral traits: uses live data when reachable, falls back to clear-sky model, and returns current UV index, minutes needed, and window timing. This is adequate for a read-only tool, though data freshness or caching is not mentioned.
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 single sentence that efficiently conveys purpose, data source, and return values. It is front-loaded with the key question. While slightly dense, every clause adds value and there is no 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?
Given the tool has 8 parameters (2 required), no output schema, and no annotations, the description provides sufficient context: it explains the high-level behavior, data source fallback, and lists the key return components (UV index, minutes needed, window). This allows an agent to understand tool usage and expected output.
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 the baseline is 3. The description adds context about location dependence (lat/lon) but does not elaborate on individual parameters beyond what the schema already provides. It does not compensate for any missing schema 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 checks if 'RIGHT NOW' is good for vitamin D synthesis using live UV/cloud data (or clear-sky fallback). It distinguishes from siblings like 'get_vitamin_d_window' (which likely returns just the window) and 'get_sun_times' (sun times only) by focusing on current moment and live data.
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 current moment decisions but does not explicitly state when to use this tool versus alternatives. It mentions data source conditions (live vs. clear-sky model) but no when-not-to-use or alternative tool names are provided.
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. It discloses that the tool returns historical data and requires OAuth. However, it does not explicitly state that it is a read-only operation or if it has any side effects. For a simple read tool, this is adequate but not thorough.
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, each earning its place: the first explains the purpose, the second states authentication requirements. No wasted words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description fully covers what the tool returns (history, streak) and its authentication needs. Given the complexity, it is complete.
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 schema covers 100% of parameters and includes a description for 'days' with default value. The tool description does not add any additional meaning beyond the schema, so baseline 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 tool returns the signed-in user's sun history from the app's calendar, specifying the data points (viable days, confirmations, streak). This sets it apart from sibling tools like get_my_profile or log_sun_session.
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?
It mentions the required OAuth scope (history:read), which is a key prerequisite. It does not explicitly state when to use vs alternatives, but the context of 'signed-in user' and 'history' naturally implies its use for personal historical 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 carries full burden. It discloses output includes estimated IU (with cap), average UV, and minutes-to-sunburn. However, it does not mention limitations such as ignoring weather or other factors affecting UV exposure, which would improve transparency for a simulation tool.
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 three sentences long, front-loaded with the core purpose. Every sentence contributes information without redundancy. It efficiently covers what, how, and when to use the tool.
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, the description adequately describes return values (IU, UV, minutes-to-sunburn). It covers all input parameters and defaults. For a moderately complex model with 10 parameters, it is largely complete, though could mention the output structure more explicitly.
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%, but the description adds context beyond the schema: it explains defaults (startTime defaults to best hour, skinType defaults to 3) and provides concrete examples for exposedSkinFraction (0.10 face+hands, etc.), which aids interpretation beyond parameter descriptions alone.
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 specifies the tool estimates two outcomes: vitamin D production (with physiological cap) and time to burn. It explicitly relates to 'how much vitamin D did I make?' and 'how long before I'd burn?', differentiating it from sibling tools like get_vitamin_d_window and get_vitamin_d_year which focus on broader time frames.
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 explicitly states 'Use for any 'how much did I get / can I get in X minutes' or 'how long without burning' question.' While it does not list when not to use, the context implies it is for single session estimation, and sibling tool names provide alternative use cases.
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 full burden. It discloses handling of midnight sun and polar night edge cases, and mentions day length trend behavior. However, it does not discuss authorization, rate limits, or data source freshness.
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 most important information (what times are returned), and wastes no words. Every sentence 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?
Given the complexity (4 parameters, no output schema, no annotations), the description is fairly complete: it lists all result types, mentions edge cases, and differentiates from siblings. It does not describe the return format, but this is acceptable without an output schema.
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 the schema already documents all parameters. The tool description adds no additional parameter semantics beyond what the schema provides (e.g., it does not repeat constraints or recommend timezone). 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 what the tool does: provides sunrise, sunset, solar noon, civil dawn/dusk, golden hour, and day length with trend for a location and date. It also distinguishes itself from sibling vitamin D tools, making the purpose unambiguous.
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 explicitly states when to use this tool (for pure sun times) and when not (for vitamin D questions, use vitamin_d tools). It implies usage for specific location/date queries, but does not provide alternative tools for other sub-types.
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 the full burden. It mentions the multi-language search and output fields, but lacks details on potential side effects, permissions, or limits (e.g., rate limits, data freshness). Adequate but not exhaustive.
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 with no wasted words. It is front-loaded with the main action and includes the crucial detail about multi-language support. Perfectly 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 low complexity (1 parameter, no output schema or annotations), the description is mostly complete. It explains the purpose and output usage. However, it could mention whether the search returns multiple cities or if it's a best-match, which would enhance completeness.
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% for the single parameter 'query', which is described as a city name. The description adds value by specifying that the name works in any of six languages, which is beyond the schema's basic type/description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: find a city by name in multiple languages and return coordinates, timezone, and elevation. It also distinguishes itself from sibling tools by indicating the output is meant to be fed into other tools.
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 implies usage context: when you need location data for other tools. It does not explicitly state when not to use it, but the context is clear and there are no competing siblings for city search.
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 explains the output structure and each field's meaning (viable days, solid months, exact season boundaries, aggregates). It does not disclose potential costs or data freshness, but covers the core behavior sufficiently.
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 focused sentences: first introduces the tool, second details output fields, third gives usage guidance. No wasted words; each sentence carries essential information.
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 description covers output fields and usage context well. However, with no output schema, the description could include more structural details (types, examples) to fully describe the complex return object, but it is still quite complete for an experienced user.
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 parameters are fully documented in the input schema. The description does not add new parameter-specific information beyond the schema, meeting the baseline for high coverage.
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 provides the whole year of solar vitamin D for a location, listing key output fields (monthsWithSun, solidMonths, exactViableSpan, summary). It distinguishes from the sibling tool get_vitamin_d_window by explicitly indicating when not to use that tool.
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 gives explicit guidance on when to use this tool ('any question about months, seasons, winter/summer') and when not to ('never probe individual dates'), directly naming the alternative tool get_vitamin_d_window.
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 the full burden. It discloses that minutes are 'acknowledged, not stored', requires OAuth scope history:write, and defaults to today. This provides useful behavioral context beyond the schema.
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 three sentences, front-loaded with the primary purpose, and contains no unnecessary words. Every sentence adds significant 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 the tool has two optional parameters, no output schema, and no nested objects, the description covers essential points: purpose, usage trigger, authentication, and parameter behavior. Siblings are diverse, and this tool's role is clearly defined.
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 noting that date defaults to today and minutes are acknowledged but not stored. These details are not present in the schema descriptions and help the agent understand parameter behavior.
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 marks a day as sun-confirmed in the signed-in user's history calendar, with a specific verb and resource. It distinguishes from sibling tools (e.g., get_my_history, estimate_sun_session) by being a write operation for logging actual sun exposure.
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 context: 'use when the user says they went (or will have gone) outside for their sun'. It also mentions defaulting to today and OAuth scope. It does not explicitly state when not to use, but the 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.
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 requires OAuth with scope profile:read, returns personal data (current and favorite cities), and provides coordinates/timezones. It implies no destructive effects, which is appropriate for a read-only tool.
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 concisely state the tool's output and authentication requirement. Information is front-loaded, with no extraneous 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?
For a zero-parameter tool with no output schema and no annotations, the description adequately describes the returned data (cities, coordinates, timezones), the user-specific nature, and auth needs. It also hints at its role as a data source for sibling tools.
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 with 100% schema coverage, so baseline is 3. The description does not need to add parameter info, and it doesn't.
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 signed-in user's current and favorite cities with coordinates and timezones. It distinguishes from siblings like search_city and get_current_status by specifying it returns user-specific city data ready for other tools.
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 mentions OAuth requirement and indicates that the output feeds into public tools, implying it should be used before tools like get_sun_times or get_vitamin_d_window. However, it does not explicitly state when not to use it or compare with alternatives like search_city.
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 takes on the full burden of behavioral disclosure. It discloses key behaviors: returns synthesisPossible=false when UV never reaches 3, adds minutesNeeded and UV at exact time with atTime, and notes that timezone is needed to avoid UTC defaults. It doesn't mention non-destructive nature, but that is implied by the read-only design. A clear, informative description.
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 single paragraph but well-structured, front-loading the main outputs and usage boundaries. It is relatively concise given the complexity of the tool, but could be improved slightly with bullet points or clearer separation of concepts.
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 10 parameters, no output schema, and moderate complexity, the description provides solid context: main output fields, the condition for synthesisPossible, and the effect of atTime. It lacks a full list of return fields but covers enough for an agent to understand the tool's basic functionality.
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?
All 10 parameters have schema descriptions, but the tool description adds extra semantic meaning beyond those. It explains how atTime modifies the output, gives examples for exposedSkinFraction (e.g., 0.10 face+hands), and contextualizes age and skin type. This aids the agent in understanding parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: providing the solar vitamin D synthesis window for a single specific day at a location. It uses specific verbs like 'synthesis window' and 'returns', and explicitly distinguishes itself from the sibling tool get_vitamin_d_year for multi-day questions.
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 states when to use this tool: 'Only for single-day questions', and provides a clear alternative: 'for months, seasons or when during the year, call get_vitamin_d_year instead'. This effectively differentiates from siblings and guides appropriate usage.
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?
Describes authentication requirement (OAuth, scope profile:read) and what data the tool returns, providing full behavioral context beyond the absent annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences with no extraneous content; the essential information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description covers all necessary details: auth, output fields, and usage pattern, making it complete.
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?
No parameters exist, and schema coverage is 100%. The description adds value by listing output fields, justifying a score above baseline 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 tool retrieves the signed-in user's saved Vitamin D profile, listing specific fields (skin type, age, etc.) and distinguishes it from sibling tools that handle cities, sun times, etc.
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 instructs to call this tool FIRST for any personal question, then pass values to public tools, and notes the OAuth requirement, offering clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

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

Score Badge

Copy to your README.md:

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

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/JaviMaligno/vitamind-mcp'

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