Skip to main content
Glama
omd0

SRT Translation MCP Server

by omd0
OverviewSchemaRelated ServersScoreDiscussions
TypeScript

SRT Translation MCP Server

A Model Context Protocol (MCP) server for processing and translating SRT subtitle files with intelligent conversation detection and context preservation.

Features

  • SRT File Processing: Parse, validate, and manipulate SRT subtitle files

  • Large File Support: Intelligent chunking for processing large SRT files

  • Conversation Detection: Context-aware analysis for better translation quality

  • Style Tag Preservation: Maintain HTML-style formatting during translation

  • Timing Synchronization: Preserve precise timing information

  • MCP Integration: Standardized interface for AI assistant integration

Related MCP server: Translate SRT MCP Server

Installation

# Install dependencies
npm install

# Build the project
npm run build

# Run tests
npm test

Usage

As an MCP Server

# Start the MCP server
npm start

# Or run directly with npx
npx srt-translation-mcp-server

Available MCP Tools

  • parse_srt: Parse and validate SRT file content

  • write_srt: Write SRT file from parsed data

  • detect_conversations: Detect conversation boundaries in SRT content

  • translate_srt: Translate SRT content with context preservation

  • translate_chunk: Translate a specific chunk of SRT content

Example Usage

// Parse SRT file
const result = await mcpClient.callTool('parse_srt', {
  content: srtFileContent
});

// Detect conversations
const conversations = await mcpClient.callTool('detect_conversations', {
  content: srtFileContent
});

// Translate SRT file
const translated = await mcpClient.callTool('translate_srt', {
  content: srtFileContent,
  targetLanguage: 'es',
  preserveFormatting: true
});

Development

# Development mode with hot reload
npm run dev

# Run tests in watch mode
npm run test:watch

# Lint code
npm run lint

# Fix linting issues
npm run lint:fix

Architecture

Core Components

  • SRT Parser: Handles SRT file parsing and validation

  • Time Parser: Manages SRT time format operations

  • Style Tags: Preserves HTML-style formatting

  • Conversation Detector: Identifies conversation boundaries

  • Translation Service: Context-aware translation processing

  • MCP Server: Protocol implementation for AI integration

Key Features

  1. Intelligent Chunking: Breaks large files at natural conversation boundaries

  2. Context Preservation: Maintains conversation context for better translations

  3. Style Tag Support: Preserves HTML formatting during translation

  4. Timing Validation: Ensures timing sequences are valid and ascending

  5. Error Handling: Comprehensive error reporting and validation

Testing

The project includes comprehensive tests for all core functionality:

  • Time parsing and formatting

  • SRT file parsing and validation

  • Style tag detection and preservation

  • Conversation detection algorithms

  • Translation workflow integration

Run tests with:

npm test

License

MIT License - see LICENSE file for details.

Available Tools

6 tools
detect_conversationsA

๐Ÿš€ CHUNK-BASED TRANSLATION WORKFLOW INSTRUCTIONS ๐Ÿš€

๐Ÿ“‹ OVERVIEW: This tool analyzes SRT files and creates intelligent chunks for efficient translation. It returns METADATA ONLY - use get_next_chunk() and translate_srt() for actual content.

๐Ÿ” WHAT IT DOES:

  • SMART INPUT: Auto-detects file paths vs SRT content

  • Creates small chunks (1-3 subtitles each) optimized for AI processing

  • Detects languages (Arabic, English, Spanish, French) per chunk

  • Identifies speakers and conversation boundaries

  • Provides translation priority rankings (high/medium/low)

  • Stores chunks in memory to avoid context limits

  • Creates individual TODO tasks for tracking progress

๐Ÿ“Š WHAT IT RETURNS (SMALL RESPONSE):

  • chunkCount: Total number of chunks created

  • totalDuration: File duration in milliseconds

  • languageDistribution: Language counts (e.g., {"ar": 45, "en": 12})

  • previewChunk: Preview of first chunk metadata only

  • sessionId: For retrieving chunks later

  • message: Instructions for next steps

  • todos: Individual tasks for each chunk

