Skip to main content
Glama

SanYu Research Engine

act_lit_verify_citations

Read-only

【引文真实性核验】 用户担心参考文献是编的、要核验引用真伪 返回:逐条核验结果 (真实算法引擎执行,非大模型生成)

Input Schema

NameRequiredDescriptionDefault
textYes含引用的正文
topicNo主题

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds genuinely useful behavioral context beyond them: it says results come back item-by-item ('逐条核验结果') and emphasizes a deterministic algorithmic engine rather than LLM generation, which is a meaningful trust signal for this task. It still omits what a verdict looks like or how failures are reported.

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?

Three short segments, front-loaded with the user problem before the return-value note. The bracketed label slightly duplicates the annotation title, but overall there is no wasted wording.

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?

There is no output schema, so the description bears the burden of explaining returns, and '逐条核验结果' is only a sketch – it does not say what fields or verdict types an agent should expect per citation. Combined with the absent usage exclusions, this is adequate but not complete for a verification 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 description coverage is 100% for both parameters ('text' – body text containing citations, and 'topic' – subject), so the schema already carries parameter meaning. The description adds nothing about how 'text' is parsed or what role 'topic' plays, so the baseline 3 applies.

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 names a specific verb and resource ('引文真实性核验' – verification of citation authenticity) and states the exact problem it solves (users suspecting fabricated references). It is clearly distinguishable from siblings like act_lit_search or act_citation_format, though it never names those siblings explicitly.

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 gives a concrete trigger condition: use this when the user worries references may be fabricated and wants to check citation authenticity. It does not state when NOT to use it or point to related siblings such as act_lit_search or act_citation_format, so routing among the literature tools is still left partly to inference.

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.