Provides tools to query and retrieve geographic data for cities and regions, utilizing Wikidata identifiers and relations to provide details like location coordinates, population, and elevation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Geodb Cities MCP Server find cities within 100km of Paris with a population over 500,000"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
用于访问 Geodb Cities API 的 MCP 服务器。
EMCP 是一个强大的 MCP 服务器管理平台，让您无需手动配置即可快速使用各种 MCP 服务器！
🌐 访问 EMCP 平台
📝 注册并登录账号
🎯 进入 MCP 广场，浏览所有可用的 MCP 服务器
🔍 搜索或找到本服务器（bach-geodb_cities）
🎉 点击 "安装 MCP" 按钮
✅ 完成！即可在您的应用中使用
✨ 零配置：无需手动编辑配置文件
🎨 可视化管理：图形界面轻松管理所有 MCP 服务器
🔐 安全可靠：统一管理 API 密钥和认证信息
🚀 一键安装：MCP 广场提供丰富的服务器选择
📊 使用统计：实时查看服务调用情况
立即访问 EMCP 平台 开始您的 MCP 之旅！
Related MCP server: Geocoding By API Ninjas
这是一个 MCP 服务器，用于访问 Geodb Cities API。
PyPI 包名: bach-geodb_cities
版本: 1.0.0
传输协议: stdio
pip install bach-geodb_citiespip install -e .# 运行（uvx 会自动安装并运行）
uvx --from bach-geodb_cities bach_geodb_cities
# 或指定版本
uvx --from bach-geodb_cities@latest bach_geodb_citiespython server.py# 安装
pip install bach-geodb_cities
# 运行（命令名使用下划线）
bach_geodb_cities此 API 需要认证。请设置环境变量:
export API_KEY="your_api_key_here"变量名 | 说明 | 必需 |
| API 密钥 | 是 |
| 不适用 | 否 |
| 不适用 | 否 |
编辑 Cursor MCP 配置文件 ~/.cursor/mcp.json:
{
"mcpServers": {
"bach-geodb_cities": {
"command": "uvx",
"args": ["--from", "bach-geodb_cities", "bach_geodb_cities"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}编辑 Claude Desktop 配置文件 claude_desktop_config.json:
{
"mcpServers": {
"bach-geodb_cities": {
"command": "uvx",
"args": ["--from", "bach-geodb_cities", "bach_geodb_cities"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}此服务器提供以下工具:
place_distanceGets this place's distance to the given place.
端点: GET /v1/geo/places/{placeId}/distance
参数:
distanceUnit (string): The unit of distance: KM | MI [default]
toPlaceId (string): The distance to this place
placeId (string) 必需: Example value:
place_timeGet this place's current time in ISO-8601 format: HHmmss.SSSZ
端点: GET /v1/geo/places/{placeId}/time
参数:
placeId (string) 必需: Example value:
place_date_timeGet this place's current date-time in ISO-6801 format: yyyyMMdd'T'HHmmssZ
端点: GET /v1/geo/places/{placeId}/dateTime
参数:
placeId (string) 必需: Example value:
place_located_inGet 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). Currently, this data is highly dependent on whether the Wikidata locatedIn relation is properly defined. If you see an issue, please propose a change to the corresponding Wikidata entry.
端点: GET /v1/geo/places/{placeId}/locatedIn
参数:
placeId (string) 必需: Example value:
place_detailsGet the details for a specific place, including location coordinates, population, and elevation above sea-level (if available).
端点: GET /v1/geo/places/{placeId}
参数:
languageCode (string): Display results in this language
asciiMode (string): Example value:
placeId (string) 必需: Example value:
city_located_inGet 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). Currently, this data is highly dependent on whether the Wikidata locatedIn relation is properly defined. If you see an issue, please propose a change to the corresponding Wikidata entry.
端点: GET /v1/geo/cities/{cityId}/locatedIn
参数:
cityId (string) 必需: Example value: Q65
places_near_locationGet places near the given location, filtering by optional criteria.
端点: GET /v1/geo/locations/{locationid}/nearbyPlaces
参数:
types (string): Only places for these types (comma-delimited): ADM2 | CITY | ISLAND
radius (string) 必需: The location radius within which to find places
distanceUnit (string): The unit of distance to use: MI | KM
countryIds (string): Only places in these countries (comma-delimited country codes or WikiData ids)
excludedCountryIds (string): Only places NOT in these countries (comma-delimited country codes or WikiData ids)
timeZoneIds (string): Only places in these time-zones
minPopulation (number): Only places having at least this population
maxPopulation (number): Only places having no more than this population
namePrefix (string): Only places whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language.
namePrefixDefaultLangResults (string): Example value:
languageCode (string): Display results in this language
asciiMode (string): Example value:
hateoasMode (string): Example value:
includeDeleted (string): Whether to include any places marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE
limit (number): The maximum number of results to retrieve
offset (number): The zero-ary offset into the results
sort (string): How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = countryCode | elevation | name | population
locationid (string) 必需: Only cities near this location. Latitude/longitude in ISO-6709 format: ±DD.DDDD±DDD.DDDD
places_near_placeGet places near the given place, filtering by optional criteria.
端点: GET /v1/geo/places/{placeId}/nearbyPlaces
参数:
types (string): Only places for these types (comma-delimited): ADM2 | CITY | ISLAND
radius (number) 必需: The location radius within which to find places
distanceUnit (string): The unit of distance to use: MI | KM
countryIds (string): Only places in these countries (comma-delimited country codes or WikiData ids)
excludedCountryIds (string): Only places NOT in these countries (comma-delimited country codes or WikiData ids)
timeZoneIds (string): Only places in these time-zones
minPopulation (number): Only places having at least this population
maxPopulation (number): Only places having no more than this population
namePrefix (string): Only places whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language.
namePrefixDefaultLangResults (string): Example value:
languageCode (string): Display results in this language
asciiMode (string): Example value:
hateoasMode (string): Example value:
includeDeleted (string): Whether to include any places marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE
offset (number): The zero-ary offset into the results
sort (string): How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = countryCode | elevation | name | population
placeId (string) 必需: Example value:
country_placesGet the places in the given country.
端点: GET /v1/geo/countries/{countryId}/places
参数:
types (string): Only cities for these types (comma-delimited): ADM2 | CITY | ISLAND
timeZoneIds (string): Only places in these time-zones
minPopulation (number): Only places having at least this population
maxPopulation (number): Only places having no more than this population
namePrefix (string): Only places whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language.
namePrefixDefaultLangResults (string): Example value:
languageCode (string): Display results in this language
asciiMode (string): Example value:
hateoasMode (string): Example value:
includeDeleted (string): Whether to include any cities marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE
limit (number): The maximum number of results to retrieve
offset (number): The zero-ary offset into the results
sort (string): How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = elevation | name | population
countryId (string) 必需: Example value: US
country_region_divisionsGet the administrative divisions in the given region.
端点: GET /v1/geo/countries/{countryid}/regions/{regioncode}/adminDivisions
参数:
minPopulation (number): Only cities having at least this population
maxPopulation (number): Only divisions having no more than this population
namePrefix (string): Only divisions whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language.
namePrefixDefaultLangResults (string): Example value:
languageCode (string): Display results in this language
asciiMode (string): Example value:
hateoasMode (string): Example value:
includeDeleted (string): Whether to include any cities marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE
limit (number): The maximum number of results to retrieve
offset (number): The zero-ary offset into the results
sort (string): How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = elevation | name | population
countryid (string) 必需: An ISO-3166 country code or WikiData id
regioncode (string) 必需: An ISO-3166 or FIPS region code
admin_division_detailsGet the details for a specific administrative division, including location coordinates, population, and elevation above sea-level (if available).
端点: GET /v1/geo/adminDivisions/{divisionId}
参数:
languageCode (string): Display results in this language
asciiMode (string): Example value:
divisionId (string) 必需: Example value: Q104994
cities_near_divisionGet cities near the given administrative division, filtering by optional criteria.
端点: GET /v1/geo/adminDivisions/{divisionId}/nearbyCities
参数:
types (string): Only cities for these types (comma-delimited): CITY | ADM2
radius (number) 必需: The location radius within which to find cities
distanceUnit (string): The unit of distance to use: MI | KM
countryIds (string): Only cities in these countries (comma-delimited country codes or WikiData ids)
excludedCountryIds (string): Only cities NOT in these countries (comma-delimited country codes or WikiData ids)
timeZoneIds (string): Only cities in these time-zones
minPopulation (number): Only cities having at least this population
maxPopulation (number): Only cities having no more than this population
namePrefix (string): Only cities whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language.
namePrefixDefaultLangResults (string): Example value:
languageCode (string): Display results in this language
asciiMode (string): Example value:
hateoasMode (string): Example value:
includeDeleted (string): Whether to include any cities marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE
limit (number): The maximum number of results to retrieve
offset (number): The zero-ary offset into the results
sort (string): How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = countryCode | elevation | name | population
divisionId (string) 必需: Example value: Q104994
admin_divisionsFind administrative divisions, filtering by optional criteria. If no criteria are set, you will get back all known divisions with a population of at least 1000
端点: GET /v1/geo/adminDivisions
参数:
location (string): Only divisions near this location. Latitude/longitude in ISO-6709 format: ±DD.DDDD±DDD.DDDD
radius (number): The location radius within which to find divisions
distanceUnit (string): The unit of distance to use: MI | KM
countryIds (string): Only divisions in these countries (comma-delimited country codes or WikiData ids)
excludedCountryIds (string): Only divisions NOT in these countries (comma-delimited country codes or WikiData ids)
timeZoneIds (string): Only divisions in these time-zones
minPopulation (number): Only divisions having at least this population
maxPopulation (number): Only divisions having no more than this population
namePrefix (string): Only divisions whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language.
namePrefixDefaultLangResults (string): Example value:
languageCode (string): Display results in this language
asciiMode (string): Example value:
hateoasMode (string): Example value:
includeDeleted (string): Whether to include any divisions marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE
limit (number): The maximum number of results to retrieve
offset (number): The zero-ary offset into the results
sort (string): How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = countryCode | elevation | name | population
country_region_placesGet the places in the given region.
端点: GET /v1/geo/countries/{countryid}/regions/{regionId}/places
参数:
types (string): Only cities for these types (comma-delimited): ADM2 | CITY | ISLAND
timeZoneIds (string): Only places in these time-zones
minPopulation (number): Only places having at least this population
maxPopulation (number): Only places having no more than this population
namePrefix (string): Only places whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language.
namePrefixDefaultLangResults (string): Example value:
languageCode (string): Display results in this language
asciiMode (string): Example value:
hateoasMode (string): Example value:
includeDeleted (string): Whether to include any cities marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE
limit (number): The maximum number of results to retrieve
offset (number): The zero-ary offset into the results
sort (string): How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = elevation | name | population
countryid (string) 必需: An ISO-3166 country code or WikiData id
regionId (string) 必需: Example value: CA
placesFind places, filtering by optional criteria. If no criteria are set, you will get back all known places.
端点: GET /v1/geo/places
参数:
types (string): Only places for these types (comma-delimited): ADM2 | CITY | ISLAND
location (string): Only places near this location. Latitude/longitude in ISO-6709 format: ±DD.DDDD±DDD.DDDD
radius (number): The location radius within which to find places
distanceUnit (string): The unit of distance to use: MI | KM
countryIds (string): Only places in these countries (comma-delimited country codes or WikiData ids)
excludedCountryIds (string): Only places NOT in these countries (comma-delimited country codes or WikiData ids)
timeZoneIds (string): Only places in these time-zones
minPopulation (number): Only places having at least this population
maxPopulation (number): Only places having no more than this population
namePrefix (string): Only places whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language.
namePrefixDefaultLangResults (string): Example value:
includeDeleted (string): Whether to include any places marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE
languageCode (string): Display results in this language
asciiMode (string): Example value:
hateoasMode (string): Example value:
limit (number): The maximum number of results to retrieve
offset (number): The zero-ary offset into the results
sort (string): How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = countryCode | elevation | name | population
time_zoneGet the time-zone current time in ISO-6801 format: HHmmss.SSSZ
端点: GET /v1/locale/timezones/{zoneid}
参数:
zoneid (string) 必需: The time-zone id
admin_divisions_near_locationGet administrative divisions near the given location, filtering by optional criteria.
端点: GET /v1/geo/locations/{locationid}/nearbyDivisions
参数:
radius (string) 必需: The location radius within which to find divisions
distanceUnit (string): The unit of distance to use: MI | KM
countryIds (string): Only divisions in these countries (comma-delimited country codes or WikiData ids)
excludedCountryIds (string): Only divisions NOT in these countries (comma-delimited country codes or WikiData ids)
timeZoneIds (string): Only divisions in these time-zones
minPopulation (number): Only divisions having at least this population
maxPopulation (number): Only divisions having no more than this population
namePrefix (string): Only divisions whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language.
namePrefixDefaultLangResults (string): Example value:
languageCode (string): Display results in this language
asciiMode (string): Example value:
hateoasMode (string): Example value:
includeDeleted (string): Whether to include any divisions marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE
limit (number): The maximum number of results to retrieve
offset (number): The zero-ary offset into the results
sort (string): How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = countryCode | elevation | name | population
locationid (string) 必需: Only divisions near this location. Latitude/longitude in ISO-6709 format: ±DD.DDDD±DDD.DDDD
admin_divisions_near_divisionGet divisions near the given administrative division, filtering by optional criteria.
端点: GET /v1/geo/adminDivisions/{divisionId}/nearbyDivisions
参数:
radius (number) 必需: The location radius within which to find divisions
distanceUnit (string): The unit of distance to use: MI | KM
countryIds (string): Only divisions in these countries (comma-delimited country codes or WikiData ids)
excludedCountryIds (string): Only divisions NOT in these countries (comma-delimited country codes or WikiData ids)
timeZoneIds (string): Only divisions in these time-zones
minPopulation (number): Only divisions having at least this population
maxPopulation (number): Only divisions having no more than this population
namePrefix (string): Only divisions whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language.
namePrefixDefaultLangResults (string): Example value:
languageCode (string): Display results in this language
asciiMode (string): Example value:
hateoasMode (string): Example value:
includeDeleted (string): Whether to include any divisions marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE
limit (number): The maximum number of results to retrieve
offset (number): The zero-ary offset into the results
sort (string): How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = countryCode | elevation | name | population
divisionId (string) 必需: Example value: Q104994
传输协议: stdio
HTTP 客户端: httpx
MIT License - 详见 LICENSE 文件。
此服务器由 API-to-MCP 工具生成。
版本: 1.0.0
Get the details for a specific administrative division, including location coordinates, population, and elevation above sea-level (if available).
| Name | Required | Description | Default |
|---|---|---|---|
| languageCode | No | Display results in this language | |
| asciiMode | No | Example value: | |
| divisionId | Yes | Example value: Q104994 |
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.
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.
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.
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.
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.
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.
Find administrative divisions, filtering by optional criteria. If no criteria are set, you will get back all known divisions with a population of at least 1000
| Name | Required | Description | Default |
|---|---|---|---|
| location | No | Only divisions near this location. Latitude/longitude in ISO-6709 format: ±DD.DDDD±DDD.DDDD | |
| radius | No | The location radius within which to find divisions | 0 |
| distanceUnit | No | The unit of distance to use: MI | KM | |
| countryIds | No | Only divisions in these countries (comma-delimited country codes or WikiData ids) | |
| excludedCountryIds | No | Only divisions NOT in these countries (comma-delimited country codes or WikiData ids) | |
| timeZoneIds | No | Only divisions in these time-zones | |
| minPopulation | No | Only divisions having at least this population | 0 |
| maxPopulation | No | Only divisions having no more than this population | 0 |
| namePrefix | No | Only divisions whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language. | |
| namePrefixDefaultLangResults | No | Example value: | |
| languageCode | No | Display results in this language | |
| asciiMode | No | Example value: | |
| hateoasMode | No | Example value: | |
| includeDeleted | No | Whether to include any divisions marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE | |
| limit | No | The maximum number of results to retrieve | 0 |
| offset | No | The zero-ary offset into the results | 0 |
| sort | No | How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = countryCode | elevation | name | population |
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.
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.
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.
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.
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.
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.
Get divisions near the given administrative division, filtering by optional criteria.
| Name | Required | Description | Default |
|---|---|---|---|
| radius | Yes | The location radius within which to find divisions | 100 |
| distanceUnit | No | The unit of distance to use: MI | KM | |
| countryIds | No | Only divisions in these countries (comma-delimited country codes or WikiData ids) | |
| excludedCountryIds | No | Only divisions NOT in these countries (comma-delimited country codes or WikiData ids) | |
| timeZoneIds | No | Only divisions in these time-zones | |
| minPopulation | No | Only divisions having at least this population | 0 |
| maxPopulation | No | Only divisions having no more than this population | 0 |
| namePrefix | No | Only divisions whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language. | |
| namePrefixDefaultLangResults | No | Example value: | |
| languageCode | No | Display results in this language | |
| asciiMode | No | Example value: | |
| hateoasMode | No | Example value: | |
| includeDeleted | No | Whether to include any divisions marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE | |
| limit | No | The maximum number of results to retrieve | 0 |
| offset | No | The zero-ary offset into the results | 0 |
| sort | No | How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = countryCode | elevation | name | population | |
| divisionId | Yes | Example value: Q104994 |
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.
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.
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.
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.
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.
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.
Get administrative divisions near the given location, filtering by optional criteria.
| Name | Required | Description | Default |
|---|---|---|---|
| radius | Yes | The location radius within which to find divisions | |
| distanceUnit | No | The unit of distance to use: MI | KM | |
| countryIds | No | Only divisions in these countries (comma-delimited country codes or WikiData ids) | |
| excludedCountryIds | No | Only divisions NOT in these countries (comma-delimited country codes or WikiData ids) | |
| timeZoneIds | No | Only divisions in these time-zones | |
| minPopulation | No | Only divisions having at least this population | 0 |
| maxPopulation | No | Only divisions having no more than this population | 0 |
| namePrefix | No | Only divisions whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language. | |
| namePrefixDefaultLangResults | No | Example value: | |
| languageCode | No | Display results in this language | |
| asciiMode | No | Example value: | |
| hateoasMode | No | Example value: | |
| includeDeleted | No | Whether to include any divisions marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE | |
| limit | No | The maximum number of results to retrieve | 0 |
| offset | No | The zero-ary offset into the results | 0 |
| sort | No | How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = countryCode | elevation | name | population | |
| locationid | Yes | Only divisions near this location. Latitude/longitude in ISO-6709 format: ±DD.DDDD±DDD.DDDD |
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.
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.
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.
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.
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.
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.
Get cities near the given administrative division, filtering by optional criteria.
| Name | Required | Description | Default |
|---|---|---|---|
| types | No | Only cities for these types (comma-delimited): CITY | ADM2 | |
| radius | Yes | The location radius within which to find cities | 100 |
| distanceUnit | No | The unit of distance to use: MI | KM | |
| countryIds | No | Only cities in these countries (comma-delimited country codes or WikiData ids) | |
| excludedCountryIds | No | Only cities NOT in these countries (comma-delimited country codes or WikiData ids) | |
| timeZoneIds | No | Only cities in these time-zones | |
| minPopulation | No | Only cities having at least this population | 0 |
| maxPopulation | No | Only cities having no more than this population | 0 |
| namePrefix | No | Only cities whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language. | |
| namePrefixDefaultLangResults | No | Example value: | |
| languageCode | No | Display results in this language | |
| asciiMode | No | Example value: | |
| hateoasMode | No | Example value: | |
| includeDeleted | No | Whether to include any cities marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE | |
| limit | No | The maximum number of results to retrieve | 0 |
| offset | No | The zero-ary offset into the results | 0 |
| sort | No | How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = countryCode | elevation | name | population | |
| divisionId | Yes | Example value: Q104994 |
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.
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.
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.
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.
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.
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.
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). Currently, this data is highly dependent on whether the Wikidata locatedIn relation is properly defined. If you see an issue, please propose a change to the corresponding Wikidata entry.
| Name | Required | Description | Default |
|---|---|---|---|
| cityId | Yes | Example value: Q65 |
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.
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.
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.
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.
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.
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.
Get the places in the given country.
| Name | Required | Description | Default |
|---|---|---|---|
| types | No | Only cities for these types (comma-delimited): ADM2 | CITY | ISLAND | |
| timeZoneIds | No | Only places in these time-zones | |
| minPopulation | No | Only places having at least this population | |
| maxPopulation | No | Only places having no more than this population | 0 |
| namePrefix | No | Only places whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language. | |
| namePrefixDefaultLangResults | No | Example value: | |
| languageCode | No | Display results in this language | |
| asciiMode | No | Example value: | |
| hateoasMode | No | Example value: | |
| includeDeleted | No | Whether to include any cities marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE | |
| limit | No | The maximum number of results to retrieve | |
| offset | No | The zero-ary offset into the results | |
| sort | No | How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = elevation | name | population | |
| countryId | Yes | Example value: US |
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.
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.
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.
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.
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.
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.
Get the administrative divisions in the given region.
| Name | Required | Description | Default |
|---|---|---|---|
| minPopulation | No | Only cities having at least this population | |
| maxPopulation | No | Only divisions having no more than this population | 0 |
| namePrefix | No | Only divisions whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language. | |
| namePrefixDefaultLangResults | No | Example value: | |
| languageCode | No | Display results in this language | |
| asciiMode | No | Example value: | |
| hateoasMode | No | Example value: | |
| includeDeleted | No | Whether to include any cities marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE | |
| limit | No | The maximum number of results to retrieve | |
| offset | No | The zero-ary offset into the results | |
| sort | No | How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = elevation | name | population | |
| countryid | Yes | An ISO-3166 country code or WikiData id | |
| regioncode | Yes | An ISO-3166 or FIPS region code |
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.
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.
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.
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.
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.
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.
Get the places in the given region.
| Name | Required | Description | Default |
|---|---|---|---|
| types | No | Only cities for these types (comma-delimited): ADM2 | CITY | ISLAND | |
| timeZoneIds | No | Only places in these time-zones | |
| minPopulation | No | Only places having at least this population | |
| maxPopulation | No | Only places having no more than this population | 0 |
| namePrefix | No | Only places whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language. | |
| namePrefixDefaultLangResults | No | Example value: | |
| languageCode | No | Display results in this language | |
| asciiMode | No | Example value: | |
| hateoasMode | No | Example value: | |
| includeDeleted | No | Whether to include any cities marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE | |
| limit | No | The maximum number of results to retrieve | |
| offset | No | The zero-ary offset into the results | |
| sort | No | How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = elevation | name | population | |
| countryid | Yes | An ISO-3166 country code or WikiData id | |
| regionId | Yes | Example value: CA |
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.
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.
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.
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.
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.
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.
Get this place's current date-time in ISO-6801 format: yyyyMMdd'T'HHmmssZ
| Name | Required | Description | Default |
|---|---|---|---|
| placeId | Yes | Example value: |
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.
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.
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.
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.
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.
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.
Get the details for a specific place, including location coordinates, population, and elevation above sea-level (if available).
| Name | Required | Description | Default |
|---|---|---|---|
| languageCode | No | Display results in this language | |
| asciiMode | No | Example value: | |
| placeId | Yes | Example value: |
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.
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.
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.
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.
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.
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.
Gets this place's distance to the given place.
| Name | Required | Description | Default |
|---|---|---|---|
| distanceUnit | No | The unit of distance: KM | MI [default] | |
| toPlaceId | No | The distance to this place | |
| placeId | Yes | Example value: |
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.
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.
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.
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.
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.
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.
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). Currently, this data is highly dependent on whether the Wikidata locatedIn relation is properly defined. If you see an issue, please propose a change to the corresponding Wikidata entry.
| Name | Required | Description | Default |
|---|---|---|---|
| placeId | Yes | Example value: |
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.
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.
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.
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.
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.
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.
Find places, filtering by optional criteria. If no criteria are set, you will get back all known places.
| Name | Required | Description | Default |
|---|---|---|---|
| types | No | Only places for these types (comma-delimited): ADM2 | CITY | ISLAND | |
| location | No | Only places near this location. Latitude/longitude in ISO-6709 format: ±DD.DDDD±DDD.DDDD | |
| radius | No | The location radius within which to find places | 0 |
| distanceUnit | No | The unit of distance to use: MI | KM | |
| countryIds | No | Only places in these countries (comma-delimited country codes or WikiData ids) | |
| excludedCountryIds | No | Only places NOT in these countries (comma-delimited country codes or WikiData ids) | |
| timeZoneIds | No | Only places in these time-zones | |
| minPopulation | No | Only places having at least this population | 0 |
| maxPopulation | No | Only places having no more than this population | 0 |
| namePrefix | No | Only places whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language. | |
| namePrefixDefaultLangResults | No | Example value: | |
| includeDeleted | No | Whether to include any places marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE | |
| languageCode | No | Display results in this language | |
| asciiMode | No | Example value: | |
| hateoasMode | No | Example value: | |
| limit | No | The maximum number of results to retrieve | 0 |
| offset | No | The zero-ary offset into the results | 0 |
| sort | No | How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = countryCode | elevation | name | population |
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.
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.
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.
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.
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.
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.
Get places near the given location, filtering by optional criteria.
| Name | Required | Description | Default |
|---|---|---|---|
| types | No | Only places for these types (comma-delimited): ADM2 | CITY | ISLAND | |
| radius | Yes | The location radius within which to find places | |
| distanceUnit | No | The unit of distance to use: MI | KM | |
| countryIds | No | Only places in these countries (comma-delimited country codes or WikiData ids) | |
| excludedCountryIds | No | Only places NOT in these countries (comma-delimited country codes or WikiData ids) | |
| timeZoneIds | No | Only places in these time-zones | |
| minPopulation | No | Only places having at least this population | 0 |
| maxPopulation | No | Only places having no more than this population | 0 |
| namePrefix | No | Only places whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language. | |
| namePrefixDefaultLangResults | No | Example value: | |
| languageCode | No | Display results in this language | |
| asciiMode | No | Example value: | |
| hateoasMode | No | Example value: | |
| includeDeleted | No | Whether to include any places marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE | |
| limit | No | The maximum number of results to retrieve | 0 |
| offset | No | The zero-ary offset into the results | 0 |
| sort | No | How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = countryCode | elevation | name | population | |
| locationid | Yes | Only cities near this location. Latitude/longitude in ISO-6709 format: ±DD.DDDD±DDD.DDDD |
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.
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.
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.
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.
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.
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.
Get places near the given place, filtering by optional criteria.
| Name | Required | Description | Default |
|---|---|---|---|
| types | No | Only places for these types (comma-delimited): ADM2 | CITY | ISLAND | |
| radius | Yes | The location radius within which to find places | 0 |
| distanceUnit | No | The unit of distance to use: MI | KM | |
| countryIds | No | Only places in these countries (comma-delimited country codes or WikiData ids) | |
| excludedCountryIds | No | Only places NOT in these countries (comma-delimited country codes or WikiData ids) | |
| timeZoneIds | No | Only places in these time-zones | |
| minPopulation | No | Only places having at least this population | 0 |
| maxPopulation | No | Only places having no more than this population | 0 |
| namePrefix | No | Only places whose names start with this prefix. If languageCode is set, the prefix will be matched on the name as it appears in that language. | |
| namePrefixDefaultLangResults | No | Example value: | |
| languageCode | No | Display results in this language | |
| asciiMode | No | Example value: | |
| hateoasMode | No | Example value: | |
| includeDeleted | No | Whether to include any places marked deleted: ALL | SINCE_YESTERDAY | SINCE_LAST_WEEK | NONE | |
| offset | No | The zero-ary offset into the results | 0 |
| sort | No | How to sort the results. Format: ±SORT_FIELD,±SORT_FIELD where SORT_FIELD = countryCode | elevation | name | population | |
| placeId | Yes | Example value: |
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.
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.
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.
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.
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.
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.
Get this place's current time in ISO-8601 format: HHmmss.SSSZ
| Name | Required | Description | Default |
|---|---|---|---|
| placeId | Yes | Example value: |
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.
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.
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.
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.
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.
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.
Get the time-zone current time in ISO-6801 format: HHmmss.SSSZ
| Name | Required | Description | Default |
|---|---|---|---|
| zoneid | Yes | The time-zone id |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search and explore a global travel points-of-interest catalog (cities, countries, POIs).
Free GeoNames MCP: countries, cities, POIs, distance & nearby. Remote HTTP + agent token signup.
City geocoding and timezone resolution for birth data, for AI agents, one API key.
Geocoding, weather forecasts, and timezone lookups
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