castlemap-mcp

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: geographic search (castles_near), record retrieval (get_castle), aggregate statistics (get_statistics), country listing (list_countries), random sample (random_castle), name search (search_castles), and fame-ranked listing (top_castles). No overlap exists.
Naming Consistency3/5
Most tools follow a verb_noun pattern (e.g., get_castle, search_castles, list_countries), but 'castles_near' breaks the pattern with a noun_prep structure. Singular/plural usage is inconsistent (get_castle vs. search_castles), though readability is maintained.
Tool Count5/5
Seven tools is well-scoped for a read-only atlas of 2,400 landmarks. Each tool covers a distinct access pattern (search, random, near, stats, etc.) without redundancy or bloat.
Completeness4/5
The tool surface covers key operations: search, retrieval, statistics, and exploration. A minor gap is the lack of a generic 'list all' endpoint with pagination, but search may fill this role. The set is largely complete for its domain.
Average 4.2/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description alone covers behavior. Mentions default radius (100 km), max (2000), nearest-first ordering, and distance_km inclusion. Lacks info on auth, rate limits, empty result handling, or pagination. Adequate but gaps remain.
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, zero waste. First sentence conveys core purpose and output. Second sentence provides usage guidance. Purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description states distance_km included but other result fields unspecified. With 5 parameters and moderate complexity, covers essentials but lacks result format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 40% (limit and radius described in schema). Description adds radius default and max, plus geocoding hint. Latitude, longitude, and category lack parameter-level description beyond schema min/max/enum. Modest value added.
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?
Description states 'List landmarks within a radius of a WGS84 coordinate, nearest first, each with distance_km.' Verb 'list' and specific resource 'landmarks' (castles) with clear scope. Distinguishes from siblings like 'search_castles' (generic search) and 'top_castles' (non-geographic).
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 advises geocoding place first then calling with lat/lng. Implies when-not-to-use (e.g., for single castle use get_castle), but does not explicitly exclude alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses ordering by fame rank and that omitting country gives worldwide results. However, it does not mention that the tool is read-only, nor does it describe any limitations or special behaviors beyond the rank explanation.
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: the first defines the result ordering, the second explains usage and filtering. Every sentence is meaningful and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could benefit from mentioning the return structure (e.g., list of castle names with rank). It adequately covers functionality but lacks completeness on response format.
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 covers 67% of parameters with descriptions. The description adds context by explaining the ranking and that category is a filter. It does not introduce new parameter semantics beyond reinforcing the filter concept.
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 that the tool returns the most famous landmarks worldwide or in a country, ordered by a specific fame rank. It distinguishes itself from siblings like 'search_castles' or 'castles_near' by focusing on ranking based on fame.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it is the direct answer for 'most famous castles in <country>' and allows filtering by country and/or category. However, it does not explicitly state when not to use this tool or mention alternative tools for different queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states it returns a random landmark with full record, but 'full record' is vague. No mention of edge cases like country not found, or randomness details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is mostly complete. It lacks specifics about the return format (what constitutes a 'full record') and error handling, but covers the main use case.
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% (country parameter explained). The tool description repeats 'optionally limited to a country' without adding new semantics. Baseline 3 applies.
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 returns a random castle, optionally filtered by country, and specifies use cases like discovery, quizzes, and 'castle of the day'. This distinguishes it from siblings like get_castle (specific), search_castles (multiple), etc.
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 use cases (discovery, quizzes, castle of the day) implying when to use it. However, it does not explicitly exclude cases like getting a specific castle or performing a search, though context suggests alternatives.
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 exist, so the description must disclose behavior. It says 'computed live' indicating freshness, and lists what is included. However, it does not mention potential limitations (e.g., data scope, update frequency) or side effects, leaving minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loads the key purpose. Every sentence adds value with 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 no parameters or output schema, the description is fairly complete, explaining what statistics are provided and giving example queries. It could be improved by noting if any filters or scoping apply, but overall it covers the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline is 4. The description appropriately adds no parameter details since none exist, and the schema coverage is effectively 100%.
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 computes live headline statistics from the atlas, listing specific metrics like totals, top countries, and extremes. It distinguishes from siblings (e.g., get_castle, search_castles) by focusing on aggregate statistics.
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 example use cases such as 'which country has the most castles' and points to a reference for more details. It implicitly tells when to use this tool (for statistical queries) but doesn't explicitly exclude other tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses behavior: accent/case-insensitive substring matching, result ordering (best-match-then-fame), output fields (coordinates, century, fame rank, links), and retry advice. It does not mention authentication, rate limits, or mutability, but as a search tool it is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a purpose: first states the core action, second details optional filters, third describes result format and advice. No redundant information, well front-loaded.
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 100% schema coverage and no output schema, the description covers the search behavior, optional filters, result fields, and retry advice. It is complete for a search tool, though it could mention pagination or default limit behavior more explicitly (but limit is in schema).
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 beyond the schema by clarifying that query matching is accent/case-insensitive substring and that country accepts name or ISO code. It also explains default limit behavior and result ordering, which the schema lacks.
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 searches the atlas's 2,400 castles by name with optional filters, using a specific verb 'search' and resource 'castles'. It distinguishes from siblings like 'castles_near' (likely location-based) and 'get_castle' (single item) by focusing on name-based substring search.
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 name-based searching and provides a retry hint for no matches, but does not explicitly say when to use this tool over alternatives or when not to use it. No exclusions or prerequisites are stated.
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?
Despite lacking annotations, the description discloses key behavioral traits: it returns all countries sorted by count descending, includes country name and ISO code, and mentions a URL for browsing. This is sufficient for a simple read-only tool, though it lacks details on data freshness or limits.
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 extremely concise at two sentences, front-loaded with the primary purpose and a practical use case. Every word adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is fully complete. It explains the output format, sorting, and provides an example answer, plus a link for further detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params), so the baseline score of 4 applies. The description adds no further parameter information, which is appropriate given the absence of parameters.
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 lists every country with its landmark count, sorted descending, and answers the specific question 'which country has the most castles'. The verb 'list' in the name and the explicit purpose differentiate it from siblings like search_castles or get_castle.
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 obtaining a broad overview of countries with castle counts, but does not explicitly state when to use this tool versus alternatives like castles_near or top_castles. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes exactly what data is returned (coordinates, founding year, fame rank, photo, Wikipedia link, readership signals). No annotations exist, so description carries full burden. It lacks mention of error behavior or rate limits but is thorough for a read 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, 55 words. Front-loads the action and resource, then provides a fallback hint. Every sentence is necessary and efficient.
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's simplicity (1 param, no output schema, no annotations), the description covers the key aspects: how to call it, what it returns, and when to use alternatives. Minor omissions like exact output structure are acceptable for a straightforward get operation.
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?
Input schema already covers the parameter with high coverage (100%), so baseline is 3. The description adds value by emphasizing slug preference and suggesting search_castles if unsure, which helps the agent select the correct input format.
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 'Fetch one landmark’s full record' using a slug or exact name, and lists the returned fields. It immediately distinguishes from sibling tools like search_castles by implying this is the full record retrieval, not a search.
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 tells when NOT to use ('Unsure of the slug?') and directs to the correct alternative ('Call search_castles first'). This provides clear guidance on when to use this tool versus its sibling.
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:

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

Score Badge

Copy to your README.md:

[![castlemap-mcp MCP server](https://glama.ai/mcp/servers/Flightmussy/castlemap-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Flightmussy/castlemap-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/Flightmussy/castlemap-mcp'

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