Skip to main content
Glama

weishengxin

get_faq

Find website usage guidance and common troubleshooting answers by keyword or FAQ ID. Load only when needed. / 按关键词或编号查询网站使用说明及常见问题,按需读取。

Input Schema

NameRequiredDescriptionDefault
limitNoFAQ entries per page, 1–20. / 每页问答数,1~20。
faq_idNoOptional exact FAQ ID. / 可选的精确问答编号。
offsetNoZero-based pagination offset. / 从0开始的分页起点。
keywordNoFAQ keywords; all space-separated terms match. / 问答关键词,空格分词全部匹配。

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full behavioral burden; it implies a read-only lookup but never says so outright. It discloses nothing about pagination behavior, empty-result handling, or total-count semantics, and does not mention that results come back paged. For a low-risk read tool this is acceptable but leaves real gaps.

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

Conciseness4/5

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

Two short, front-loaded sentences that state the action first and the loading hint second; nothing is wasted. The bilingual duplication lengthens it, but that appears to be a deliberate localization convention rather than filler.

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?

With an output schema present, the description needn't explain return values, and all four parameters are fully documented in the schema with zero required fields. What remains missing is only the when-to-use routing relative to siblings, which is a minor gap for a self-contained 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?

Schema coverage is 100%, so the schema already documents limit, offset, faq_id, and keyword with matching semantics. The description adds only the framing that keyword and FAQ ID are two lookup modes, without explaining precedence when both are supplied or that all space-separated terms must match.

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?

States a specific verb and resource: 'Find website usage guidance and common troubleshooting answers' via keyword or FAQ ID. The purpose is unambiguous and distinct from siblings like draw_plot or get_module_schema, though the description never explicitly contrasts itself with them.

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?

'Load only when needed' gives a weak just-in-time usage hint, implying this is an on-demand lookup rather than something to call preemptively. There is no explicit when-not-to-use guidance and no named alternative among the siblings for related documentation needs.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources