Skip to main content
Glama
Sign In
anker-xinlidou-mcp

anker-xinlidou-mcp

by dontbesilent2025
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

correction_guide

Provides correction rules for fixing speech recognition errors in transcripts, including homophones, misheard words, spacing, and proper nouns, without rewriting or summarizing.

Instructions

纠错规则：只纠语音识别错误（同音字、听错的词、空格、专名），不改写、不润色、不总结。

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "correction_guide"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden; it does disclose the permitted scope of edits (homophones, misheard words, spacing, proper nouns) and the prohibited operations, which is real behavioral content. It does not state that the call is read-only and side-effect free or that it simply returns static guidance text, leaving the agent to infer safety.

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?

One short sentence with no filler, and the core constraint (only ASR errors) is front-loaded. The leading label '纠错规则：' is slightly redundant with the tool name, keeping it just short of ideal.

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?

Complexity is minimal (no parameters, output schema present, so return values need no explanation), and the description conveys the rule content. It still never explicitly frames the tool as returning a set of rules, which is the one thing an agent must know to invoke it correctly.

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 takes zero parameters, so the baseline is 4 and there is no parameter meaning for the description to add. Nothing here misleads about inputs.

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 text names the resource (correction rules) and enumerates them, so an agent can guess this returns the ASR-correction guideline. But it is phrased as a bare rule statement with no verb saying what the tool does (returns/retrieves the guide), and nothing distinguishes it from siblings like glossary or pending_corrections beyond the subject matter.

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 negative constraints ('don't rewrite, don't polish, don't summarize') imply when these rules apply and how strictly, which is useful. However, there is no explicit instruction such as 'call this before save_correction' or any comparison to the other tools that also deal with corrections.

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

Deploy Server

Other Tools