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., "@public-apis-mcp-server What's the weather in Tokyo?"
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.
一个零配置的 MCP 服务，包装 11 个免费公共 API，无需 API key，开箱即用。
A zero-config MCP server wrapping 11 free public APIs. No API keys required, works out of the box.
{
"mcpServers": {
"public-apis": {
"command": "uvx",
"args": ["public-apis-mcp-server@latest"]
}
}
}无。无需任何配置即可使用。 None. Truly zero configuration.
Related MCP server: astronomy-mcp-server
get_weather基于 Open-Meteo，查询实时天气及 7 天预报。 Real-time weather and 7-day forecast via Open-Meteo (free, no key).
{
"arguments": { "city": "Beijing" }
}get_country_info查询国家详情：人口、货币、语言、国旗等。 Country details: population, currency, languages, flag via REST Countries.
{
"arguments": { "name": "Japan" }
}get_asteroid_info查询 NASA NEO 小行星数据（按日期）。 Near-Earth asteroid data from NASA NEO by date.
{
"arguments": { "date": "2026-06-13" }
}get_astronomy_pictureNASA APOD — 每日天文图片及说明。 NASA Astronomy Picture of the Day with explanation.
get_ip_geolocation通过 ip-api.com 查询 IP 地址的地理位置（城市、国家、经纬度等）。 IP geolocation via ip-api.com (city, country, coordinates, ISP).
{
"arguments": { "ip": "8.8.8.8" }
}lookup_wordFree Dictionary API — 单词定义、音标、词性、例句。 English word definitions, phonetics, parts of speech, examples.
{
"arguments": { "word": "serendipity" }
}get_random_activityBored API — 推荐随机活动，可按类型筛选。 Random activity recommendation, filterable by type.
{
"arguments": { "type": "recreational" }
}search_arxivarXiv API — 搜索物理、数学、计算机科学等论文。 Search arXiv papers across physics, math, CS, and more.
{
"arguments": { "query": "transformer attention", "max_results": 5 }
}search_booksOpen Library — 按书名、作者、ISBN 搜索图书。 Search books by title, author, or ISBN via Open Library.
{
"arguments": { "query": "dune", "limit": 5 }
}get_sun_timesSunrise-Sunset API — 查询日出日落、天文晨昏时间。 Sunrise, sunset, dawn, dusk times for any location.
{
"arguments": {
"lat": 39.9042,
"lng": 116.4074
}
}get_posts / get_usersJSONPlaceholder — 获取模拟帖子/用户数据，适合开发和测试。 Fetch mock posts and user data for development/testing.
工具 | 来源 | 限制 |
| Open-Meteo | 完全免费，每分钟 10,000 请求 |
| REST Countries | 完全免费 |
| NASA NEO | 内置 |
| NASA APOD | 同上 |
| ip-api.com | 完全免费，每分钟 45 请求 |
| Free Dictionary | 完全免费 |
| Bored API | 完全免费 |
| arXiv API | 完全免费，合理使用 |
| Open Library | 完全免费，合理使用 |
| Sunrise-Sunset | 完全免费 |
| JSONPlaceholder | 完全免费 |
所有工具均使用 HTTP API，无需任何 API key 或注册。 All tools use public HTTP APIs — no registration or API key needed.
git clone https://github.com/online111111/public-apis-mcp-server.git
cd public-apis-mcp-server
uv sync
uv run python -m public_apis_mcp_server.serverMIT
获取指定日期的近地小行星信息（NEO）。 数据来源: NASA，使用公开 DEMO_KEY（每小时 30 次限制）。
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | 日期，格式 YYYY-MM-DD，默认今天 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses data source (NASA) and rate limit (DEMO_KEY, 30 per hour), which are important behavioral traits beyond just describing the function. No annotations provided, so description carries the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with core purpose. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers purpose, source, and rate limit. Missing return value details but output schema compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter. Description repeats the format and default already in schema, adding no new semantic meaning.
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?
Description clearly states verb (获取), resource (近地小行星信息/NEO information), and scope (指定日期). Distinguishes from siblings as no other tool relates to asteroids.
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 versus alternatives. Does not mention prerequisites or exclusion scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 NASA 每日天文图片（APOD）的信息。 数据来源: NASA，使用公开 DEMO_KEY（每小时 30 次限制）。
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | 日期，格式 YYYY-MM-DD，默认今天 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the rate limit using a public DEMO_KEY, but does not indicate whether the operation is read-only, what the return value includes, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loading the core purpose and adding a key constraint. No wasted words; every sentence is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return value details are not required. However, the description could clarify it returns image metadata (e.g., title, URL) rather than just vague 'information'. Current description is adequate but leaves ambiguity.
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 has 1 parameter with 100% description coverage (date with format YYYY-MM-DD, default today). The description adds no additional parameter meaning, so 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 retrieves NASA's Astronomy Picture of the Day (APOD) information, with a specific verb '获取' (get) and resource 'NASA每日天文图片'. Sibling tools are unrelated, so no confusion.
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 explicit guidance on when to use this tool vs alternatives. The description mentions a rate limit (30 req/h) but does not state prerequisites, when to prefer it, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取指定国家的详细信息（人口、面积、货币、语言、国旗等）。 数据来源: REST Countries，完全免费。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 国家名称（中文或英文，如 "China"、"日本"、"Germany"、"CHN"） |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only mentions the data source and free status, but fails to disclose other behavioral traits like read-only nature, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with the action and key details (data source, free).
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 presence of an output schema, the description adequately covers the purpose and data source. Could mention parameter language flexibility (Chinese/English) but that's in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but description adds value by listing the types of information retrieved (population, area, etc.), complementing the parameter's name-only description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves detailed country information (population, area, currency, language, flag, etc.) and distinguishes from sibling tools that focus on asteroids, astronomy, IP, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for country info but provides no explicit when-to-use or when-not-to-use guidance relative to siblings. No alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询 IP 地址的地理位置信息（国家、城市、ISP 等）。 数据来源: ip-api.com，完全免费，无需 API key。
| Name | Required | Description | Default |
|---|---|---|---|
| ip | No | IP 地址，不传则查询本机公网 IP |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions the tool is free and uses ip-api.com, but does not disclose rate limits, error handling, safety (read-only), or any potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter) and the existence of an output schema, the description is mostly complete. It could mention potential limitations or output structure, but it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema describes the 'ip' parameter well (including default behavior). The description adds no additional semantic information beyond the data source and cost, so it meets the baseline but does not exceed it.
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: querying geolocation (country, city, ISP) for an IP address. It uses a specific verb ('查询') and resource, and it distinguishes itself from sibling tools, none of which offer IP geolocation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when IP geolocation is needed, and mentions the data source and that no API key is required. However, it does not explicitly state when not to use it or provide alternatives, though no direct sibling exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 JSONPlaceholder 测试平台的帖子列表（模拟数据）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 返回帖子数量，默认 5 | |
| user_id | No | 可选，按用户 ID 筛选 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It mentions that the data is simulated, which is a key behavioral trait. However, it does not disclose whether the operation is read-only or other potential side effects, though it is implicitly a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the essential information. It is front-loaded with the action and resource, with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and the presence of an output schema, the description is mostly complete. It identifies the source and the simulated nature of the data. It does not elaborate on return fields, but that is covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond the schema's parameter descriptions (limit and user_id). The description only covers the tool's overall purpose, not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of posts from the JSONPlaceholder test platform, specifying it is simulated data. This provides a clear verb-resource combination and distinguishes it from unrelated sibling 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 does not provide any guidance on when to use this tool versus alternatives or mention any exclusions or prerequisites. It only states the tool's function, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取随机活动推荐，适合打发时间或寻找灵感。 数据来源: Bored API (boredapi.com)，完全免费。
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | 活动类型，可选: education/recreational/social/diy/cooking/music/busywork/relaxation/charity | |
| participants | No | 参与人数（0 表示不限） | |
| min_price | No | 最低花费 (0.0 - 1.0) | |
| max_price | No | 最高花费 (0.0 - 1.0) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits like read-only nature, side effects, or rate limits. It only mentions the data source is free but does not confirm the operation is non-destructive or provide any behavioral context. This is insufficient.
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: two sentences, each adding distinct value. The first states purpose, the second provides data source and cost. No fluff or repetition.
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 full input schema, presence of output schema, and the tool's simplicity, the description is mostly complete. It could mention that results can be filtered by parameters or that the result is a single random activity, but the schema and output schema likely cover that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described adequately in the schema. The description adds no extra meaning beyond what the schema provides, so baseline score of 3 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides random activity recommendations for passing time or finding inspiration. The verb '获取' (get) and resource '活动推荐' (activity recommendations) are specific. However, it does not differentiate from siblings, but siblings are clearly distinct domains.
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 explicit when-to-use or when-not-to-use guidance is provided. The usage is implied by the tool's purpose (random activities), but alternatives are not mentioned. A score of 3 is appropriate as the context is clear from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取指定地点和日期的日出、日落、晨光、暮光等天文时间。 数据来源: Sunrise-Sunset API，完全免费。
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | 纬度 | |
| longitude | Yes | 经度 | |
| date | No | 日期，格式 YYYY-MM-DD，默认今天 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral info. It notes the data source and free nature but lacks details on error handling, limitations, or reliability. With an output schema present (context indicates exists), the description does not need to explain return values, but more context on behavior would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose. No redundant or unnecessary information. Efficient 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?
For a simple tool with three parameters and an output schema, the description is largely complete. It covers the core functionality and data source. Could mention input validation but not critical given schema. Output schema handles returns.
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 describes all parameters. The description adds no additional meaning beyond matching parameters to 'location and date.' Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves astronomical times (sunrise, sunset, etc.) for a given location and date. It uses a specific verb ('get') and resource ('astronomical times'), differentiating it from sibling tools like get_weather or get_country_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the data source and that it is free, but does not explicitly state when to use this tool versus alternatives or provide any exclusions. Usage context is implied but not clearly delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 JSONPlaceholder 测试平台的用户列表（模拟数据）。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the data is simulated (模拟数据), adding behavioral context beyond a simple list retrieval. However, with no annotations, it does not disclose potential limits, pagination, or return format, which is acceptable for a simple tool but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the purpose and key context (test platform, simulated data). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema, the description adequately states its function and data nature. It could optionally mention relation to other JSONPlaceholder tools, but not essential for 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?
There are no parameters, so the description does not need to add meaning beyond the schema. Baseline score of 4 is appropriate as schema coverage is 100% and no parameter documentation is required.
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 explicitly states the action ('获取' = get) and the resource ('用户列表' = user list) from a specific platform ('JSONPlaceholder 测试平台'), clearly distinguishing it from generic user list tools. It adds context of simulated data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_posts or search_books. No exclusion criteria or context-dependent recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取指定城市或经纬度坐标的天气信息（当前 + 预报）。 数据来源: Open-Meteo，完全免费。
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | 城市名称（如 "Beijing"、"Tokyo"、"London"，中英文均可） | |
| latitude | No | 纬度（不提供 city 时使用） | |
| longitude | No | 经度（不提供 city 时使用） | |
| timezone | No | 时区，默认 "auto" | auto |
| forecast_days | No | 预报天数，1-16，默认 3 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions data source (Open-Meteo) and that it's free, but lacks details on read-only nature, rate limits, or other behavioral traits. It is minimally adequate.
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 concise with two sentences, no redundant information. However, it is in Chinese, which might affect readability for English-centric agents.
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 presence of an output schema and 100% parameter coverage, the description is largely sufficient. However, it omits parameter interaction details (city vs coordinates) and any error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond schema; it does not clarify the relationship between city and coordinates or parameter constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets weather info for a city or coordinates, covering both current and forecast. It distinguishes from siblings like get_asteroid_info or get_country_info, which are obviously different domains.
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 explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites or when not to use it, relying solely on the tool name and context of siblings to imply purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询英文单词的定义、音标、词性、例句等。 数据来源: Free Dictionary API (dictionaryapi.dev)，完全免费。
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes | 要查询的英文单词 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the data source (Free Dictionary API) and that it's free, but does not mention any behavioral traits such as rate limits, error handling (e.g., word not found), response size, or potential side effects (none expected). This leaves the agent with incomplete understanding of the tool's 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 two sentences in Chinese, concise and to the point. It includes a data source note which is helpful but not essential. Overall, it is efficiently structured with no redundant information, though the second sentence could be integrated.
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 simplicity (single parameter, output schema exists), the description covers the key types of information returned (definitions, phonetic symbols, etc.) and mentions the data source. It does not explain output structure, but the output schema likely handles that. The description is complete enough for basic 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?
There is only one parameter, 'word', with a schema description '要查询的英文单词' (the English word to query). The tool description does not add meaning beyond the schema; it merely lists the types of data returned. Since schema coverage is 100%, the baseline 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 it queries English words for definitions, phonetic symbols, parts of speech, example sentences, etc. The verb '查询' (look up) and resource '英文单词' (English word) are specific. It distinguishes itself from sibling tools like get_country_info or get_random_activity by focusing on language lookup.
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 does not provide explicit when-to-use or when-not-to-use guidance. However, the tool's purpose is straightforward (English word lookup), so usage is implied. No alternatives are mentioned, but sibling tools cover different domains, so confusion is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索 arXiv 学术论文（物理学、数学、计算机科学、经济学等）。 数据来源: arXiv API，完全免费。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词 | |
| max_results | No | 返回结果数，默认 5，最大 20 | |
| sort_by | No | 排序方式，可选 relevance / lastUpdatedDate / submittedDate | relevance |
| category | No | 分类筛选，如 cs.AI (人工智能)、math (数学)、physics (物理) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It mentions the API source and cost, but omits critical details such as rate limits, query syntax specifics (e.g., boolean operators), or how failures are handled. The description is minimal and does not adequately inform about potential constraints.
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 very concise, consisting of only two sentences. It front-loads the core purpose. While extremely brief, it is not overly verbose and contains only relevant information. The slight trailing whitespace is minor.
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 that an output schema exists (even though not shown in detail here), the description does not need to explain return values. However, for a tool with 4 parameters and moderate complexity, the description fails to mention important context like pagination, result format, or error conditions. It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, meaning the schema already explains all parameters. The tool description adds no additional semantic information beyond the schema. Therefore, 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 action (search) and resource (arXiv academic papers), specifying the disciplines covered (physics, math, computer science, economics). It effectively distinguishes the tool from sibling tools, which are mostly info retrieval tools unrelated to scholarly search.
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 lacks any guidance on when to use this tool versus alternatives like search_books. It mentions the data source and that it is free, but provides no decision rules or exclusions. Users are left to infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索图书信息（标题、作者、出版年份、封面等）。 数据来源: Open Library，完全免费。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词（书名、作者等） | |
| limit | No | 返回结果数，默认 5，最大 20 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It only states the tool searches data from Open Library and is free, but does not explicitly state it is read-only, has no side effects, or any rate limits. The behavioral profile is incomplete.
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?
Description is very concise: two sentences, first covering purpose and fields, second covering data source and cost. Information is front-loaded and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, required query, default limit), the description covers source and search fields. An output schema exists, so return details need not be in description. However, it lacks mention of the max limit (20) which is in schema, and does not describe pagination or other potential constraints, making it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds the list of searchable fields (title, author, etc.) which are not in the schema but relate to query. However, this does not significantly enhance parameter understanding beyond what the schema already provides.
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?
Description clearly states the tool searches for book information (title, author, publication year, cover, etc.) and specifies the data source (Open Library) and cost (free). The verb 'search' and resource 'books' are specific and distinct from sibling tools like search_arxiv.
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?
Description provides no guidance on when to use this tool versus alternatives. It does not mention when not to use it or any prerequisites, leaving the agent to 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.
Each tool targets a distinct public API domain (e.g., asteroids, weather, books) with no overlap. An agent can clearly distinguish which tool to use for a specific type of query.
Tools use a consistent verb_noun pattern in snake_case, with 'get_' for data retrieval and 'search_' for search operations. The minor variation in verbs is systematic and predictable.
With 12 tools covering a diverse set of public APIs, the count is well-balanced—not too few to be useful and not too many to be overwhelming.
The tool set provides broad coverage of common public API categories (space, geography, weather, language, etc.), though additional APIs like music or movies could be included. No critical gaps given the server's aggregator purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
20+ pay-per-use APIs: image gen, crypto data, email verify, SSL check, web scraping, and more.
Try 26 utility REST APIs keylessly: NAICS classification, IP geo, email validation, currency.
Turn any task into the right API calls: discover, evaluate, and integrate public APIs.
One MCP endpoint over 69 public PPN APIs: search_apis to discover, execute_api to call. Free tier.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/online111111/public-apis-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
