io.github.FreyaBit/shanghai-library-open-data-mcp

Server Quality Checklist

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

Latest release: v1.3.0
Disambiguation3/5
Most tools have distinct purposes (e.g., souyun_rhyme vs souyun_couplet), but slc_api and slc_raw both provide generic access to library data, and slc_sparql is documentation rather than a query tool. This creates some boundary confusion.
Naming Consistency4/5
All names use lowercase with underscores and follow a prefix_noun pattern (souyun_* and slc_*). The convention is consistent, though not verb-noun based, and the mix of prefixes is acceptable.
Tool Count4/5
12 tools is within the typical well-scoped range, but includes a few near-redundant access methods (slc_api, slc_raw, slc_endpoints) and a documentation-only tool (slc_sparql). Slightly heavy but reasonable for the combined library/poetry scope.
Completeness4/5
The library domain is nearly complete thanks to the generic slc_api dispatcher covering 97 endpoints, plus dedicated tools for key resources. The poetry tools cover rhyme, couplet, and poem search. Minor gaps exist (e.g., no direct SPARQL execution), but agents can work around them.
Average 3.3/5 across 12 of 12 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description was expected to disclose behavioral traits. It only states that the tool is 'verified available' and describes a search, but does not mention authentication requirements (despite the API key parameter in the schema), data scope, or return behavior. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, consisting of a single phrase with an annotation-like note. While it is concise, it is under-specified and does not front-load critical information such as the tool's general purpose or usage context. It reads more like a placeholder than a well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no annotations, and no output schema, the description is incomplete. It fails to mention the need for an API key, the nature of the response, or any constraints. The schema documents parameters but the description does not provide the contextual glue needed for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters completely (key for API key, keyword for road/building name), achieving 100% coverage. The description adds no extra semantic value, so 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says '武康路历史建筑检索' (Wukang Road historical building search), which indicates a search over historical buildings but incorrectly narrows the scope to Wukang Road, whereas the schema's keyword parameter implies a broader road/building keyword search. It distinguishes from sibling tools by focusing on buildings, but the specificity is misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to use this tool versus siblings like slc_era or slc_jiapu, nor any exclusions or prerequisites. The 'verified available' note is a status indicator, not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It does not mention whether the operation is read-only, requires special permissions, returns data in a particular format, or has any rate limits or side effects. The scant phrase 'retrieval' implies a read operation, but without specifics it 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, consisting of a single noun phrase. While this is concise and front-loaded, it is under-specified to the point of not providing adequate information. It does not waste words, but the lack of structure and detail makes it less effective than a well-structured two-sentence description would be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no output schema, and no annotations, this description is far from complete. It does not explain what the tool returns, how the parameters interact, or any context around 'red tourism/historical events'. The concise phrase leaves the agent guessing about invocation details, making it inadequate for effective tool selection and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 67% of parameters (key and date have descriptions), but the description itself adds nothing about the parameters. The 'keyword' parameter is undocumented in the schema and the description gives no hint about its meaning or usage. The description fails to compensate for the coverage gap, offering no added semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '红色旅游/历史事件检索' (red tourism/historical event retrieval) clearly states the tool's function: retrieving red tourism or historical events. It includes a specific resource and an action (检索/search). While it does not explicitly distinguish from sibling tools like slc_era or slc_building, the focus on red tourism/historical events is a distinct subject area, so it is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any context about prerequisites like the API key. The description only names the function and provides no usage scenarios, exclusions, or alternatives, leaving the agent to infer when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only mentions the platform key availability for web use. It fails to indicate whether the tool performs read-only queries, any side effects, return formats, or error behavior, leaving 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than appropriately concise. The single sentence does not earn its place because it fails to communicate the tool's function, making it more a fragment than a useful explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a bare-bones description. For a complex operation like SPARQL graph querying, this is severely incomplete. It lacks critical information about return values, usage conditions, and alternates, making it inadequate for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline for this dimension is 4. There are no parameter definitions to clarify, and the description does not need to compensate for missing parameter info. It adds no parameter semantics, but none are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'SPARQL 图查询说明（该平台 Key 仅网页端可用）' is vague; it reads as an explanatory note rather than a clear action like 'execute SPARQL query'. It does not differentiate from sibling tools such as slc_api or slc_endpoints, leaving the tool's exact function ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The only context is a platform key limitation, which addresses authentication but not usage scenarios, prerequisites, or complementary tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the subject matter without describing output format, read-only nature, or any side effects. The term 'overview' implies a safe, read-only operation, but no specifics are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase that immediately conveys the tool's purpose. It is front-loaded with '总览' and contains no unnecessary words or redundancy. This is an optimally compact structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should explain what the tool returns. It only identifies the subject (datasets and third-party organizations) but does not specify the output structure, format, or level of detail. This leaves the agent uncertain about the result of invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so there is nothing to explain. The baseline for zero-parameter tools is 4, and the description adds no parameter information because none is required. The schema coverage is trivially 100%, so no gaps exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '数据集与第三方机构总览' clearly indicates an overview of datasets and third-party organizations. It implies a listing or summary function, distinguishing it from specific lookup tools like slc_endpoints or souyun_rhyme. A more explicit verb like 'list' would improve clarity, but the current phrasing is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions or sibling tool relationships. The intended usage is only implied by the term '总览' (overview), suggesting it serves as a starting point for exploring available data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits, but it only states the search action. It does not mention read-only nature, authentication requirements (the API key is only in the schema), output format, pagination, error handling, or any side effects. This is a significant gap for an agent assessing safety and expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It conveys the core purpose and the two search fields efficiently. Every word contributes value, making it appropriately concise for a simple search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must be more self-sufficient. It does not explain what the tool returns, the scope of the 'data1' dataset, how to use the API key, or how this tool relates to sibling search tools. An agent would have to infer or seek additional information to invoke it correctly, making the description incomplete for a tool of even moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning to the undocumented title and familyname parameters by explicitly stating they are search criteria. However, it does not explain matching behavior (exact, partial, pinyin), whether both can be combined, or required formats. The key parameter is described in the schema but nothing extra is provided in the description. Overall, the description partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a genealogy catalog search ('家谱谱目检索'), which is a specific resource and action. It distinguishes itself from sibling tools such as poetry, couplets, and other collection-specific searches by naming the exact domain. The verb '检索' (search) is precise and the scope is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used when searching for genealogy records, and it mentions the searchable fields (title/surname). However, it provides no explicit guidance on when to choose this over sibling tools like slc_datasets or slc_sparql, nor does it state any prerequisites or exclusions. The usage context is present but implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It does add behavioral context beyond the name: the GET method implies read-only, and the host scope (data1.library.sh.cn) is specified. However, it does not disclose response format, error behavior, whether the API key is always required, or rate limits — notable gaps for a raw/fallback tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single tight sentence that front-loads the core purpose (fallback GET call) and host scope with zero filler or redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param tool with a nested params object, no annotations, and no output schema, the one-sentence description is minimally adequate but leaves uncertainty about return values and error handling. The intentional fallback nature partially justifies brevity, but the description does not state what kind of raw response the agent should expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes key and path (67% coverage), and the description adds no parameter-level detail beyond the 'GET' hint, which loosely implies params become query string parameters. The 'params' object parameter remains undocumented, and the description does not compensate for that gap or clarify what it should contain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'GET 兜底调用' for '任意 data1.library.sh.cn 路径' (any path on data1.library.sh.cn). The term '兜底' (fallback) positions it as the catch-all tool, distinguishing it from specific sibling tools like slc_endpoints and slc_api. It is clear but slightly terse, not earning a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word '兜底' (fallback) implies this tool should be used when no more specific path-specific tool matches, giving implicit usage context. However, there is no explicit when-to-use guidance, nor are alternatives like slc_endpoints or slc_api named as preferred options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only adds the '免token' (no token needed) detail, but does not explain the return format, pagination behavior, error handling, or any limitations. The query dimensions are functional parameters, not behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that conveys the tool's purpose, query dimensions, and intended use case. It is front-loaded with the tool's name and avoids unnecessary verbiage; every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description is not fully complete. It does not explain return values, how parameters combine, or page number semantics. However, the schema covers most parameters, and the core purpose is clear, so it is a minimal viable description with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83%, so the schema already documents most parameters. The description adds mapping of keyword to author/title/verse and mentions rhyme/dynasty/genre, but does not elaborate on pageno or scope nuances. It adds some value beyond the schema but not enough to exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly names the tool as '搜韵诗词检索' (Souyun poem search) and lists queryable dimensions (author/title/verse/dynasty/genre/rhyme), clearly distinguishing it from sibling tools like souyun_rhyme and souyun_couplet. The verb '检索' (search) plus the resource '诗词' (poems) makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the use case '服务 AIGC 歌词' (serving AIGC lyrics), implying when to use it, but does not explicitly state when to prefer this tool over alternatives or when not to use it. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It adds the behavioral trait '免token' (token-free), and enumerates the query categories, but does not disclose return format, error behaviors, or rate limits, leaving gaps for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the tool name and core function, with zero filler words. It efficiently communicates the tool's scope despite using slashes to compress multiple features.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, so the description must explain return values and usage context. It does not mention the output shape or how the various qtype modes manifest in results, and it lacks alternate-tool guidance, leaving the agent under-informed for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both 'char' and 'qtype' described in detail, including the qtype enum values. The description adds limited semantic value beyond the schema—it names the functions but does not clarify parameter formats or edge cases, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '搜韵韵典：查字所属韵部、词末/词首典故、句末诗例' which clearly specifies a lookup action (查) on the rhyme dictionary resource, and lists three distinct, specific functions (rhyme category, word-boundary allusions, line-end examples), differentiating it from sibling poetry tools like souyun_poem and souyun_couplet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when rhyme-related information is needed ('查字所属韵部') but provides no explicit guidance on when to use this tool versus alternatives, no exclusions, and no mention of prerequisites. The 'qtype' parameter is documented in the schema, but the description does not direct the agent to specific qtype values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It mentions the required API key (authentication), path_args usage, and endpoint ID, but fails to indicate whether operations are read-only, how errors are handled, or what the response format looks like. Given that this tool can invoke 97 different APIs, these omitted traits are significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with semicolons, placing the purpose first, then parameter guidance, then a usage hint. Every sentence adds value, though the long list of domains could be trimmed without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (universal dispatcher for 97 APIs) and absence of output schema and annotations, the description covers purpose, parameter roles, authentication, and a discovery workflow. Missing details about return format and error behavior are notable, but the universal nature makes them less critical; overall it is fairly complete for a dispatcher.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 repeats parameter roles but introduces a contradiction: it states key is required (必填), while the input schema lists only endpoint as required. This conflicting information reduces the usefulness of the description and misleads the agent, so the score is lowered to 2.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies it as a universal dispatcher calling all webapi interfaces registered in api_2025, listing specific content domains and the count (97). This verb-resource pairing distinguishes it from sibling tools, and the instruction to use slc_endpoints for ID lookup reinforces its role as the generic access point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs users to first use slc_endpoints to find the interface ID, which serves as a prerequisite and names an alternative tool. It does not explicitly state when to avoid this tool in favor of specialized siblings, but the context makes it clear this is the generic dispatcher for all registered APIs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the responsibility. It discloses the need for an API key, but does not describe error handling, rate limits, or the exact output format beyond the example. This is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with an illustrative example. It is front-loaded with the tool name and functionality, with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple lookup tool, and the description explains the core conversion direction and provides an example. However, there is no output schema and no mention of edge cases, reverse conversion specifics, or error conditions, leaving some gaps for a fully complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with clear descriptions (100% coverage), so the baseline is 3. However, the description states 'key' is required ('必填') while the schema's required array includes only 'term', creating a direct contradiction that could mislead the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts Chinese historical dynasty/reign era names to AD year ranges and vice versa, using the example '明 -> 1368~1644'. This specific verb+resource pairing distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: input a dynasty/reign term or an AD year, and it returns the corresponding range or era. The example illustrates the expected input/output. However, it does not explicitly mention alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description discloses the output fields (id/家族/路径/参数) and the optional filter, but it does not explicitly mention that the operation is read-only or non-destructive. Since 'list' naturally implies a read operation, it is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main purpose ('列出全部可用 webapi 接口'), then specifies the fields and filter capability, and ends with the intended use. Every phrase earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description is complete: it states what is returned and the filter option. It lacks some details like return format or pagination, but for a discoverability tool, this is adequate. The sibling context reinforces that this is a meta-tool for finding other APIs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the one parameter 'family' already described in detail, including examples. The description only says '可按 family 过滤' (can filter by family), adding no new semantic information beyond the schema. Thus, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '列出全部可用 webapi 接口' (list all available web API endpoints), and specifies the resource (webapi interfaces) and the action (list). It also distinguishes itself from siblings by indicating it provides discovery of endpoints, while siblings are specific data tools like souyun_rhyme and slc_datasets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes '用于发现能力' (for discovering capabilities), which implies when to use this tool: when the agent needs to know what APIs are available. It also mentions filtering by family, but it does not explicitly state alternatives or scenarios where this tool should not be used. This is sufficient for a discovery tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses the core behavior (returning antithetical vocabulary) and adds a useful cost note about being token-free ('免token'). It does not, however, specify output format, limits, or error conditions, leaving some uncertainty for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that packs the essential information: purpose, input, output, and cost. It is front-loaded with the tool's name and function, with no filler or redundancy. This is an exemplary concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description covers the essential aspects: what it does, what input it needs, and why to use it. The main gap is the lack of any detail about the output format beyond 'vocabulary', which could be ambiguous. Overall, it is sufficiently complete for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a description for the 'word' parameter (including an example), and the overall schema description coverage is 100%. The main tool description adds no additional parameter semantics beyond what is in the schema, so it meets the baseline of 3. The example in the schema is helpful for understanding the expected input format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it returns antithetical (对仗) vocabulary for a given character or word. It distinguishes itself from sibling tools like souyun_rhyme by focusing on couplet alignment rather than rhyme, and it specifies the use case of writing couplets. The verb '返回' and resource '对仗词汇' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: '写对仗句用' (for writing antithetical sentences), which tells the agent when to invoke this tool. However, it does not explicitly mention alternatives or when not to use it, though the distinct purpose implicitly separates it from rhyming or poem tools. The guidance is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![OpenSH-mcp MCP server](https://glama.ai/mcp/servers/FreyaBit/OpenSH-mcp/badges/score.svg)](https://glama.ai/mcp/servers/FreyaBit/OpenSH-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/FreyaBit/OpenSH-mcp'

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