๐ŸŽฏ RECOMMENDED WORKFLOW:

  1. Call detect_conversations with storeInMemory=true

  2. Review metadata to understand file structure (SMALL RESPONSE)

  3. Use get_next_chunk to process chunks one by one

  4. Use translate_srt() for actual translation

  5. Track progress with todo_management

๐Ÿ’ก EXAMPLES:

File Path Input: {"content": "/path/to/file.srt", "storeInMemory": true, "createTodos": true}

SRT Content Input: {"content": "1\n00:00:02,000 --> 00:00:07,000\nHello world", "storeInMemory": true}

โš ๏ธ IMPORTANT:

  • This returns METADATA ONLY - no actual text content

  • Response is SMALL to avoid context overflow

  • Use get_next_chunk() to retrieve individual chunks

  • Use translate_srt() for actual translation

  • Store chunks in memory for large files to avoid context limits

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYesSRT file content OR file path to analyze (auto-detected)
storeInMemoryNoStore chunks in memory to avoid context limits (default: false)
sessionIdNoSession ID for memory storage (optional, auto-generated if not provided)
createTodosNoCreate individual TODO tasks for each chunk (default: false)

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits: it explains the tool auto-detects input types (file paths vs content), stores chunks in memory to avoid context limits, creates TODO tasks, returns only metadata (not content), and produces small responses to prevent context overflow. It doesn't mention error handling or performance characteristics, keeping it from a perfect score.

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

Conciseness3/5

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

While well-structured with clear sections, the description is verbose with decorative elements (emojis, all-caps headers) that don't add functional value. The core information could be conveyed more efficiently. However, every sentence does serve a purpose in explaining the tool's role in the workflow.

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

Completeness5/5

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

For a tool with no annotations and no output schema, the description provides exceptional completeness: it explains what the tool does, how to use it in context with sibling tools, what parameters mean, what behavior to expect, what gets returned, and provides concrete examples. This fully compensates for the lack of structured metadata.

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?

With 100% schema description coverage, the baseline is 3. The description adds meaningful context beyond the schema: it explains the auto-detection behavior for the 'content' parameter, provides concrete examples of both input types, and clarifies the purpose of storeInMemory (to avoid context limits) and createTodos (for tracking progress). This adds substantial practical guidance.

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 clearly states the tool analyzes SRT files and creates intelligent chunks for translation, distinguishing it from siblings like parse_srt (which likely parses without chunking) and translate_srt (which handles actual translation). It specifies the verb (analyzes/creates) and resource (SRT files) with specific scope (chunk-based translation workflow).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool versus alternatives, including a recommended workflow (step 1), explicit instructions to use get_next_chunk() for content retrieval and translate_srt() for translation, and warnings that this returns metadata only. It clearly positions this as the entry point in a multi-step process.

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

get_next_chunkA

๐Ÿ“ฆ CHUNK RETRIEVAL FOR TRANSLATION WORKFLOW ๐Ÿ“ฆ

๐ŸŽฏ PURPOSE: Retrieves the next chunk from memory for sequential processing. Use this after detect_conversations with storeInMemory=true.

๐Ÿ”„ HOW IT WORKS:

  • Automatically tracks which chunk to return next

  • Returns actual chunk data with subtitle text content

  • Advances to next chunk automatically

  • Returns null when all chunks processed

๐Ÿ“ฅ PARAMETERS:

  • sessionId: Session ID from detect_conversations response

๐Ÿ“ค RETURNS:

  • chunk: Complete chunk data with subtitle text (or null if done)

  • chunkIndex: Current chunk number (0-based)

  • totalChunks: Total chunks available

  • hasMore: Boolean indicating if more chunks exist

  • message: Status message

๐Ÿ’ก USAGE PATTERN:

  1. Call detect_conversations with storeInMemory=true

  2. Get sessionId from response

  3. Call get_next_chunk repeatedly until hasMore=false

  4. Process each chunk for translation

  5. Use translate_srt() on individual chunks

๐Ÿ“‹ EXAMPLE: {"sessionId": "srt-session-123456789"}

โš ๏ธ NOTE:

  • Each call advances to the next chunk automatically

  • Store sessionId from detect_conversations response

  • Use this for chunk-by-chunk processing of large files

ParametersJSON Schema
NameRequiredDescriptionDefault
sessionIdYesSession ID from detect_conversations with storeInMemory=true

