Connect your AI assistant to Vitamin D Explorer — so it can answer, for your actual location and skin type, whether the sun can make vitamin D right now, how long you'd need, and which months of the year it's possible at all.
Generic advice says "get 15 minutes of sun". That answer is wrong most of the time: skin type I in London and skin type V in Madrid need completely different exposure, and above about 40° latitude there are months where synthesis is physically impossible no matter how long you stay out.
"I'm in Vilnius, skin type II. Can I make vitamin D today?"
"Which months of the year can I get vitamin D in London?"
"I was out 25 minutes at noon in Madrid, arms and legs bare — how much did I make?"
"When's golden hour in Lisbon on Friday?"
Related MCP server: WeatherAPI MCP Server
Most clients can connect to the hosted server directly, with no install at all — see getvitamind.app/connect for per-client steps. Use this package when your client only launches local commands.
{
"mcpServers": {
"vitamind": {
"command": "npx",
"args": ["-y", "vitamind-mcp"]
}
}
}That's the whole configuration. No API key, no account.
Six public tools, no account needed:
Tool | Answers |
| Find a city and its coordinates, in any of the app's six languages |
| Sunrise, sunset, solar noon, civil dawn/dusk, both golden hours, day length |
| The synthesis window for one day: minutes needed, best hour, UV peak |
| The whole year in one call: which months work, which don't |
| Whether right now is a good moment, from live UV and cloud data |
| What a session produced — IU made, and minutes until burning |
Four more read your saved profile, favourite cities and sun history if you sign in
(get_my_profile, get_my_cities, get_my_history, log_sun_session). Those need
OAuth, which this bridge does not implement — connect the account endpoint directly, or:
npx mcp-remote https://getvitamind.app/api/mcp-auth/mcpNot a lookup table. Every answer is computed from:
Solar geometry — NOAA declination and elevation formulas.
UV model — Madronich (2007) clear-sky UVI with van Heuklon ozone by latitude, longitude and season, plus an altitude correction (~8% per km — enough to change which months work for a city like Bogotá).
Vitamin D synthesis — Holick & Dowdy (2010), with MED by Fitzpatrick skin type (I-VI) and the Holick (1989) age factor. Sessions saturate: past roughly ⅓ MED you gain little and burn risk rises, and the tools say so.
Live weather — Open-Meteo UV index and cloud cover.
Threshold for any synthesis at all: UV index ≥ 3. Below that the answer is honestly "not today, consider supplementing" rather than a smaller number.
| Endpoint to bridge to. Default |
| Same, as an environment variable |
A stdio↔HTTP relay, and nothing more. It forwards JSON-RPC messages verbatim between your client and the hosted server, so new tools appear without a release here. All the vitamin D logic lives in the hosted server — deliberately, since a second copy of the model in this package would drift from the app that people actually use.
Estimates for healthy skin under clear-sky or forecast conditions. They ignore aerosols, ground reflectance, sunscreen and individual variation, and they are not a substitute for advice from a professional. Do not use them to plan an intentional burn.
App: getvitamind.app
Setup guide: getvitamind.app/connect
Main repository: JaviMaligno/vitamind
MIT
Estimate a sun session's outcome: 'I was (or will be) out N minutes — how much vitamin D did I make?' plus 'how long before I'd burn?' for the profile. Takes a start time (defaults to the day's best hour) and session minutes; returns estimated IU (with the physiological cap), average UV and clear-sky minutes-to-sunburn. Use for any 'how much did I get / can I get in X minutes' or 'how long without burning' question.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Age in years (synthesis declines with age); omit for adult baseline | |
| lat | Yes | Latitude in decimal degrees | |
| lon | Yes | Longitude in decimal degrees | |
| date | No | Date as YYYY-MM-DD; defaults to today | |
| minutes | Yes | Session length in minutes | |
| skinType | No | Fitzpatrick skin type 1 (very fair) to 6 (very dark); default 3 | |
| timezone | No | IANA timezone like 'Europe/Madrid'. Strongly recommended — without it all times are UTC | |
| startTime | No | Local HH:MM the session starts; defaults to the day's best hour | |
| elevationM | No | Ground elevation in metres (UV rises ~8%/km); default sea level | |
| exposedSkinFraction | No | Skin exposed: 0.10 face+hands, 0.18 face+arms, 0.25 t-shirt+shorts (default), 0.40 swimsuit |
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.
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.
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.
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.
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.
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.
Whether RIGHT NOW is a good moment for vitamin D synthesis at a location, using live Open-Meteo UV/cloud data when reachable (clear-sky model otherwise): current UV index, minutes needed now, and when today's window opens or closes.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Age in years (synthesis declines with age); omit for adult baseline | |
| lat | Yes | Latitude in decimal degrees | |
| lon | Yes | Longitude in decimal degrees | |
| skinType | No | Fitzpatrick skin type 1 (very fair) to 6 (very dark); default 3 | |
| targetIU | No | Vitamin D target per session in IU; default 1000 | |
| timezone | No | IANA timezone like 'Europe/Madrid'. Strongly recommended — without it all times are UTC | |
| elevationM | No | Ground elevation in metres (UV rises ~8%/km); default sea level | |
| exposedSkinFraction | No | Skin exposed: 0.10 face+hands, 0.18 face+arms, 0.25 t-shirt+shorts (default), 0.40 swimsuit |
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.
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.
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.
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.
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.
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.
The signed-in user's current city and favorite cities with coordinates and timezones, ready to feed into the public tools. Requires OAuth (scope profile:read).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
The signed-in user's sun history from the app's calendar: which recent days had viable sun, which they confirmed going outside, and their current streak. Requires OAuth (scope history:read).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many recent days to return; default 30 |
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.
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.
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.
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.
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.
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.
The signed-in user's saved Vitamin D profile: skin type, exposed-skin default, age, target IU and their current city. Requires connecting with OAuth (scope profile:read). Call this FIRST for any personal question, then pass its values to the public tools instead of asking the user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Sunrise, sunset, solar noon, civil dawn/dusk, morning AND evening golden hour, and day length (with day-over-day trend) for a location and date. Handles midnight sun and polar night. Pure sun times — for vitamin D questions use the vitamin_d tools instead.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude in decimal degrees | |
| lon | Yes | Longitude in decimal degrees | |
| date | No | Date as YYYY-MM-DD; defaults to today | |
| timezone | No | IANA timezone like 'Europe/Madrid'. Strongly recommended — without it all times are UTC |
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.
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.
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.
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.
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.
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.
The solar vitamin D synthesis window for ONE specific day at a location, for a personal profile: when UV is strong enough (index ≥ 3), the best hour, the clear-sky minutes needed to reach the target IU, and (with atTime) the minutes at the specific hour the user plans to go out. Returns synthesisPossible=false when the sun never gets high enough that day. Only for single-day questions — for months, seasons or 'when during the year', call get_vitamin_d_year instead of calling this once per date.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Age in years (synthesis declines with age); omit for adult baseline | |
| lat | Yes | Latitude in decimal degrees | |
| lon | Yes | Longitude in decimal degrees | |
| date | No | Date as YYYY-MM-DD; defaults to today | |
| atTime | No | Local HH:MM the user plans to go out — adds minutesNeeded and UV at that exact time | |
| skinType | No | Fitzpatrick skin type 1 (very fair) to 6 (very dark); default 3 | |
| targetIU | No | Vitamin D target per session in IU; default 1000 | |
| timezone | No | IANA timezone like 'Europe/Madrid'. Strongly recommended — without it all times are UTC | |
| elevationM | No | Ground elevation in metres (UV rises ~8%/km); default sea level | |
| exposedSkinFraction | No | Skin exposed: 0.10 face+hands, 0.18 face+arms, 0.25 t-shirt+shorts (default), 0.40 swimsuit |
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.
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.
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.
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.
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.
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.
The WHOLE YEAR of solar vitamin D for a location in a single call. monthsWithSun lists every month with at least one viable day (season edges count as partial months, see byMonth[].viableDays); solidMonths lists months where most days work; exactViableSpan gives the exact season boundaries; summary carries per-year aggregates for comparing places. Use this for any question about months, seasons, winter/summer or 'when during the year can I…' — never probe individual dates with get_vitamin_d_window for that.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Age in years (synthesis declines with age); omit for adult baseline | |
| lat | Yes | Latitude in decimal degrees | |
| lon | Yes | Longitude in decimal degrees | |
| skinType | No | Fitzpatrick skin type 1 (very fair) to 6 (very dark); default 3 | |
| targetIU | No | Vitamin D target per session in IU; default 1000 | |
| timezone | No | IANA timezone like 'Europe/Madrid'. Strongly recommended — without it all times are UTC | |
| elevationM | No | Ground elevation in metres (UV rises ~8%/km); default sea level | |
| exposedSkinFraction | No | Skin exposed: 0.10 face+hands, 0.18 face+arms, 0.25 t-shirt+shorts (default), 0.40 swimsuit |
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.
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.
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.
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.
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.
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.
Marks a day as sun-confirmed in the signed-in user's history calendar — use when the user says they went (or will have gone) outside for their sun. Defaults to today. Requires OAuth (scope history:write).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Day to confirm, YYYY-MM-DD; defaults to today | |
| minutes | No | Minutes the user reports having spent in the sun (acknowledged, not stored) |
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.
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.
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.
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.
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.
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.
Find a city in the app's database by name (any of the app's six languages works) and get its coordinates, IANA timezone and elevation — feed those into the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | City name, e.g. 'Madrid', 'London', 'Nueva York' |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.1estimate_sun_sessionget_current_statusget_my_citiesget_my_historyget_my_profileget_sun_timesget_vitamin_d_windowget_vitamin_d_yearlog_sun_sessionsearch_cityEach 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Vitamin D synthesis calculator: sun position, UV, IU/min, time to dose, sunburn risk, daily window.
Know when the sun can make vitamin D where you are, for your skin type. Live UV data.
Where is it sunny? Monthly sunshine scores, temps, rain, UV and sea temp for 3,833 destinations.
Real-time weather conditions and multi-day forecasts via Open-Meteo — free, no API key required
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
