Geodb Cities MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
There is significant overlap between tools like 'city_located_in' and 'place_located_in' which serve similar purposes for different entity types, and 'place_time' vs 'place_date_time' vs 'time_zone' which all handle time-related queries with subtle distinctions. However, most tools have clear primary functions (e.g., 'admin_divisions_near_location' vs 'places_near_location') that help differentiate them.
Naming Consistency4/5
The naming follows a consistent snake_case pattern throughout with clear verb_noun or noun_verb_noun structures (e.g., 'admin_divisions_near_location', 'place_details'). Minor inconsistencies exist like 'place_date_time' using an incorrect ISO standard reference (6801 instead of 8601) and 'time_zone' being more terse than others, but overall the pattern is predictable.
Tool Count4/5
With 18 tools, the count is slightly high but reasonable for a geographic database server covering administrative divisions, cities, places, and time data. It provides comprehensive query capabilities without being overwhelmingly large, though some consolidation might improve coherence.
Completeness5/5
The tool set offers complete coverage for querying geographic entities (places, cities, administrative divisions) with details, proximity searches, containment relationships, and time information. There are no obvious gaps—agents can retrieve, filter, and relate geographic data effectively across the domain.
Average 3/5 across 18 of 18 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- 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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions filtering capabilities, it doesn't describe important behavioral aspects: whether this is a read-only operation, what format the results come in, whether there are rate limits or authentication requirements, or what happens when no divisions are found. The description is too minimal for a tool with 17 parameters and no output schema.
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 extremely concise - a single sentence that efficiently states the core functionality. It's front-loaded with the main purpose and includes the filtering aspect. While perhaps too brief given the tool's complexity, every word serves a purpose with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 17 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'divisions' are in this context, what format results come in, whether there are pagination considerations (despite limit/offset parameters), or any error conditions. The description leaves too many questions unanswered for proper agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'filtering by optional criteria' which aligns with the many filter parameters in the schema. However, with 100% schema description coverage, the schema already documents all 17 parameters thoroughly. The description adds minimal value beyond what's already in the parameter descriptions, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Get divisions near the given administrative division, filtering by optional criteria.' This clearly indicates a retrieval operation with filtering capabilities. However, it doesn't distinguish this tool from its sibling 'admin_divisions_near_location' (which appears to search near coordinates rather than a division ID), leaving some ambiguity about when to use one versus the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'admin_divisions_near_location' and 'admin_division_details' available, there's no indication of when this specific tool (searching near a division) is preferred over searching near coordinates or getting division details directly. The description only states what the tool does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only mentions the core action and optional filtering, lacking details on permissions, rate limits, pagination (despite an 'offset' parameter), error handling, or what the output looks like (no output schema). For a tool with 17 parameters, this leaves significant behavioral gaps.
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, clear sentence that efficiently states the core action and scope. It's front-loaded with the main purpose and avoids unnecessary words, though it could be more structured by explicitly mentioning key parameters or output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (17 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain the return type, pagination behavior, error cases, or how 'places' are defined relative to siblings. For a rich filtering tool, more context on usage and output is needed to be 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?
Schema description coverage is 100%, so the schema fully documents all 17 parameters. The description adds no parameter-specific information beyond implying filtering exists ('optional criteria'), which doesn't enhance understanding of individual parameters. This meets the baseline for high schema coverage but doesn't add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose ('Get places near the given place') with a verb and resource, but it's vague about what 'places' means compared to siblings like 'admin_divisions_near_division' or 'cities_near_division'. It doesn't specify if 'places' refers to cities, administrative divisions, or other geographic entities, making sibling differentiation unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'places_near_location' (which uses coordinates instead of placeId) or 'admin_divisions_near_division'. It mentions 'filtering by optional criteria' but doesn't explain when those filters are appropriate or what scenarios this tool is designed for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states a read operation ('Get') without disclosing behavioral traits such as rate limits, authentication needs, pagination (implied by limit/offset but not explained), error handling, or what 'places' entails (e.g., cities, towns). It lacks critical context for safe and effective use.
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, efficient sentence with zero waste—'Get the places in the given region'—front-loaded and appropriately sized for its purpose. Every word earns its place without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (15 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'places' are, how results are returned, or behavioral aspects like pagination or errors. For a tool with rich filtering options, more context is needed to guide effective use.
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 15 parameters thoroughly. The description adds no parameter semantics beyond implying filtering by region, which is covered by required parameters 'countryid' and 'regionId'. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the places in the given region' states a clear verb ('Get') and resource ('places'), but it's vague about what qualifies as a 'place' (cities, towns, etc.) and doesn't distinguish from siblings like 'country_places' or 'places'. It specifies 'region' but lacks detail on region scope versus 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'country_places', 'places', or 'admin_divisions'. It mentions 'region' but doesn't clarify context, exclusions, or prerequisites, leaving usage ambiguous relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states basic functionality without behavioral details. It doesn't disclose whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior (despite limit/offset parameters), or what happens with invalid inputs. The description adds minimal value beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys the core purpose with zero waste. The description is appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 17 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain return format, result ordering, error conditions, or how the various filters interact. The agent would struggle to use this effectively without trial and error.
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 17 parameters thoroughly. The description adds no additional parameter semantics beyond mentioning 'optional criteria' - it doesn't explain parameter relationships, default behaviors, or usage patterns. Baseline 3 is appropriate when schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('administrative divisions near the given location') with optional filtering. It distinguishes from siblings like 'admin_division_details' (single division) and 'admin_divisions' (general list), but doesn't explicitly differentiate from 'admin_divisions_near_division' (similar but uses division vs location).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'admin_divisions_near_division' (near division vs location) or 'places_near_location' (places vs administrative divisions). The description mentions optional filtering but provides no context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('Get cities...') without mentioning any behavioral traits such as rate limits, authentication requirements, error handling, or response format. For a tool with 18 parameters and no output schema, this lack of behavioral context is a significant gap, leaving the agent uncertain about how the tool operates beyond basic functionality.
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, efficient sentence that front-loads the core purpose without unnecessary elaboration. It uses clear language and avoids redundancy, making it easy to parse. Every word serves a purpose, adhering to the principle that each sentence should earn its place, resulting in an optimally concise and well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, no output schema, and no annotations), the description is insufficiently complete. It lacks details on behavioral traits, usage guidelines relative to siblings, and output expectations. While the schema covers parameters, the description doesn't compensate for the absence of annotations or output schema, leaving significant gaps in understanding how to effectively use this tool in context.
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%, meaning all parameters are documented in the input schema. The description adds minimal value beyond the schema by mentioning 'filtering by optional criteria,' which aligns with the many filter parameters in the schema. However, it doesn't provide additional context on parameter interactions or usage examples, so it meets the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get cities near the given administrative division, filtering by optional criteria.' It specifies the verb ('Get'), resource ('cities'), and scope ('near the given administrative division'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'places_near_location' or 'admin_divisions_near_division,' which could cause confusion about when to use this specific tool versus alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'filtering by optional criteria' but doesn't specify scenarios or prerequisites for its use. With sibling tools like 'places_near_location' and 'admin_divisions_near_division' available, the lack of differentiation leaves the agent without clear usage context, potentially leading to incorrect tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Get' but doesn't disclose behavioral traits like whether this is a read-only operation, potential rate limits, authentication needs, or what the output format looks like (e.g., list of divisions with details). For a tool with 13 parameters and no output schema, this is a significant gap.
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, clear sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return values, behavioral constraints, or how it differs from siblings. For a data retrieval tool with many filtering options, more context is needed to guide effective use.
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 fully documents all 13 parameters. The description adds no additional meaning beyond implying filtering by region, which is already covered by the required 'regioncode' parameter. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('administrative divisions in the given region'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'admin_divisions' or 'country_region_places', which likely have overlapping functionality, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., 'admin_divisions', 'country_region_places'), there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'Gets' distance, implying a read-only operation, but doesn't mention any behavioral traits such as performance considerations, error handling, or what the output might look like (e.g., numeric distance, formatted string). This leaves significant gaps for a tool with no annotation coverage.
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, efficient sentence that directly states the tool's purpose without any wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of calculating distances between places, the lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a distance value, units, or possible errors), which is crucial for an AI agent to use it correctly. The high schema coverage helps, but overall context is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any meaning beyond what the input schema provides. With 100% schema description coverage, the schema already documents all three parameters clearly, including defaults and examples. The description doesn't explain parameter interactions or provide additional context, so it meets the baseline but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Gets') and resource ('this place's distance to the given place'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'places_near_place' or 'places_near_location', which might offer similar proximity-related functionality, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'places_near_place' and 'places_near_location' that might handle distance or proximity queries, there's no indication of how this tool differs or when it's the appropriate choice, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that filtering is optional and the default returns all places, but doesn't address critical behaviors: whether this is a read-only operation, potential rate limits, authentication needs, pagination behavior (despite 'limit' and 'offset' parameters), or what happens with large result sets. For a tool with 18 parameters and no annotation coverage, this is inadequate.
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 and front-loaded: two clear sentences that directly state the tool's core functionality and default behavior. Every word earns its place with zero redundancy or fluff. It efficiently communicates the essential information in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, no annotations, no output schema, many siblings), the description is insufficiently complete. It doesn't help an agent understand when to choose this tool over alternatives, doesn't explain behavioral constraints, and doesn't clarify what 'all known places' means in practice. For a search/filter tool with rich parameter options, more context about use cases and limitations is needed.
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 fully documents all 18 parameters. The description adds no parameter-specific information beyond implying that criteria are optional. It doesn't explain parameter interactions, default behaviors beyond the all-places return, or provide examples. With complete schema coverage, the baseline is 3, and the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find places, filtering by optional criteria.' It specifies the verb ('find') and resource ('places'), and mentions the optional filtering capability. However, it doesn't explicitly differentiate this tool from its many sibling tools (like 'places_near_location' or 'places_near_place'), which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance: 'If no criteria are set, you will get back all known places.' This explains the default behavior but offers no guidance on when to use this tool versus its many siblings (e.g., 'places_near_location' for proximity searches or 'country_places' for country-specific queries). There's no mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action ('Get places') without detailing aspects like rate limits, authentication needs, error handling, or response format. This leaves significant gaps for a tool with 18 parameters and no output 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 a single, efficient sentence that front-loads the core purpose without unnecessary words. It effectively communicates the essential function in a compact form, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (18 parameters, no annotations, no output schema), the description is insufficient. It lacks details on behavioral traits, output format, error conditions, and usage context, leaving the agent with inadequate information to invoke the tool effectively in varied scenarios.
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 input schema fully documents all parameters. The description adds no additional meaning beyond implying filtering capabilities ('optional criteria'), which does not enhance parameter understanding beyond the schema. This meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get places near the given location, filtering by optional criteria.' It specifies the verb ('Get'), resource ('places'), and scope ('near the given location'), but does not explicitly differentiate it from sibling tools like 'places_near_place' or 'cities_near_division', which limits it to a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'optional criteria' but does not specify contexts, prerequisites, or exclusions, nor does it reference sibling tools for comparison, resulting in minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the output format but fails to describe other key behaviors: whether this is a read-only operation, if it requires authentication, potential rate limits, error handling, or timezone validation. For a tool with no annotations, this leaves significant gaps in understanding its operational traits.
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 and front-loaded, consisting of a single sentence that directly states the tool's function and output format. There is no wasted verbiage, making it efficient for quick comprehension by an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It specifies the output format but doesn't cover behavioral aspects like safety, permissions, or error responses. For a tool that likely interacts with timezone data, more context on limitations or usage scenarios would enhance completeness, especially with sibling tools present.
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 description coverage is 100%, with the parameter 'zoneid' fully documented in the input schema. The description adds no additional meaning beyond what the schema provides, such as examples of timezone IDs or format constraints. Since the schema handles the parameter documentation adequately, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the time-zone current time in ISO-6801 format: HHmmss.SSSZ'. It specifies the verb ('Get'), resource ('time-zone current time'), and output format. However, it doesn't explicitly differentiate from sibling tools like 'place_time' or 'place_date_time', which might offer similar functionality, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools such as 'place_time' and 'place_date_time' available, there's no indication of context, prerequisites, or exclusions for selecting this tool over others. This lack of comparative guidance limits its utility for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions what details are returned but doesn't cover important aspects like whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or data freshness. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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, well-structured sentence that efficiently conveys the core functionality without unnecessary words. It's appropriately sized for a straightforward lookup tool and front-loads the essential information.
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 the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool returns but doesn't address behavioral aspects or usage context. Without annotations or output schema, more detail about return format, errors, or operational constraints would improve completeness.
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 three parameters. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain format expectations for divisionId or clarify what 'asciiMode' does). With complete schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('administrative division'), and specifies the types of details returned (location coordinates, population, elevation). However, it doesn't explicitly differentiate this tool from sibling tools like 'place_details' or 'admin_divisions', which might also provide administrative division information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that might overlap (e.g., 'place_details', 'admin_divisions'), there's no indication of whether this tool is for detailed single-division lookup, how it differs from broader listing tools, or any prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It reveals one important behavioral trait: the default population threshold of 1000 when no criteria are set. However, it doesn't address other critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior (despite limit/offset parameters), or what the return format looks like. For a tool with 17 parameters and no annotations, this leaves significant gaps.
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 appropriately concise with just two sentences. The first sentence establishes the core purpose, and the second provides important default behavior information. Every sentence earns its place, though it could be slightly more structured by explicitly mentioning it's a query/filtering tool upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (17 parameters, no annotations, no output schema), the description is insufficiently complete. While it explains the default population threshold, it doesn't address the tool's overall behavior, return format, error conditions, or how the numerous filtering parameters interact. For a rich query tool with many options, the description should provide more context about what 'administrative divisions' encompasses and typical use cases.
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%, meaning all parameters are documented in the schema itself. The description adds minimal parameter semantics beyond the schema - it only mentions the population threshold of 1000 when no criteria are set, which relates to minPopulation parameter behavior. Since the schema does the heavy lifting, the baseline of 3 is appropriate, though the description could have better explained how parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find administrative divisions, filtering by optional criteria.' This specifies both the verb ('find') and resource ('administrative divisions'), making it immediately understandable. However, it doesn't explicitly differentiate this tool from its siblings like 'admin_division_details' or 'admin_divisions_near_location', which prevents a perfect score.
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 provides some usage guidance by explaining what happens 'If no criteria are set' (returns all known divisions with population ≥1000), which helps understand default behavior. However, it doesn't offer explicit guidance on when to use this tool versus alternatives like 'admin_divisions_near_location' or 'admin_division_details', leaving the agent to infer based on parameter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s] the places,' implying a read-only operation, but does not specify whether it requires authentication, has rate limits, returns paginated results, or handles errors. For a tool with 14 parameters and no annotations, this is a significant gap in transparency.
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, clear sentence: 'Get the places in the given country.' It is front-loaded with the core purpose and contains no unnecessary words, making it highly efficient and easy to parse.
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 the tool's complexity (14 parameters, no output schema, no annotations), the description is minimal. It adequately states the purpose but lacks behavioral details, usage guidelines, and output information. While the schema covers parameters well, the overall context for an AI agent to use the tool effectively is incomplete, placing it at the minimum viable level.
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 100% description coverage, with each parameter well-documented (e.g., 'types' specifies allowed values, 'minPopulation' explains filtering). The description adds no additional parameter semantics beyond the schema, but since schema coverage is high, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the places in the given country.' It specifies the verb ('Get') and resource ('places'), and the scope ('in the given country') is explicit. However, it does not differentiate this tool from sibling tools like 'places', 'country_region_places', or 'admin_divisions', which might offer similar functionality, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks any mention of sibling tools (e.g., 'places' or 'country_region_places') or specific contexts where this tool is preferred, such as filtering by country versus other geographic scopes. Without such information, the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the output format but doesn't mention whether this is a read-only operation, potential errors (e.g., invalid placeId), rate limits, or authentication needs. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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, efficient sentence that front-loads the core purpose and includes essential format details. There's no wasted text, and it's appropriately sized for a simple tool.
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 the tool's low complexity (1 parameter, no output schema, no annotations), the description covers the basic purpose and output format. However, it lacks details on error handling, usage context, or behavioral traits, making it minimally adequate but with clear gaps for practical use.
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 description coverage is 100%, with the 'placeId' parameter documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as examples or constraints. Baseline 3 is appropriate since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('this place's current date-time'), specifying the output format ('ISO-6801 format: yyyyMMdd'T'HHmmssZ'). It distinguishes from sibling tools like 'place_time' or 'time_zone' by focusing on a specific place's current datetime, but doesn't explicitly differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'place_time' or 'time_zone'. The description implies usage for retrieving a place's datetime, but lacks explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions what data is returned but doesn't cover critical aspects like whether this is a read-only operation, error handling, rate limits, authentication needs, or data freshness. For a tool with no annotation coverage, this is a significant gap.
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, efficient sentence that front-loads the core purpose and lists key data fields without unnecessary words. Every part earns its place, making it easy to scan and understand quickly.
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 annotations and no output schema, the description is minimally adequate for a simple lookup tool. It specifies the resource and data fields but lacks details on behavior, errors, or output structure. For a tool with 3 parameters and no structured safety hints, it should do more to be fully helpful.
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 three parameters. The description doesn't add any parameter-specific details beyond implying 'placeId' is used to identify the place, which is redundant with the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('details for a specific place'), and lists key data fields (location coordinates, population, elevation). However, it doesn't explicitly differentiate from sibling tools like 'places' or 'place_located_in', which might offer overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., 'places', 'place_located_in', 'admin_division_details'), there's no indication of prerequisites, context, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns current time in a specific format, implying it's a read-only operation, but doesn't mention any behavioral traits like rate limits, error handling, or data freshness. For a tool with no annotations, this is a significant gap in transparency.
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 and front-loaded in a single sentence: 'Get this place's current time in ISO-8601 format: HHmmss.SSSZ'. Every word earns its place by specifying the action, resource, and output format without any waste or redundancy.
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 the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally complete. It states what the tool does and the output format, but lacks context on usage relative to siblings, behavioral details, or parameter meaning. This is adequate for a simple tool but leaves gaps that could hinder effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. The schema has 100% coverage with one parameter 'placeId' documented, so the baseline is 3. The description doesn't explain what a 'placeId' represents, its format, or how it relates to the output, leaving the schema to handle all parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get this place's current time in ISO-8601 format: HHmmss.SSSZ'. It specifies the verb 'Get' and the resource 'place's current time', along with the output format. However, it doesn't explicitly differentiate from sibling tools like 'place_date_time' or 'time_zone', which likely have related functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools related to time and places (e.g., 'place_date_time', 'time_zone'), but the description doesn't mention any context, prerequisites, or exclusions for usage. This leaves the agent to guess based on tool names alone.
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 provided, the description carries the full burden of behavioral disclosure. It adds useful context about data dependency on Wikidata and potential issues, which helps set expectations. However, it doesn't cover other behavioral aspects like rate limits, authentication needs, error handling, or response format. The description provides some transparency but leaves gaps for a tool with no annotations.
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 appropriately sized with two sentences: the first front-loaded with the core functionality, and the second providing important contextual caveats. There's minimal waste, though the parenthetical examples and formatting could be slightly tightened. Every sentence adds value, making it efficient but not perfectly concise.
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 annotations and no output schema, the description provides adequate context for a simple lookup tool with one parameter. It explains what data is returned and includes a caveat about data quality. However, it doesn't fully address the lack of output schema by detailing return values or structure, and the sibling tool context is underdeveloped. It's minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'cityId' documented as requiring a string like 'Q65'. The description doesn't add any parameter-specific information beyond what the schema provides, such as explaining what 'cityId' represents or format details. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the details for the containing populated place (e.g., its county or other administrative division), including location coordinates, population, and elevation above sea-level (if available).' It specifies the verb ('Get'), resource ('containing populated place'), and scope of data returned. However, it doesn't explicitly distinguish this from sibling tools like 'place_located_in' or 'admin_division_details', which appear related.
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 provides implied usage guidance by noting data dependency on Wikidata's 'locatedIn' relation and suggesting to propose changes if issues arise. However, it lacks explicit guidance on when to use this tool versus alternatives like 'place_located_in' or 'admin_division_details', and doesn't mention prerequisites or exclusions. The context is clear but incomplete for sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the tool returns specific data types (coordinates, population, elevation), has data quality dependencies on Wikidata's 'locatedIn' relation, and includes a call-to-action for reporting issues. However, it doesn't mention performance characteristics, error handling, or response format details.
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 appropriately sized with two well-structured sentences: the first clearly states the tool's purpose and return data, the second provides important behavioral context about data dependencies. The information is front-loaded with the core functionality first. Minor points deducted for slightly awkward formatting with extra spaces and the parenthetical '(if available)' could be more concise.
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?
For a single-parameter tool with no annotations and no output schema, the description provides adequate coverage of what the tool does and its data dependencies. However, it doesn't describe the return format structure, doesn't explain what happens when no containing place exists, and doesn't provide examples of typical responses. The Wikidata dependency note is valuable context but doesn't fully compensate for missing output information.
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 has 100% description coverage for its single parameter (placeId), so the baseline is 3. The description doesn't add any parameter-specific information beyond what the schema provides - it doesn't explain what format placeId should be in, provide examples beyond the empty schema example, or clarify how it relates to the administrative containment query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the details for the containing populated place' with specific examples (county or administrative division) and data types (coordinates, population, elevation). It distinguishes from siblings like 'place_details' by focusing on administrative containment rather than general place details. However, it doesn't explicitly contrast with 'city_located_in' which appears to be a similar sibling.
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 provides implied usage context through the Wikidata dependency note, suggesting this tool should be used when administrative containment data is needed and warning about data reliability issues. However, it doesn't explicitly state when to use this vs. alternatives like 'admin_division_details' or 'city_located_in', nor does it provide clear exclusion criteria or prerequisites.
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:

[![bachai-geodb-cities MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-geodb-cities/badges/card.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-geodb-cities)

Score Badge

Copy to your README.md:

[![bachai-geodb-cities MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-geodb-cities/badges/score.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-geodb-cities)

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/BACH-AI-Tools/bachai-geodb-cities'

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