TDQS

A4.4/5.0
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 behaviors: automatic tracking of chunk sequence, advancement to the next chunk on each call, and returning null when processing is complete. It also notes prerequisites like storing the sessionId. However, it lacks details on error handling or performance aspects like rate limits.

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 well-structured with clear sections (PURPOSE, HOW IT WORKS, etc.) and uses emojis for visual organization, making it easy to scan. However, it includes some redundant information, such as repeating the sessionId parameter details that are already in the schema, slightly reducing efficiency. Overall, it is appropriately sized and front-loaded with key information.

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

Completeness5/5

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

Given the tool's complexity (sequential retrieval with state tracking), no annotations, and no output schema, the description provides comprehensive context. It explains the workflow, return values (chunk, chunkIndex, etc.), usage patterns, and notes on behavior like automatic advancement. This compensates well for the lack of structured data, making it complete for agent understanding.

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%, with the schema fully documenting the single parameter sessionId. The description adds minimal value beyond the schema by repeating the parameter name and its source, but does not provide additional semantic context or usage nuances. This meets the baseline of 3 when schema coverage is high.

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 explicitly states the tool's purpose as 'Retrieves the next chunk from memory for sequential processing,' specifying both the verb (retrieves) and resource (chunk from memory). It clearly distinguishes from sibling tools like detect_conversations, parse_srt, and translate_srt by focusing on sequential retrieval rather than detection, parsing, or translation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: 'Use this after detect_conversations with storeInMemory=true' and includes a detailed usage pattern with numbered steps. It also specifies alternatives indirectly by naming other tools in the workflow, such as using translate_srt() on individual chunks after retrieval.

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

parse_srtC

Parse SRT file content and return structured data

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYesSRT file content to parse

TDQS

C2.9/5.0
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. It states the tool 'parse[s] SRT file content and return[s] structured data,' which implies a read-only operation, but it doesn't specify error handling (e.g., for invalid input), performance characteristics, or the format of the returned structured data. This is a significant gap for a tool with no annotation coverage.

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 directly states the tool's function without any wasted words. It is front-loaded with the core action ('parse') and resource ('SRT file content'), making it easy to understand at a glance.

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 (parsing structured data) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'structured data' means in the return value, how errors are handled, or any constraints on the input content. For a parsing tool with no structured output documentation, this leaves critical gaps for the agent.

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 'content' parameter clearly documented as 'SRT file content to parse.' The description adds no additional meaning beyond this, as it only repeats that it parses 'SRT file content.' Given the high schema coverage, the baseline score of 3 is appropriate, as the schema already does the heavy lifting.

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 with a specific verb ('parse') and resource ('SRT file content'), making it immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'translate_srt' or 'write_srt' that also work with SRT files, which prevents a perfect score.

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 sibling tools like 'translate_srt' (for translation) or 'write_srt' (for writing), nor does it specify prerequisites such as needing valid SRT content. This leaves the agent without context for tool selection.

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

todo_managementC

Manage tasks for SRT processing workflows.

WHAT IT DOES:

  • Create, update, and track tasks during SRT processing

  • Monitor progress across different processing stages

  • Manage task priorities and dependencies

ACTIONS:

  • create: Create a new task

  • update: Update task status

  • complete: Mark task as completed

  • list: List all tasks

  • get_status: Get overall task status

TASK TYPES:

  • srt_parse: Parse and validate SRT file

  • conversation_detect: Detect conversation chunks

  • chunk_optimize: Optimize chunks for AI processing

  • ai_process: Process with AI model

  • translate: Translate content

  • quality_check: Quality assurance

  • output_generate: Generate final output

EXAMPLE USAGE:

  1. Create task: {"action": "create", "taskType": "srt_parse", "title": "Parse SRT file", "priority": "high"}

  2. Update status: {"action": "update", "taskId": "task-123", "status": "completed"}

  3. List tasks: {"action": "list"}

  4. Get status: {"action": "get_status"}

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesTodo action to perform
taskTypeNoType of task
titleNoTask title
descriptionNoTask description
priorityNoTask prioritymedium
taskIdNoTask ID (for update/complete actions)
statusNoTask status (for update action)
metadataNoAdditional task metadata

