MCP SubMatcher

by sienyaa

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: get_config_summary and get_config_value handle configuration retrieval, set_config_value handles configuration modification, scan_media_files discovers files, preview_matching shows results without changes, and rename_subtitles performs the actual renaming. An agent can easily distinguish between these functions.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using snake_case: get_config_summary, get_config_value, preview_matching, rename_subtitles, scan_media_files, and set_config_value. This predictable naming scheme makes the tool set easy to navigate and understand.
Tool Count5/5
With 6 tools, this server is well-scoped for subtitle matching and configuration management. Each tool earns its place by covering distinct aspects of the workflow, from scanning and previewing to renaming and configuration, without being overly sparse or bloated.
Completeness5/5
The tool set provides complete coverage for the subtitle matching domain: scanning media files, previewing matches, executing renames, and full CRUD operations on configuration (get/set values and summary). There are no obvious gaps, allowing agents to handle the entire workflow seamlessly.
Average 2.9/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/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 behavioral disclosure. The description only states the action without explaining critical behaviors: it doesn't mention that this is a potentially destructive operation (renaming files), the default 'confirm=false' puts it in a dry-run mode, what happens if errors occur, or any permissions/rate limits. This leaves significant gaps for a mutation tool.
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 extremely concise—a single phrase in Chinese—with no wasted words. However, it's under-specified rather than efficiently informative, lacking necessary details for clarity. It's front-loaded but incomplete, so it doesn't fully earn a top score despite its brevity.
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's complexity (a mutation operation with a dry-run mode), lack of annotations, and no output schema, the description is incomplete. It fails to explain the tool's behavior, output format, or error handling. For a tool that modifies files, this minimal description is inadequate to ensure safe and correct usage.
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%, so the input schema fully documents both parameters ('directory' and 'confirm') with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as explaining how the renaming logic works or what 'directory' should contain. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '执行字幕重命名操作' is a tautology that essentially restates the tool name 'rename_subtitles' in Chinese. It doesn't specify what resources are being renamed (e.g., subtitle files in a directory) or provide any distinguishing details from sibling tools. While it indicates the action (rename subtitles), it lacks specificity about scope or method.
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 description doesn't mention prerequisites, context for use, or exclusions. Given sibling tools like 'preview_matching' and 'scan_media_files' that might relate to media processing, there's no indication of how this tool fits into a workflow or when it's appropriate.
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?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states what the tool does ('get current configuration summary') without any information about permissions required, whether this is a read-only operation, what format the summary returns, or any rate limits. For a tool with zero annotation coverage, this leaves significant behavioral 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?
The description is a single, efficient sentence ('获取当前配置摘要') that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool with no parameters. However, it could be slightly more front-loaded with additional context, but given the simplicity, this is minor.
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's simplicity (0 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what a 'configuration summary' entails, how it differs from detailed values, or what the return format might be. Without annotations or output schema, the description should provide more context about the tool's behavior and output to be fully helpful to an 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 tool has 0 parameters, and schema description coverage is 100% (though empty since there are no parameters). With no parameters to document, the description doesn't need to compensate for any schema gaps. The baseline for zero parameters is 4, as there's nothing to explain beyond what's already covered by the absence of parameters.
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 '获取当前配置摘要' (Get current configuration summary) clearly states the verb 'get' and resource 'configuration summary', but it's somewhat vague about what exactly constitutes a 'summary' versus detailed configuration values. It doesn't distinguish itself from sibling tools like 'get_config_value' which presumably retrieves specific configuration values rather than a summary.
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 guidance on when to use this tool versus alternatives like 'get_config_value' or 'set_config_value'. There's no mention of prerequisites, context for when a summary is more appropriate than detailed values, or any exclusions. The agent must infer usage from the tool name alone.
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 full burden for behavioral disclosure. While '获取' implies a read operation, it doesn't specify whether this requires special permissions, what happens if the path doesn't exist, whether it's cached or real-time, or what format the returned value takes. For a tool that reads configuration data, this leaves significant behavioral questions unanswered.
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, efficient sentence that states exactly what the tool does without any wasted words. It's appropriately sized for a simple retrieval tool and gets straight to the point with no unnecessary elaboration.
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 configuration retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what type of value is returned (string, number, object), whether there are default values, what error responses look like, or how this differs from the sibling 'get_config_summary' tool. The description leaves too many contextual questions unanswered for effective agent use.
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 minimal value beyond the input schema, which already has 100% coverage with a clear parameter description. The description mentions '指定路径' (specified path) but doesn't elaborate beyond what the schema already documents about dot notation and array indexing. With complete schema coverage, the baseline is 3 even without additional parameter semantics in the description.
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 states the tool's purpose: retrieving a value from a configuration file at a specified path. It uses a specific verb ('获取' - get/retrieve) and identifies the resource ('配置文件' - configuration file). However, it doesn't explicitly differentiate from its sibling 'get_config_summary', which might retrieve summary information rather than specific values.
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 guidance on when to use this tool versus alternatives. It doesn't mention when to use 'get_config_value' versus 'get_config_summary' (a clear sibling tool) or 'set_config_value' (the complementary write operation). There's no indication of prerequisites, error conditions, or typical use cases.
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 full burden for behavioral disclosure. While '扫描' implies a read operation, it doesn't specify whether this is recursive, what file formats are supported, whether it modifies files, what happens with permissions errors, or what the output format will be. For a scanning tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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, efficient sentence in Chinese that directly states the tool's function without unnecessary words. It's appropriately sized for a simple scanning tool and front-loads the core action ('扫描') and target resources. Every word contributes to understanding the tool's purpose.
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 scanning tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what constitutes a successful scan, what information is returned about found files, how errors are handled, or whether there are any limitations (file size, depth, permissions). The agent lacks crucial context about the tool's behavior and outputs despite the simple parameter structure.
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 description coverage is 100% with the single parameter 'directory' well-documented in the schema. The description adds minimal value beyond what's already in the schema - it mentions '指定目录' (specified directory) which aligns with the schema's '要扫描的目录路径' (directory path to scan). No additional parameter context, constraints, or examples are provided beyond the structured schema documentation.
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 states the action ('扫描' - scan) and target resources ('视频和字幕文件' - video and subtitle files) with a specific scope ('指定目录中' - in specified directory). It distinguishes itself from siblings like get_config_summary or rename_subtitles by focusing on file scanning rather than configuration or renaming operations. However, it doesn't explicitly differentiate from preview_matching which might also involve file examination.
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 guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when-not-to-use scenarios, or comparison with sibling tools like preview_matching or rename_subtitles. The agent must infer usage context solely from the tool name and description without explicit direction.
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 states the tool sets a value in a config file, implying a write/mutation operation, but doesn't mention potential side effects, permissions required, whether changes are reversible, or error handling. This leaves significant gaps in understanding the tool's behavior beyond the basic action.
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, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for a simple tool, with zero wasted text.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after setting the value (e.g., success/failure response, side effects), lacks context about the config file's nature, and provides minimal behavioral transparency, making it inadequate for safe and effective use.
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%, so the input schema already documents both parameters ('path' and 'value') with descriptions and examples. The tool description doesn't add any meaningful semantic context beyond what the schema provides, such as format details or constraints, but doesn't need to compensate for gaps either.
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 states the action ('设置' meaning 'set') and the target ('配置文件中指定路径的值' meaning 'value at specified path in config file'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'get_config_value' or 'get_config_summary' beyond the basic action difference.
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 like 'get_config_value' or 'preview_matching'. The description lacks context about prerequisites, appropriate scenarios, or exclusions, offering only the basic function without usage context.
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 provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's a preview/exercise mode ('演习模式') and non-destructive ('不会实际修改文件'), which clarifies safety and operational context. However, it doesn't mention potential side effects like performance impact or output format, leaving some gaps.
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 extremely concise and front-loaded, consisting of a single sentence in Chinese that efficiently conveys the core purpose and key behavioral trait. Every word earns its place, with no wasted information, making it easy to parse quickly.
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 the tool's moderate complexity (previewing subtitle matching), no annotations, no output schema, and 1 parameter with full schema coverage, the description is minimally adequate. It covers the purpose and safety aspect but lacks details on what the preview output entails (e.g., format, success criteria) or prerequisites. For a tool with no structured output, more context would be helpful.
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 has 100% description coverage, with the parameter 'directory' documented as '要分析的目录路径' (directory path to analyze). The description doesn't add any semantic details beyond this, such as expected directory structure or file types. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation.
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 states the tool's purpose: '预览字幕匹配结果' (preview subtitle matching results). It specifies the action (preview) and the resource (subtitle matching results), though it doesn't explicitly differentiate from siblings like 'rename_subtitles' or 'scan_media_files' beyond the 'preview' aspect. The description is specific but lacks sibling differentiation for a full score.
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 usage context with '演习模式，不会实际修改文件' (exercise mode, will not actually modify files), suggesting it's for testing or simulation purposes. However, it doesn't explicitly state when to use this tool versus alternatives like 'rename_subtitles' (which likely modifies files) or 'scan_media_files' (which might scan without previewing). The guidance is implied but not explicit.
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:

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

Score Badge

Copy to your README.md:

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

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/sienyaa/mcp-submatcher'

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