NameDay MCP

Server Details

Look up Swedish name days by date or name. Find out which names are celebrated today, discover the names associated with any calendar date, or find the name day for a specific name.

The service provides Swedish name day information, including name meanings, cultural and historical background, alternative spellings, and name variants.

Ownership verified

Status: Healthy
Uptime: 100.0% over the last 24 hours
Last Tested: 2026-11-09 22:26
Transport: Streamable HTTP · MCP 2025-11-25
URL
ChatGPT: –
Claude: –

TDQS

A4.5/5.0

Scored 2026-10-21 16:25 across 4 tools

Disambiguation5/5

Each tool targets a distinct query type: a single date, a whole month, today's date, or a name-to-date match. Although get_nameday_today overlaps with get_nameday_by_date for the current date, the descriptions explicitly direct usage and eliminate ambiguity.

Naming Consistency4/5

Names follow a consistent snake_case verb_noun_by_pattern, but minor deviations exist: get_namedays_by_month uses plural 'namedays' while get_nameday_by_date uses singular, and match_nameday_by_name uses 'match' instead of 'get'.

Tool Count5/5

Four tools is well-scoped for a read-only Swedish nameday lookup service. Each tool covers a distinct access pattern without excess.

Completeness4/5

The surface covers the core lookup needs: by date, by month, today, and by name. A minor gap is the lack of a bulk year or date-range operation, but the month tool makes such queries possible through repeated calls.

Available Tools

4 tools

get_nameday_by_dateA

Read-onlyIdempotent

Inspect

Read-only lookup for Swedish nameday names on a calendar date.

The lookup uses the recurring month-and-day calendar; no year is needed.

Use get_nameday_today for the current date. Invalid dates raise an error; dates without nameday entries return an empty names list.

Name	Required	Description	Default
`mm_dd`	Yes	Calendar date in zero-padded MM-DD format, such as 03-14. February 29 is accepted.

Output Schema

Name	Required	Description
`date`	Yes	Nameday date in MM-DD format.
`names`	Yes	Names celebrated on this date, with their slug, description, and variants. Names follow the order listed in the nameday data.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, idempotent, non-destructive, non-open-world behavior. The description adds genuinely new context: no year is required because the calendar recurs, invalid dates raise an error, and valid dates with no entries return an empty names list.

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 short, front-loaded sentences with no filler; the core capability comes first, followed by the sibling routing and edge-case behavior.

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?

An output schema exists, so return shape need not be described, yet the description still covers the empty-list edge case and error behavior. For a single-parameter read tool, nothing an agent needs to call it correctly is missing.

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% and the schema already specifies zero-padded MM-DD format and the Feb 29 acceptance, so the baseline is 3. The description reinforces the semantics (recurring month-and-day, no year) but adds no format detail 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?

States a specific verb+resource+scope: a read-only lookup of Swedish nameday names for a given calendar date. It also names the sibling get_nameday_today as the differing case, so an agent can distinguish it without opening the schema.

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?

Explicitly routes the current-date case to get_nameday_today, which is clear usage guidance. It does not address the other two siblings (get_namedays_by_month, match_nameday_by_name), so the alternative space is only partially covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_namedays_by_monthA

Read-onlyIdempotent

Inspect

Read-only lookup for Swedish nameday names in a calendar month.

Use the calendar month number (1 for January through 12 for December); no year is needed.

Returns dated entries with names and their details, ordered by date. Dates without nameday entries are omitted. Use get_nameday_by_date for a single date, get_nameday_today for today's date, or match_nameday_by_name if you know a name.

Name	Required	Description	Default
`month`	Yes	Calendar month number from 1 to 12.

Output Schema

Name	Required	Description
`result`	Yes	Ordered nameday entries for the requested month. Each entry contains a date and its names with their details. Dates without nameday entries are omitted.

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: results are ordered by date and dates without nameday entries are omitted. It stops short of anything else, but that is the meaningful addition 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?

Three short sentences, each earning its place: scope, input convention, output ordering. The alternative-routing guidance is packed at the end without padding or repetition.

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?

An output schema exists, so return values need no full explanation, yet the description still notes ordering and omitted empty dates. Input convention is stated, siblings are named, and annotations carry the safety profile — nothing an agent needs to invoke this correctly is missing.

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% and documents the range, so the baseline is 3. The description goes further by clarifying that the value is a month number and that no year is required, which resolves an ambiguity the schema alone does not (whether a year accompanies the month).

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?

States a specific verb and resource ('Read-only lookup for Swedish nameday names') scoped to a calendar month. It distinguishes itself from all three siblings by naming them, so an agent can route correctly without opening any schema.

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 routes the agent: get_nameday_by_date for a single date, get_nameday_today for today, match_nameday_by_name if a name is known. It also states the input convention ('month number 1-12; no year is needed'), leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_nameday_todayA

Read-onlyIdempotent

Inspect

