Этот репозиторий архивирован. Проект переехал в char-index-skill, теперь доступный как плагин Claude Code Skill с продолжением поддержки сервера MCP.
Будущие обновления как Skill, так и MCP-сервера (
char-index-mcp) будут публиковаться из нового репозитория.
Сервер протокола контекста модели (MCP), обеспечивающий манипуляцию строками на основе индексов на уровне символов. Идеально подходит для генерации тестового кода, где важна точная позиция символов.
LLM генерируют текст посимвольно и испытывают трудности с точным подсчетом символов. При генерации тестового кода с определенными требованиями к длине или проверке позиций строк вам нужны точные инструменты, основанные на индексах. Этот MCP-сервер решает данную проблему.
Related MCP server: MCP Character Tools
find_nth_char - Найти n-е вхождение символа
find_all_char_indices - Найти все индексы символа
find_nth_substring - Найти n-е вхождение подстроки
find_all_substring_indices - Найти все вхождения подстроки
split_at_indices - Разделить строку по нескольким позициям
insert_at_index - Вставить текст в определенную позицию
delete_range - Удалить символы в диапазоне
replace_range - Заменить диапазон новым текстом
find_regex_matches - Найти совпадения регулярного выражения с позициями
extract_between_markers - Извлечь текст между двумя маркерами
count_chars - Статистика символов (всего, буквы, цифры и т.д.)
extract_substrings - Извлечь одну или несколько подстрок (универсальный инструмент)
Установка не требуется! Просто настройте и запустите:
# Test it works
uvx char-index-mcp --helppip install char-index-mcpgit clone https://github.com/agent-hanju/char-index-mcp.git
cd char-index-mcp
pip install -e .macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"char-index": {
"command": "uvx",
"args": ["char-index-mcp"]
}
}
}{
"mcpServers": {
"char-index": {
"command": "char-index-mcp"
}
}
}# Using uvx (recommended)
claude mcp add char-index '{"command":"uvx","args":["char-index-mcp"]}'
# Using pip install
claude mcp add char-index '{"command":"char-index-mcp"}'Добавьте в ~/.cursor/mcp.json:
{
"mcpServers": {
"char-index": {
"command": "uvx",
"args": ["char-index-mcp"]
}
}
}{
"mcpServers": {
"char-index": {
"command": "char-index-mcp"
}
}
}# Find 3rd occurrence of 'l'
find_nth_char("hello world", "l", 3) # Returns: 9
# Find all occurrences of 'l'
find_all_char_indices("hello world", "l") # Returns: [2, 3, 9]# Find 2nd "hello"
find_nth_substring("hello hello world", "hello", 2) # Returns: 6
# Find all occurrences
find_all_substring_indices("hello hello world", "hello") # Returns: [0, 6]# Insert comma after "hello"
insert_at_index("hello world", 5, ",") # Returns: "hello, world"
# Delete " world"
delete_range("hello world", 5, 11) # Returns: "hello"
# Replace "world" with "Python"
replace_range("hello world", 6, 11, "Python") # Returns: "hello Python"# Split at multiple positions
split_at_indices("hello world", [2, 5, 8]) # Returns: ["he", "llo", " wo", "rld"]
# Extract single character
extract_substrings("hello", [{"start": 1, "end": 2}])
# Returns: [{"start": 1, "end": 2, "substring": "e", "length": 1}]
# Batch extraction
extract_substrings("hello world", [
{"start": 0, "end": 5},
{"start": 6, "end": 11}
])
# Returns: [
# {"start": 0, "end": 5, "substring": "hello", "length": 5},
# {"start": 6, "end": 11, "substring": "world", "length": 5}
# ]# Find all numbers with their positions
find_regex_matches("test123abc456", r"\d+")
# Returns: [
# {"start": 4, "end": 7, "match": "123"},
# {"start": 10, "end": 13, "match": "456"}
# ]# Extract content between markers
extract_between_markers("start[content]end", "[", "]", 1)
# Returns: {
# "content": "content",
# "content_start": 6,
# "content_end": 13,
# "full_start": 5,
# "full_end": 14
# }# Clone the repository
git clone https://github.com/agent-hanju/char-index-mcp.git
cd char-index-mcp
# Install in development mode
pip install -e ".[dev]"
# Run tests
pytest
# Run with coverage
pytest --cov=char_index_mcp --cov-report=term-missingГенерация тестового кода: Генерация строк с точным количеством символов
Обработка данных: Разделение/извлечение данных по точным позициям
Форматирование текста: Вставка/удаление/замена по конкретным индексам
Анализ шаблонов: Поиск и извлечение совпадений по шаблону с позициями
Парсинг ответов LLM: Извлечение контента между XML-тегами по позиции
# Ask Claude: "Generate a test string that's exactly 100 characters long"
# Claude can use count_chars() to verify the exact length
# Ask: "Find where the 5th comma is in this CSV line"
# Claude can use find_nth_char(csv_line, ",", 5)
# Ask: "Split this string at characters 10, 25, and 50"
# Claude can use split_at_indices(text, [10, 25, 50])
# Ask: "Extract the text between the 2nd <thinking> and </thinking> tags"
# Claude can use extract_between_markers(text, "<thinking>", "</thinking>", 2)Вклад приветствуется! Пожалуйста:
Сделайте форк репозитория
Создайте ветку для новой функции
Добавьте тесты для нового функционала
Отправьте pull request
Лицензия MIT - подробности см. в файле LICENSE
mcp-character-counter - Подсчет и анализ символов
mcp-wordcounter - Подсчет слов и символов в файлах
text-master-mcp - Комплексный инструментарий для обработки текста
По вопросам, предложениям или проблемам, пожалуйста, откройте issue на GitHub.
Примечание: Это первый MCP-сервер, специально разработанный для манипуляции строками на основе индексов. Все остальные текстовые MCP-серверы фокусируются на подсчете, преобразовании регистра или кодировании, а не на точном позиционировании символов.
Count character statistics. Returns dict with total, without_spaces, letters, digits, spaces, special.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format ('Returns dict with total, without_spaces, letters, digits, spaces, special'), which is useful behavioral context. However, it lacks details on edge cases (e.g., empty strings, Unicode handling), performance implications, or error conditions. The description doesn't contradict annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: a single sentence that directly states the purpose and return value. Every word earns its place with no redundancy or fluff. It efficiently communicates core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single input, statistical output), no annotations, and no output schema, the description is minimally adequate. It covers the basic action and return structure but lacks details on usage context, parameter nuances, or behavioral specifics. For a simple tool, this might suffice, but gaps remain in guiding effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond the input schema, which has 0% description coverage and only documents 'text' as a required string parameter. However, with only 1 parameter, the baseline is 4 as per the rules (0 params = baseline 4, adjusted for minimal parameter count). The description implies the parameter is text to analyze but doesn't elaborate on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Count character statistics' specifies the verb (count) and resource (character statistics). It distinguishes from siblings like 'find_all_char_indices' or 'find_regex_matches' by focusing on statistical counting rather than searching or manipulation. However, it doesn't explicitly differentiate from all siblings (e.g., 'extract_substrings' might also involve counting in some contexts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 scenarios where counting characters is preferred over other text analysis tools (e.g., 'find_all_char_indices' for positional data or 'extract_between_markers' for extraction). There's no indication of prerequisites, limitations, or comparative context with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete characters in range [start, end).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| start | Yes | ||
| end | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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. While 'Delete' implies a destructive mutation, the description doesn't specify what happens to the modified text (whether it's returned, stored, or discarded), whether the operation is reversible, or any error conditions. The [start, end) notation suggests exclusive end indexing, but this isn't explicitly explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, with zero wasted language. It's front-loaded with the core action and immediately specifies the range format. Every word serves a purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which presumably documents return values), the description doesn't need to explain outputs. However, for a destructive mutation tool with 3 parameters and 0% schema coverage, the description is insufficient. It doesn't cover parameter meanings, error conditions, or behavioral details that would help an agent use it correctly alongside similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description only mentions 'start' and 'end' parameters indirectly through the range notation, completely omitting the 'text' parameter. It doesn't explain what the 'text' parameter represents (input text to modify), what valid ranges are, or whether indices are zero-based or one-based.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('characters in range'), making the purpose immediately understandable. It specifies the range format [start, end) which adds precision. However, it doesn't explicitly distinguish this from sibling tools like 'replace_range' or 'insert_at_index', which also manipulate text ranges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 are multiple sibling tools for text manipulation (replace_range, insert_at_index, extract_between_markers), but the description doesn't help an agent choose between them. It also doesn't mention prerequisites or constraints for using this deletion operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract content between markers with positions. Returns dict with content and position info.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| start_marker | Yes | ||
| end_marker | Yes | ||
| occurrence | No |
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 mentions the return type (dict with content and position info), but doesn't cover critical aspects like error handling (e.g., if markers are not found), performance implications, or whether the extraction is case-sensitive. This leaves significant gaps for a tool with 4 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. However, it could be more structured by separating usage details from return value, but it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, no output schema), the description is incomplete. It lacks details on parameter usage, error cases, and behavioral traits, making it inadequate for safe and effective tool invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It doesn't explain any parameters beyond what the schema titles imply (e.g., 'occurrence' with default 1 is not clarified). No additional meaning is provided for 'text', 'start_marker', 'end_marker', or how 'occurrence' affects extraction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('extract') and resource ('content between markers'), specifying it returns a dict with content and position info. However, it doesn't explicitly differentiate from sibling tools like 'extract_substrings' or 'find_regex_matches', which might offer similar extraction capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'extract_substrings' or 'find_regex_matches'. The description implies usage for extracting content between markers but lacks explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract substrings by index ranges. Supports negative indices and omitting end. Returns list of {start, end, substring, length} dicts.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| ranges | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: supports negative indices and omitting end, and returns structured dicts. However, it doesn't cover error handling (e.g., invalid ranges), performance characteristics, or whether the operation is read-only/destructive (though extraction implies non-destructive).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and well-structured: one sentence covering purpose, key features, and return format. Every word earns its place with zero redundancy. The information is front-loaded with the core functionality stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage and an output schema exists, the description provides adequate basic information but has gaps. It explains the return format (which the output schema would detail), but doesn't fully compensate for the undocumented parameters or provide complete behavioral context for a string manipulation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'index ranges' which helps explain the 'ranges' parameter, but provides no details about the 'text' parameter or the structure/format of range objects. The description adds minimal value beyond what's implied by parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Extract substrings by index ranges' with specific functionality (supports negative indices and omitting end) and output format. It distinguishes from siblings like 'extract_between_markers' by focusing on index-based extraction rather than marker-based, but doesn't explicitly compare to all alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'extract_between_markers', 'find_regex_matches', or other sibling tools. The description mentions technical capabilities but provides no context about appropriate use cases or when other tools might be better suited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all indices where a character appears. Returns empty list if not found.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| char | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the return behavior ('Returns empty list if not found'), which is helpful, but lacks details on performance (e.g., case sensitivity, handling of multiple characters, or error conditions). For a tool with no annotations, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that are front-loaded with the core purpose and include essential behavioral info. Every sentence earns its place by stating the action and the return behavior, with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no nested objects) and the presence of an output schema (which handles return values), the description is mostly complete. It covers the purpose and basic behavior, but could improve by addressing parameter semantics or usage guidelines to be fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It doesn't add any meaning beyond the schema's parameter names ('text' and 'char'), such as explaining what 'char' represents (e.g., a single character) or constraints. With 0% coverage and no param info in the description, it meets the baseline but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Find all indices') and resource ('where a character appears'), specifying the exact operation. It distinguishes from siblings like 'find_all_substring_indices' (for substrings) and 'find_nth_char' (for single occurrence), making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it 'Returns empty list if not found,' suggesting it's for checking character presence. However, it doesn't explicitly say when to use this tool versus alternatives like 'find_all_substring_indices' for substrings or 'count_chars' for counting, leaving the context somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all starting indices where a substring appears (includes overlaps).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| substring | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 'includes overlaps' which adds some context about the algorithm's behavior, but doesn't cover important aspects like case sensitivity, empty string handling, performance characteristics, or error conditions. This leaves significant gaps for a tool that performs string analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - a single sentence that communicates the core functionality and a key behavioral detail ('includes overlaps'). Every word earns its place with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (string search algorithm), no annotations, and the presence of an output schema (which handles return values), the description is minimally adequate. It covers the basic purpose and a key behavioral detail, but lacks important context about edge cases, performance, and differentiation from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. While it doesn't explicitly explain the 'text' and 'substring' parameters, their meaning is strongly implied by the tool's purpose. The description adds value by specifying 'includes overlaps' which clarifies the algorithm's behavior beyond basic parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('Find all starting indices') and resource ('where a substring appears'), and specifies it includes overlaps. However, it doesn't explicitly differentiate from sibling tools like find_nth_substring or find_regex_matches, 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.
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 find_nth_substring, find_regex_matches, or extract_substrings. It mentions 'includes overlaps' which hints at behavior but doesn't constitute usage guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find index of nth occurrence of a character. Returns -1 if not found.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| char | Yes | ||
| n | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return behavior ('Returns -1 if not found'), which is crucial for understanding outcomes. However, it doesn't mention error handling, performance, or other behavioral traits like character encoding or case sensitivity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly state the purpose and return behavior. Every word earns its place, and it's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and the presence of an output schema (which likely covers return values), the description is somewhat complete but lacks details on parameter usage and behavioral context. With no annotations and 0% schema coverage, it should do more to explain inputs and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'nth occurrence' and 'character', which hints at the 'n' and 'char' parameters, but doesn't explain the 'text' parameter or provide details like what 'n' defaults to (though the schema shows default=1) or how 'char' is interpreted (e.g., single character only). It adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Find index' and resource 'nth occurrence of a character', distinguishing it from siblings like 'find_all_char_indices' (which finds all occurrences) and 'find_nth_substring' (which works with substrings). It precisely defines what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for locating a specific occurrence of a character in text, but doesn't explicitly state when to use this tool versus alternatives like 'find_all_char_indices' or 'find_nth_substring'. No guidance on exclusions or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find starting index of nth occurrence of a substring. Returns -1 if not found.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| substring | Yes | ||
| n | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 clearly describes the core behavior (finding starting index) and edge case handling (returns -1 if not found), which is good. However, it doesn't mention performance characteristics, case sensitivity, encoding considerations, or what happens with overlapping matches - leaving some behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just two short sentences that communicate the essential information with zero waste. It's front-loaded with the core purpose and follows with the important edge case behavior. Every word earns its place in this minimal but complete description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (string search with occurrence counting), no annotations, and the existence of an output schema (which handles return value documentation), the description is reasonably complete. It covers the core functionality and error case, though it could benefit from mentioning case sensitivity or match behavior. For a utility function with output schema support, this provides adequate context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the lack of parameter documentation in the schema. While it doesn't explicitly name parameters, it clearly explains what the tool does with 'text', 'substring', and 'n' through its functional description. The mention of 'nth occurrence' and 'returns -1 if not found' provides semantic context for all three parameters, though it doesn't detail the default value for 'n' or parameter constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Find starting index of nth occurrence of a substring') and distinguishes it from siblings like 'find_all_substring_indices' (which finds all occurrences) and 'find_nth_char' (which works on characters rather than substrings). It uses precise technical language that defines exactly what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'find_all_substring_indices' for finding all occurrences or 'find_nth_char' for character-based searches. There's no context about when this specific nth-occurrence search is preferable to other substring tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all regex matches with positions. Returns list of {start, end, match} dicts.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| pattern | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 return format ('list of {start, end, match} dicts'), which is helpful, but lacks critical details like whether the search is case-sensitive, how overlapping matches are handled, or what happens with invalid regex patterns. For a regex 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: two sentences with zero waste. The first sentence states the purpose, and the second specifies the return format, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (regex matching), no annotations, and an output schema that likely covers return values, the description is minimally adequate. It explains what the tool does and the return format, but lacks details on parameter usage, error handling, or behavioral nuances, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It doesn't mention the 'text' or 'pattern' parameters at all, nor does it explain their roles or constraints (e.g., pattern syntax). However, with only 2 parameters and an output schema present, the baseline is 3, as the description adds some value by hinting at the return structure but doesn't fully address parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find all regex matches with positions.' It specifies the verb ('Find'), resource ('regex matches'), and scope ('all'), but doesn't explicitly differentiate from sibling tools like 'find_all_substring_indices' or 'find_all_char_indices' which serve similar search functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 sibling tools or suggest scenarios where regex matching is preferable to substring or character-based searches, leaving the agent without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insert text at index position without replacing. Supports negative indices.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| index | Yes | ||
| insertion | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions 'Supports negative indices' which adds useful behavioral context, but fails to disclose critical traits like whether the operation is idempotent, error handling for out-of-bounds indices, or performance characteristics for large texts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two clear sentences that are front-loaded with the core functionality. Every word earns its place with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but has output schema), the description is minimally adequate. The output schema existence means return values don't need explanation, but the description lacks context about the tool's role among siblings and behavioral expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies the 'index' parameter supports negative values but doesn't explain what 'text' and 'insertion' parameters represent or their relationships. The description adds minimal value beyond the bare parameter names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Insert text at index position') and the resource ('text'), distinguishing it from siblings like delete_range or replace_range. However, it doesn't explicitly differentiate from tools like split_at_indices that might also manipulate text positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 replace_range or insert operations in other tools. It mentions 'without replacing' but doesn't clarify scenarios where insertion versus replacement is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace characters in range [start, end) with new text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| start | Yes | ||
| end | Yes | ||
| replacement | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 action ('Replace characters') but lacks details on permissions, error handling, or output behavior. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core action and parameters. It's appropriately sized for the tool's complexity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, mutation operation) and the presence of an output schema, the description is minimally adequate but incomplete. It lacks behavioral details and usage context, though the output schema may cover return values, preventing a lower score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only implies parameters ('range [start, end) with new text') without explaining their meanings or constraints. It adds minimal value beyond the schema's property names, resulting in a baseline score due to inadequate compensation for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Replace characters') and the resource ('in range [start, end) with new text'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'delete_range' or 'insert_at_index', which also modify text at specific positions, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 scenarios where replacement is preferred over deletion or insertion, nor does it reference sibling tools, leaving the agent without context for selection among similar text manipulation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split text at exact index positions. Indices auto-sorted and deduplicated.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| indices | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that indices are 'auto-sorted and deduplicated', which is a useful behavioral trait beyond basic splitting. However, it doesn't cover other aspects like error handling (e.g., out-of-bounds indices), return format, or whether the operation is read-only or modifies data, leaving gaps for a tool with mutation implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that directly state the tool's function and a key behavioral trait. Every word earns its place, and it's front-loaded with the core purpose, making it efficient and easy to parse without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to explain return values. However, with no annotations, 0% schema coverage, and two parameters, the description is minimal. It covers the basic action and one behavioral aspect but lacks details on parameter usage, error cases, or interaction with siblings, making it adequate but incomplete for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies parameters 'text' and 'indices' but doesn't add meaning beyond the schema's titles. No details on index semantics (e.g., zero-based, inclusive/exclusive) or text handling are provided. The baseline is 3 since schema coverage is low, but the description doesn't adequately fill the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('split') and resource ('text'), specifying the action occurs 'at exact index positions'. It distinguishes from siblings like 'extract_substrings' or 'delete_range' by focusing on splitting rather than extraction or deletion. However, it doesn't explicitly contrast with all siblings, such as 'insert_at_index' which also involves indices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description mentions indices are 'auto-sorted and deduplicated', which hints at usage but doesn't specify scenarios like splitting text for processing segments versus using 'extract_between_markers' for marker-based extraction. It lacks clear when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
count_charsdelete_rangeextract_between_markersextract_substringsfind_all_char_indicesfind_all_substring_indicesfind_nth_charfind_nth_substringfind_regex_matchesinsert_at_indexreplace_rangesplit_at_indicesEach tool has a clearly distinct purpose with no overlap: character counting, deletion, extraction, finding indices, regex matching, insertion, replacement, and splitting. The descriptions precisely differentiate operations like find_all_char_indices vs find_nth_char, and extract_between_markers vs extract_substrings.
All tools follow a consistent snake_case verb_noun pattern (e.g., count_chars, delete_range, extract_between_markers). The naming is predictable and readable throughout, with verbs like count, delete, extract, find, insert, replace, and split consistently applied.
12 tools are well-scoped for a character/index manipulation server, covering essential operations without bloat. Each tool earns its place by addressing specific needs like character statistics, range operations, substring extraction, and pattern matching.
The toolset provides complete coverage for text manipulation tasks: counting, insertion, deletion, replacement, extraction, finding indices (both character and substring), regex matching, and splitting. There are no obvious gaps; agents can perform a full lifecycle of operations on text data.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Exact text tools for AI agents: unified diff, patch apply, regex testing, grapheme counting.
Exact character/word counting, reversal, palindrome checks, indexing, sorting; Unicode-safe.
Precision math engine for AI agents. 203 exact methods. Zero hallucination.
300+ deterministic data utilities for AI agents: validate, normalize, parse, match, redact.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/agent-hanju/char-index-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