TDQS

C2.8/5.0
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. It mentions actions like 'create', 'update', and 'complete' which imply mutations, but doesn't specify permissions needed, whether tasks persist, error handling, or what 'get_status' returns. The description lacks critical behavioral context for a multi-action tool with mutation capabilities.

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

Conciseness3/5

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

The description is well-structured with clear sections (WHAT IT DOES, ACTIONS, TASK TYPES, EXAMPLE USAGE), but contains redundancy by repeating enum values already in the schema. The example usage section is helpful but could be more concise. Some sentences like 'Manage task priorities and dependencies' add value without being redundant.

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 complex 8-parameter tool with multiple mutation actions and no annotations or output schema, the description is incomplete. It doesn't explain what the tool returns for different actions, how tasks relate to actual SRT processing, error conditions, or persistence behavior. The lack of output schema means the description should compensate by explaining return values, which it doesn't.

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 schema already documents all 8 parameters thoroughly with descriptions and enums. The description adds minimal value beyond the schema - it lists the same action and taskType enums that appear in the schema. The example usage shows parameter combinations but doesn't provide additional semantic context beyond what's in the schema.

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 manages tasks for SRT processing workflows, with specific actions like create, update, and track tasks. It distinguishes from siblings like parse_srt or translate_srt by focusing on task management rather than direct SRT processing operations. However, it doesn't explicitly contrast with sibling tools in the description text itself.

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 the sibling tools like parse_srt or translate_srt. While it lists task types that correspond to some sibling functions, it doesn't explain when task management is appropriate versus calling those tools directly. The example usage shows how to invoke the tool but not when.

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

translate_srtA

๐ŸŒ SRT TRANSLATION HELPER TOOL ๐ŸŒ

๐Ÿšจ CRITICAL: THIS IS A HELPER TOOL ONLY - AI DOES THE TRANSLATION! ๐Ÿšจ

๐ŸŽฏ PURPOSE: This tool helps prepare SRT content for AI translation but DOES NOT translate text itself. The AI assistant must perform the actual translation work.

๐Ÿ“ WHAT IT DOES:

  • Parses SRT content and extracts subtitle text for AI translation

  • Preserves timing and formatting structure

  • Returns structured data for AI to translate

  • Provides context and metadata for better translation

โŒ WHAT IT DOES NOT DO:

  • โŒ Does NOT translate text automatically

  • โŒ Does NOT return translated content

  • โŒ Does NOT perform any AI translation

โœ… WHAT IT RETURNS:

  • Structured SRT data with original text

  • Timing and formatting information

  • Translation context and metadata

  • Ready-to-translate format for AI

๐Ÿ”„ RECOMMENDED WORKFLOW:

  1. Use detect_conversations to analyze file structure

  2. Use get_next_chunk to get individual chunks

  3. Use translate_srt to prepare chunk for AI translation

  4. AI assistant translates the text content

  5. AI assistant combines results into final SRT file

๐Ÿ’ก USAGE PATTERNS:

Prepare Full File for Translation: {"content": "full SRT content", "targetLanguage": "es", "sourceLanguage": "en"}

Prepare Individual Chunk for Translation: {"content": "chunk SRT content", "targetLanguage": "es", "sourceLanguage": "en"}

โš ๏ธ CRITICAL INSTRUCTIONS:

  • This tool ONLY prepares content for AI translation

  • AI assistant must do the actual text translation

  • Use this to get structured data, then translate with AI

  • Return format is ready for AI processing

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYesSRT file content to translate
targetLanguageYesTarget language code (e.g., es, fr, de)
sourceLanguageNoSource language code (optional, auto-detect if not provided)

TDQS

A4.1/5.0
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 what the tool does (parses SRT, extracts text, preserves timing/formatting, returns structured data) and what it doesn't do (translate automatically). It mentions the return format and provides critical instructions about the AI's role. However, it doesn't specify error handling, performance characteristics, or authentication needs.

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

Conciseness2/5

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

The description is excessively long with redundant sections and excessive emoji/formatting. Multiple sections repeat the same core message about being a helper tool (CRITICAL, PURPOSE, WHAT IT DOES NOT DO, CRITICAL INSTRUCTIONS). While information is front-loaded, the overall structure is bloated with unnecessary visual elements and repetition that don't add value.

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?