Read-only lookup for Swedish nameday names for today's date in Europe/Stockholm time. For another date, use get_nameday_by_date.

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
`date`	Yes	Nameday date in MM-DD format.
`names`	Yes	Names celebrated on this date, with their slug, description, and variants. Names follow the order listed in the nameday data.

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveness, and closed-world scope. The description reinforces 'read-only' and adds a meaningful behavioral detail not in the annotations: the timezone (Europe/Stockholm) that defines what 'today' means, which prevents an agent from assuming UTC.

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 tight sentences with no filler. The primary behavior is front-loaded and the alternative-tool advice follows in a single clause.

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?

An output schema exists, so return-value explanation is unnecessary. The description covers scope, timezone, and the alternative routing, which is everything needed for a zero-parameter lookup 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?

Zero parameters, so there are no parameter semantics to explain; the baseline of 4 applies. The description correctly does not invent or dwell on parameters it doesn't have.

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?

States a specific verb ('lookup'), resource ('Swedish nameday names'), and scope ('today's date in Europe/Stockholm time'). It explicitly names the sibling get_nameday_by_date as the differentiator, so an agent can distinguish it without inspecting schemas.

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 when to use this tool (for today's date) and names the alternative (get_nameday_by_date) with the condition that selects it (another date). Routing is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

match_nameday_by_nameA

Read-onlyIdempotent

Inspect

Read-only match from a name to a Swedish nameday; returns the matched name and all names for its date.

matched_name is the canonical spelling the query resolved to and is always one of the returned names; those others are celebrated on the same date. A configured variant comes back as its canonical name, so a query for Kalle returns matched_name "Karl", and a fuzzy match returns the closest candidate that passes the checks below.

Fuzzy matching normalizes the query and candidate names, scores candidates from 0 to 100, and checks only the highest-scoring candidate. It must meet min_score and have a normalized length between half and twice the candidate's normalized length. If it fails either check, no match is returned; the next-best candidate is not tried. Ties select the first candidate in the nameday data. Configured exact variants bypass fuzzy matching. Raises an error if no match is found. If you already have a date, use get_nameday_by_date or get_nameday_today for the current date.

Name	Required	Description	Default
`name`	Yes	Name to match against Swedish nameday entries.
`min_score`	No	Minimum fuzzy-match score to accept on a 0-100 scale. Higher values require a closer match. Configured exact variants bypass this threshold.

Output Schema

Name	Required	Description
`date`	Yes	Nameday date in MM-DD format.
`names`	Yes	Names celebrated on this date, with their slug, description, and variants. Names follow the order listed in the nameday data.
`matched_name`	Yes	The name the query matched, always one of `names`. Fuzzy matches and configured variants return the canonical spelling, so `Kalle` resolves to `Karl`.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial behavior beyond them: normalization, 0-100 scoring, only the top candidate checked, the min_score and length-ratio gates, no fallback to next-best, tie-breaking by first-in-data, exact-variant bypass, and error on no match.

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?

Front-loads the core purpose and then layers matching semantics efficiently; every sentence carries real information about fuzzy-match behavior or routing. It is somewhat dense and longer than typical, but no sentence is wasted.

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 an output schema present, return values need not be explained, yet the description still clarifies matched_name semantics. Combined with full parameter coverage and rich fuzzy-matching behavior, an agent has everything needed to call it 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 baseline is 3, but the description adds meaning beyond the schema: how min_score actually gates the single highest-scoring candidate and that the next-best candidate is never tried, plus what matched_name resolves to. This enriches both parameters beyond their terse 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?

States a specific verb+resource ('read-only match from a name to a Swedish nameday') plus the return shape (matched name and all names for its date). It also names the sibling tools to use when a date is already known, so an agent can distinguish it from get_nameday_by_date/get_nameday_today without opening schemas.

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 routing is provided: 'If you already have a date, use get_nameday_by_date or get_nameday_today for the current date.' It also describes when fuzzy matching applies versus configured exact variants and that an error is raised on no match, giving clear when-to-use and when-not context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 21, 2026

Changedmatch_nameday_by_name3 fields changed

addedOutput schema / properties / matched_name

Added value: +{
+  "description": "The name the query matched, always one of `names`. Fuzzy matches and configured variants return the canonical spelling, so `Kalle` resolves to `Karl`.",
+  "title": "Matched Name",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "date",
-  "names"
-]New value: +[
+  "date",
+  "names",
+  "matched_name"
+]

changedOutput schema / title

Previous value: -"NameDayResponse"New value: +"NameMatchResponse"

1 tool updateOct 17, 2026

Changedget_namedays_by_month1 field changed

addedOutput schema / properties / result / description

Added value: +"Ordered nameday entries for the requested month. Each entry contains a date and its names with their details. Dates without nameday entries are omitted."

1 tool updateOct 17, 2026
- Addedget_namedays_by_month

3 tool updatesOct 16, 2026

Changedget_nameday_by_date7 fields changed

addedInput schema / properties / mm_dd / description

Added value: +"Calendar date in zero-padded MM-DD format, such as 03-14. February 29 is accepted."

addedOutput schema / $defs / NameItem / properties / description / description

Added value: +"Swedish background and meaning for the name; may contain HTML markup."

addedOutput schema / $defs / NameItem / properties / name / description
```
Added value: +"The Swedish nameday name."
```
addedOutput schema / $defs / NameItem / properties / slug / description
```
Added value: +"URL-friendly slug for the name."
```
addedOutput schema / $defs / NameItem / properties / variants / description
```
Added value: +"Alternative spellings or forms of the name."
```
addedOutput schema / properties / date / description
```
Added value: +"Nameday date in MM-DD format."
```

addedOutput schema / properties / names / description

Added value: +"Names celebrated on this date, with their slug, description, and variants. Names follow the order listed in the nameday data."

Changedget_nameday_today6 fields changed
- addedOutput schema / $defs / NameItem / properties / description / description
```
Added value: +"Swedish background and meaning for the name; may contain HTML markup."
```
- addedOutput schema / $defs / NameItem / properties / name / description
```
Added value: +"The Swedish nameday name."
```
- addedOutput schema / $defs / NameItem / properties / slug / description
```
Added value: +"URL-friendly slug for the name."
```
- addedOutput schema / $defs / NameItem / properties / variants / description
```
Added value: +"Alternative spellings or forms of the name."
```
- addedOutput schema / properties / date / description
```
Added value: +"Nameday date in MM-DD format."
```
- addedOutput schema / properties / names / description
```
Added value: +"Names celebrated on this date, with their slug, description, and variants. Names follow the order listed in the nameday data."
```

Changedmatch_nameday_by_name8 fields changed

addedInput schema / properties / min_score / description

Added value: +"Minimum fuzzy-match score to accept on a 0-100 scale. Higher values require a closer match. Configured exact variants bypass this threshold."

addedInput schema / properties / name / description

Added value: +"Name to match against Swedish nameday entries."

addedOutput schema / $defs / NameItem / properties / description / description

Added value: +"Swedish background and meaning for the name; may contain HTML markup."

addedOutput schema / $defs / NameItem / properties / name / description
```
Added value: +"The Swedish nameday name."
```
addedOutput schema / $defs / NameItem / properties / slug / description
```
Added value: +"URL-friendly slug for the name."
```
addedOutput schema / $defs / NameItem / properties / variants / description
```
Added value: +"Alternative spellings or forms of the name."
```
addedOutput schema / properties / date / description
```
Added value: +"Nameday date in MM-DD format."
```

addedOutput schema / properties / names / description

Added value: +"Names celebrated on this date, with their slug, description, and variants. Names follow the order listed in the nameday data."

3 tool updatesOct 15, 2026
- First observedget_nameday_by_date
- First observedget_nameday_today
- First observedmatch_nameday_by_name

Publisher details

Operator: Zeronine
Operator website: https://namnsdag.09999990.xyz
Vendor relationship: Unknown
Documentation: Unknown
Trust center: Unknown
Restrictions: Not applicable

Related MCP Connectors

SweKit - Swedish validatorsA
dev.workers.zenith-ops.swekit-api
Swedish personnummer/orgnr/bankgiro/OCR validation, kontonummer to IBAN, bankdagar.
Developer Tools Finance
131
https://swekit-api.zenith-ops.workers.dev/mcp
SweKit - Swedish validatorsA
dev.workers.erikssonanton2001.swekit-api
Swedish personnummer/orgnr/bankgiro/OCR validation, kontonummer to IBAN, bankdagar.
Finance Payments & Billing Developer Tools
1
https://swekit-api.erikssonanton2001.workers.dev/mcp
Aleva open dataB
se.aleva
Swedish public data as read-only tools: registries, statistics, domains, transport, energy.
Government Data Open Data
471
https://api.aleva.se/mcp
FirmafaktaA
se.firmafakta
Swedish company data: segment companies by industry, place and size, and look up any company.
Search Open Data Government Data
131
https://mcp.firmafakta.se

Related MCP Servers

Nameday MCP Server
Art & Culture Search
radoone
A
license
Not graded
quality
D
maintenance
Provides nameday information for 11+ countries, allowing users to find namedays by name, date, or today's celebrations.
Updated a year ago (2025-09-19 21:56 UTC)
1
MIT
Apiverket MCP Server
Government Data Open Data
vinvuk
A
license
A
quality
D
maintenance
Query Swedish public data from AI tools. Includes company data, SCB statistics, weather, transport, public agencies, and more through the Apiverket API.
Updated 5 months ago (2026-06-23 05:55 UTC)
2
60 npm
2
MIT
swehockey
Sports Open Data
troelskn
F
license
Not graded
quality
D
maintenance
Enables AI assistants to look up Swedish ice-hockey data from stats.swehockey.se — schedules & results, standings, team rosters, and season-total scoring & goalie stats.
Updated 3 months ago (2026-08-10 10:04 UTC)
-
mcp-ukrainian-calendar
Art & Culture Education & Learning Tools
ChuprinaDaria
A
license
Not graded
quality
D
maintenance
Provides access to Ukrainian pagan calendar with holidays, deities, folk wisdom, and birth charms, enabling users to query today's holidays, upcoming events, deity details, and personal birth charms.
Updated 7 months ago (2026-04-08 11:45 UTC)
7 npm
5
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?