Skip to main content
Glama

Server Quality Checklist

67%
Profile completionA complete profile improves this server's visibility in search results.
  • Latest release: v0.1.0

  • Disambiguation4/5

    Each tool targets a fairly distinct retrieval need: QQ channel hot summaries, official-site recent info, official-site full-text search, and cross-source question search. The only mild overlap is between official_site_recent and official_site_search, but their descriptions make the difference clear enough.

    Naming Consistency4/5

    Tool names are consistently lowercase snake_case and follow recognizable source prefixes like campus_* and official_site_*. However, suffixes mix result-oriented terms (summary, recent) with action terms (search), so they do not follow a strict verb_noun pattern throughout.

    Tool Count5/5

    Four tools is well-scoped for a campus information retrieval server. Each tool covers a distinct retrieval workflow without redundancy, and the set is neither too thin nor overloaded for its stated purpose.

    Completeness4/5

    The set covers recent official announcements, full-text official-site search, QQ channel hot content, and a combined question-based search across both sources. A dedicated channel-only keyword search is missing, but campus_question_search partially fills that gap, so the surface is reasonably complete.

  • Average 3.6/5 across 4 of 4 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 2 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

  • Behavior3/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    The description clearly states that this is a full-text keyword search and details the returned fields, which is useful given that no annotations are provided. However, it does not disclose behavioral specifics such as the default 90-day time window, the maximum number of results, or how the optional keyword parameter interacts with query.

    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 filler. It efficiently conveys the operation, scope, and output contract in one pass.

    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?

    While the output contract is covered, the description is incomplete for a tool with four parameters and no annotations. An agent can make a minimal call using the required query, but it cannot confidently determine when to prefer this tool over siblings or how to correctly use keyword, days, and max_results without additional inference.

    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 has 0% description coverage, and the description does not explain the relationship between query and keyword or the meaning of days and max_results. The phrase '关键词全文检索' partially clarifies that query is the search term, but the remaining parameters remain semantically underspecified.

    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 uses a specific verb ('执行关键词全文检索'), names the exact resource ('西北农林科技大学官网(含新闻网)'), and states the output format (Markdown list with title/date/source/abstract/link). This makes the tool clearly distinguishable from siblings like official_site_recent or campus_question_search.

    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 gives no guidance on when to use this tool versus its siblings. It does not mention that official_site_recent is for recency-based browsing or that campus_question_search targets Q&A content, so the selection criteria are entirely implied rather than explicit.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior4/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations, the description carries the behavioral burden; it discloses that this is a read-only query of the official site and that output is a Markdown summary, plus that keyword narrows the results. It does not mention rate limits, freshness boundaries, or failure modes, but for a simple read tool the key behavioral traits are disclosed.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    Two sentences with no filler: the first establishes tool, source URL, content scope, and output format; the second gives the key parameter example. The most load-bearing information is front-loaded.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    The tool is simple and the output schema is present, which covers return structure. However, the description does not explain three of the four parameters, nor does it position the tool against official_site_search, so an agent still has meaningful uncertainty about how to set days/category/max_results and when to choose this over its siblings.

    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 description coverage is 0%, so the description must compensate, but only keyword is given real meaning (with the '植保学院' example). days, category, and max_results are left to inference from their names and defaults, which is insufficient with no schema descriptions.

    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–resource pair: query the NWAFU official website for recent activities, competitions, notices, and recruitment information, then output a Markdown summary. It does not explicitly distinguish itself from official_site_search or the other siblings, so it loses a point for lacking sibling differentiation.

    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 intended use—retrieving recent official-site news—is implied and there is a concrete keyword example, but no alternative tools are named and no when-not-to-use conditions are given. Sibling tools like official_site_search could overlap, yet the description does not route the agent between them.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior4/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are provided, so the description carries the full burden. It transparently discloses the source URL, ranking formula, automatic categorization, Markdown output, and source attribution. It does not mention failure modes or rate limits, but the core behavior is clearly described.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness4/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is a single dense sentence that front-loads the fetch action, source, ranking, categorization, and output format. Every clause is relevant, though a more structured breakdown of parameters would improve readability.

    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?

    The output schema covers return structure, and the description explains source, ranking, categories, and citations. However, with five parameters and no explicit guidance on when to invoke this tool versus siblings, the description is not fully complete.

    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 description coverage is 0%, and the description does not explain any of the five parameters. Terms like 'top_n' and 'window_hours' are only indirectly related to '热度榜' and '近期帖子', while max_posts, comment_top_n, and include_comments receive no clarification.

    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 states a specific action: fetch recent posts from a named QQ channel, rank them by likes+comments, categorize them into seven types, and output a Markdown summary with source links. It clearly identifies the resource and unique behavior, distinguishing it from a plain recent-posts or search tool.

    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 this tool is for obtaining a ranked, categorized summary of QQ-channel posts rather than raw retrieval or search. It does not explicitly state when to use this tool versus the sibling tools or describe exclusions.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior4/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations exist, so the description carries the full transparency burden. It does disclose the full search pipeline: auto keyword extraction, dual-source search, and merged Markdown output with source titles and links. It does not, however, explain the days recency window, the include_channel toggle, or behavior with zero results.

    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?

    One dense sentence that front-loads the action and sources, then follows with the pipeline steps and output format. Every clause adds information and there is no 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?

    The description is sufficient for a default invocation using only the required question, and an output schema covers the return structure. However, with 0% schema coverage, no annotations, and three sibling tools, the missing parameter semantics and lack of alternative routing keep it from being fully complete.

    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?

    With schema description coverage at 0%, the description needed to compensate, but it only clarifies the question parameter through the auto-extraction behavior. The parameters days, keywords, max_results, and include_channel are left unexplained, so an agent cannot reliably customize the call beyond the required question.

    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 names the action (检索), the exact sources (学校官网 + 校园 QQ 频道), and the concrete pipeline: keyword extraction, searching both sources, and merging Markdown results with titles and links. This clearly distinguishes it from siblings like official_site_search, which are single-source or summary tools.

    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 for natural-language questions covering both campus sources, but it never states explicit when-not conditions or names sibling tools as alternatives. The '自定义问题' phrasing provides context without exclusions, so the agent must infer the boundary with official_site_search.

    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

nwafu-AgentPlatformMCP MCP server

Copy to your README.md:

Score Badge

nwafu-AgentPlatformMCP MCP server

Copy to your README.md:

Latest Blog Posts

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/unielevotor/nwafu-AgentPlatformMCP'

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