For a tool with no annotations and no output schema, the description does an excellent job explaining what the tool returns ('Structured SRT data with original text, Timing and formatting information, Translation context and metadata, Ready-to-translate format for AI'). It provides workflow context and distinguishes the tool's role from the AI's translation work. The main gap is lack of specific output format details that an output schema would provide.

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%, providing good baseline documentation for all three parameters. The description adds minimal parameter-specific information beyond the schema, though it does provide usage patterns that show example parameter values and clarifies that sourceLanguage is optional with auto-detection. This meets the baseline expectation when schema coverage is high.

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 explicitly states the tool's purpose: 'This tool helps prepare SRT content for AI translation but DOES NOT translate text itself.' It distinguishes itself from translation tools by emphasizing it's a helper tool that extracts and structures subtitle text for AI translation, not performing translation. The distinction from siblings like 'parse_srt' is implied through its specific translation-preparation focus.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: in a recommended workflow with 'detect_conversations' and 'get_next_chunk' as prerequisites, and 'write_srt' as a likely follow-up. It clearly states what it does NOT do (translate automatically), and includes usage patterns for full files or individual chunks. Alternatives are implied through the workflow steps and sibling tools.

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

write_srtC

Write SRT data to file format

ParametersJSON Schema
NameRequiredDescriptionDefault
srtDataYesSRT data object to write

TDQS

C2.7/5.0
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. It states the tool writes data, implying a mutation operation, but doesn't specify file creation behavior (e.g., overwrites existing files, requires permissions, or handles errors). For a write tool with zero annotation coverage, this leaves critical behavioral traits undisclosed.

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 with zero waste. It's front-loaded with the core action ('Write SRT data') and specifies the target ('to file format'), making it appropriately sized and easy to parse quickly.

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 write operation with nested object parameters) and lack of annotations or output schema, the description is incomplete. It doesn't cover behavioral aspects like file handling, error conditions, or output expectations, leaving significant gaps for an agent to use it correctly.

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%, with the parameter 'srtData' documented as an SRT data object to write. The description adds no additional meaning beyond this, such as format details or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't detract either.

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 states the tool writes SRT data to a file format, which is a clear verb+resource combination. However, it doesn't distinguish this from sibling tools like 'parse_srt' or 'translate_srt' that also handle SRT data, leaving the specific role ambiguous. The purpose is understandable but lacks 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 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. It doesn't mention prerequisites (e.g., needing parsed SRT data first), exclusions, or relationships to siblings like 'parse_srt' (which might prepare data for writing). Usage is implied from the name alone, with no explicit context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 6 tool updates
    • First observeddetect_conversations
    • First observedget_next_chunk
    • First observedparse_srt
    • First observedtodo_management
    • First observedtranslate_srt
    • First observedwrite_srt
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Each tool has a distinct, non-overlapping purpose in the SRT translation workflow: detect_conversations analyzes and chunks files, get_next_chunk retrieves chunks sequentially, parse_srt parses SRT content, todo_management manages tasks, translate_srt prepares content for AI translation, and write_srt writes output. The descriptions clearly differentiate their roles, with no ambiguity or overlap in functionality.

Naming Consistency4/5

Most tools follow a clear verb_noun pattern (e.g., detect_conversations, get_next_chunk, parse_srt, write_srt), which is consistent and predictable. However, translate_srt and todo_management deviate slightly by using a verb_noun format but with less precise action verbs, and todo_management is more generic. Overall, the naming is highly consistent with only minor deviations.

Tool Count5/5

With 6 tools, the server is well-scoped for its purpose of SRT translation. Each tool serves a specific role in the workflow (analysis, chunking, parsing, task management, translation preparation, and output), and none feel redundant or unnecessary. This count is ideal for covering the domain without being overwhelming or insufficient.

Completeness5/5

The tool set provides complete coverage for the SRT translation domain, supporting a full workflow from input analysis to output generation. It includes detection, chunking, parsing, task management, translation preparation, and file writing, with no obvious gaps. The descriptions emphasize a cohesive process, ensuring agents can handle all necessary operations without dead ends.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

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/omd0/srt-mcp'

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