editor-mcp

by danielpodrazka

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
Disambiguation4/5
Most tools have distinct purposes, but 'cancel' and 'confirm' are ambiguous without context, and 'find_function' and 'find_line' could be confused as both search within files. The core editing tools like 'read', 'select', and 'overwrite' are clearly differentiated, supporting a coherent workflow.
Naming Consistency3/5
The naming is mixed with some consistency: verbs like 'find', 'set', and 'run' are used, but patterns vary (e.g., 'listdir' vs. 'new_file', 'overwrite' vs. 'select'). There's no uniform verb_noun structure, making it readable but not predictable across all tools.
Tool Count5/5
With 14 tools, this is well-scoped for an editor server, covering file operations, editing, searching, and testing. Each tool serves a specific role in the workflow, and the count is neither too sparse nor overwhelming for the domain.
Completeness4/5
The toolset provides strong coverage for file editing and testing workflows, including create, read, update, and delete operations. Minor gaps exist, such as no explicit 'save' or 'undo' tools, but agents can work around these using existing tools like 'overwrite' and workflow steps.
Average 3.1/5 across 14 of 14 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Cancel action' gives no information about what the tool actually does behaviorally - whether it's a read-only status change, a destructive operation, what permissions are required, what side effects occur, or what the typical response looks like. The description is completely inadequate for understanding the tool's behavior.
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?
While 'Cancel action' is extremely brief, this is under-specification rather than effective conciseness. The two words fail to provide necessary information about the tool's purpose and usage. True conciseness would efficiently convey essential information, but this description is so sparse that it's essentially non-functional as documentation.
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 that the tool has no parameters but likely performs some meaningful action (cancellation), the description is incomplete. With no annotations to provide behavioral context and a description that offers only the most minimal information, an agent would struggle to understand when and how to use this tool appropriately. The existence of an output schema helps somewhat, but the description itself provides insufficient context for effective tool selection and invocation.
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 with 100% schema description coverage, so the schema fully documents the parameter situation (none). The description doesn't need to compensate for any parameter documentation gaps. The baseline for zero parameters with full schema coverage is 4, as there are no parameters whose semantics need explanation beyond what the schema provides.
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 'Cancel action' is a tautology that essentially restates the tool name 'cancel'. It doesn't specify what type of action gets canceled, what resource is affected, or what the cancellation entails. While the name suggests a general cancellation function, the description adds no meaningful clarification beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With sibling tools like 'confirm', 'delete_file', 'overwrite', and others that might represent different actions or states, there's no indication of what context triggers a cancellation, what prerequisites exist, or what alternatives might be appropriate in different scenarios.
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. 'Confirm action' implies a mutation (confirmation typically changes state), but it doesn't specify what gets confirmed, whether it's reversible, what permissions are needed, or what the response contains. This leaves significant gaps for a tool that likely modifies workflow state.
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 extremely concise ('Confirm action') but arguably under-specified rather than efficiently informative. While it wastes no words, it fails to provide the minimal context needed to understand what's being confirmed, making this brevity problematic rather than virtuous.
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 likely performs a state-changing confirmation (implied by the name and sibling tools like 'cancel'), the description is incomplete. With no annotations, no parameter documentation needed, but an output schema exists, the description should at least clarify what action is confirmed and in what context, which it fails to do.
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 zero parameters with 100% schema description coverage, so the schema already fully documents the absence of inputs. The description doesn't need to compensate for any parameter gaps, and 'Confirm action' appropriately implies no additional inputs are required for a simple confirmation operation.
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 'Confirm action' is a tautology that essentially restates the tool name 'confirm' without specifying what action is being confirmed or what resource is involved. It provides no differentiation from sibling tools like 'cancel' or 'select' that might also involve confirmation-like operations.
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 indicate what context triggers its use, what prerequisites exist, or how it differs from sibling tools like 'cancel' (which might abort an action) or 'select' (which might choose among options).
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, the description carries full burden but only states the action without behavioral details. It doesn't disclose if deletion is permanent, requires permissions, has side effects, or what happens on success/failure. 'Delete' implies destructive mutation, but specifics are missing.
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?
Extremely concise at two words, front-loaded with the core action. Every word earns its place with no wasted text, though this brevity contributes to vagueness in other dimensions.
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 destructive mutation tool with no annotations, the description is incomplete. It lacks context on what 'current' means, deletion behavior, permissions, or output. The presence of an output schema helps, but the description doesn't leverage it to explain return values or error conditions.
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 with 100% schema coverage, so no parameter documentation is needed. The description doesn't add param info, but that's appropriate here, meeting the baseline for zero-param tools.
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 'Delete current file' clearly states the action (delete) and target (current file), but it's vague about what 'current' refers to in context. It doesn't distinguish this from potential sibling operations like 'overwrite' or 'cancel' that might also modify files.
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 'overwrite' or 'cancel'. The description implies it's for deletion but doesn't specify prerequisites, conditions, or what makes a file 'current'.
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 but provides minimal behavioral information. It mentions this is for a 'subsequent overwrite operation' which implies this is a preparatory step, but doesn't describe what happens during the selection (does it lock lines? create a temporary buffer? require specific permissions?). No information about side effects, error conditions, or performance characteristics.
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 appropriately brief with clear sections (purpose statement, Args, Returns). The first sentence could be more polished ('Select lines from' is incomplete), but overall the structure is efficient with no wasted words. Each section serves a clear purpose.
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 there's an output schema (Returns section), the description doesn't need to explain return values in detail. However, for a tool with no annotations and only 2 parameters, the description provides adequate but minimal context. It explains what the tool does and documents parameters, but lacks information about error conditions, prerequisites, or how it integrates with the 'overwrite' sibling tool.
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 description includes an Args section that clearly documents both parameters with their types and meaning (line numbers, 1-based). With 0% schema description coverage and only 2 parameters, this documentation fully compensates for the schema gap. The parameter information is complete and adds meaningful context beyond the bare schema.
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 'Select lines from for subsequent overwrite operation' which indicates a selection function but is grammatically awkward and vague about what resource is being selected from. It distinguishes from siblings like 'overwrite' by indicating this is a preparatory step, but doesn't clarify what type of content or file is involved.
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 mentions this is 'for subsequent overwrite operation' which provides some context about when to use it, but doesn't explicitly state when NOT to use it or what alternatives exist. No guidance is given about prerequisites or how this tool relates to other file operations in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 overwrites lines and returns a diff preview with syntax errors for JS or Python, which adds useful context about output and language-specific behavior. However, it lacks details on permissions, side effects (e.g., whether changes are immediate or require confirmation), or error handling, leaving 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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by key behavioral details. The Args and Returns sections are structured but could be more integrated. There's minimal waste, though the example in Args might be slightly verbose; overall, it earns its place efficiently.
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 complexity (mutation with 1 parameter, nested objects, and an output schema), the description is partially complete. It explains the action and return values, and the output schema likely covers the diff preview details, reducing the burden. However, with no annotations and low schema coverage, it misses critical context like safety, prerequisites, and full parameter semantics, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 provides an example for the 'new_lines' parameter (a dict with a 'lines' key containing an array of strings), which adds meaning beyond the generic object type in the schema. However, it doesn't explain the structure fully (e.g., other possible keys, constraints) or cover nested object details, resulting in incomplete 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: 'Overwrite the selected lines with new text' specifies the verb (overwrite) and resource (selected lines). It distinguishes from siblings like 'delete_file' or 'set_file' by focusing on line-level text replacement rather than file operations. However, it doesn't explicitly differentiate from similar text-editing siblings that might exist, keeping it at 4 instead of 5.
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 mentions that the amount of new lines can differ from the original selection, which implies a context of line editing, but it doesn't specify prerequisites (e.g., needing a selection first), exclusions, or direct comparisons to siblings like 'set_file' or 'confirm'. This leaves the agent without clear usage instructions.
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 the full burden. It implies a configuration change ('set') but doesn't disclose behavioral traits like whether it's persistent, requires specific permissions, or has side effects. For a mutation tool with no annotations, this is inadequate.
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 is front-loaded with the key information. It wastes no words and is appropriately sized for its purpose, earning full marks for conciseness.
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 as a configuration setter with no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on behavior, parameter usage, and expected outcomes, making it insufficient for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description doesn't add any meaning about the 'path' parameter. It fails to explain what the path represents, its format, or examples, leaving the parameter semantics unclear.
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's purpose is to 'set' something 'before running tests' for project recognition, which is clear but vague. It doesn't specify what exactly is being set (Python path) or distinguish it from siblings like 'set_file', making it moderately helpful but lacking specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use it ('before running tests'), which is helpful guidance. However, it doesn't mention when not to use it or alternatives among siblings, such as how it differs from 'set_file', leaving some gaps in usage differentiation.
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 but provides minimal behavioral context. It mentions the tool runs tests in a virtual environment but doesn't disclose critical behaviors like: whether it modifies files, what happens if tests fail, if it requires specific permissions, execution timeouts, or how results are structured beyond the basic return dict. The description doesn't contradict annotations (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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose statement, Args, Returns) and appropriately sized. The opening sentence efficiently states the core purpose. The Args section is necessary given the 0% schema coverage. Only minor improvement possible by integrating parameter explanations more seamlessly.
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 4 parameters with 0% schema coverage and no annotations, the description does a good job explaining parameters and return values. However, for a test execution tool that could have significant behavioral implications (modifying state, long-running processes, failure modes), the description lacks important context about execution environment, error handling, and behavioral constraints that would be needed for safe agent use.
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 0% schema description coverage, the description compensates well by clearly explaining all 4 parameters in the Args section, adding meaningful context about what each parameter controls. The description provides semantic value beyond the bare schema by explaining test_path accepts 'Directory or file path', test_name is for 'Specific test function/method', and what collect_only actually does ('Only collect tests without executing them').
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 specific action ('Run pytest tests') and resource ('using the specified Python virtual environment'), distinguishing it from all sibling tools which are file/function operations rather than test execution. The verb 'Run' is precise and unambiguous.
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 about when to use this tool versus alternatives. While it's clearly for running pytest tests, there's no mention of prerequisites (e.g., needing a virtual environment setup), when to use collect_only versus full execution, or how it relates to other testing tools (none exist among siblings).
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 the full burden. It states the tool sets a file as a prerequisite for other operations, implying a stateful context, but doesn't disclose behavioral traits like whether the file must exist, what happens on invalid paths, if this persists across sessions, or any error conditions. For a tool with no annotations, this leaves significant 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 concise and well-structured: two sentences that efficiently convey purpose and usage guidelines without redundancy. Every sentence adds value, and it's front-loaded with the core action.
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 (stateful operation with a prerequisite role), no annotations, and an output schema present (which may cover return values), the description is partially complete. It explains the workflow role but lacks details on parameter semantics and behavioral transparency, making it adequate but with clear gaps.
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 1 parameter with 0% description coverage. The description doesn't add any meaning beyond the schema—it doesn't explain what 'filepath' represents (e.g., absolute/relative path, format, constraints). With low schema coverage, the description fails to compensate, but since there's only one parameter, the baseline is slightly higher than minimal.
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: 'Set the current file to work with.' This is a specific verb ('set') and resource ('current file'), making the action understandable. However, it doesn't explicitly differentiate from sibling tools like 'new_file' or 'delete_file' beyond workflow context.
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 usage guidance: 'This is always the first step in the workflow. You must set a file before you can use other tools like read, select etc.' It clearly states when to use it (first step) and why (prerequisite for other tools), with named alternatives mentioned.
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 the full burden. It states the tool finds matching lines but does not disclose behavioral traits such as case sensitivity, regex support, search scope (e.g., whole file vs. visible portion), or performance considerations (e.g., large file handling). The description is minimal beyond the basic operation.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by structured Args and Returns sections. Every sentence earns its place with no redundant information, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the presence of an output schema (which covers return values), the description is mostly complete. It explains what the tool does and the parameter, but lacks behavioral details (e.g., search behavior) that would be helpful despite the output schema.
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 0% schema description coverage (schema has no descriptions), the description must compensate. It adds meaning by specifying that 'search_text' is 'Text to search for in the file', clarifying the parameter's purpose. However, it does not detail constraints (e.g., length, special characters) or examples, leaving some gaps.
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 specific action ('Find lines that match provided text') and resource ('in the current file'), distinguishing it from siblings like 'find_function' (which likely searches for functions) and 'read' (which reads the entire file). The verb+resource combination is precise and unambiguous.
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 for text matching in a file, but does not explicitly state when to use this tool versus alternatives like 'find_function' (for functions) or 'skim' (purpose unclear). No exclusions or prerequisites are mentioned, leaving the agent to infer context from tool names alone.
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 and does well by disclosing key behavioral traits: it creates a file, automatically selects the first line for editing, and creates parent directories if missing. This covers mutation behavior and side effects, though it doesn't mention permissions, error handling, or rate limits, which are gaps for a tool with no annotations.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by important behavioral details, and ends with structured Args and Returns sections. Every sentence adds value without redundancy, 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.
Completeness4/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 (file creation with side effects), no annotations, and an output schema present, the description is fairly complete. It explains the action, behavioral traits, and parameter semantics, but could improve by addressing error cases or interaction with siblings. The output schema handles return values, so the description's focus on other aspects is appropriate.
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 description adds meaningful context for the single parameter 'filepath' by explaining it's the 'Path of the new file', which clarifies its purpose beyond the schema's basic type definition. With 0% schema description coverage and only one parameter, this compensation is effective, though it doesn't detail format constraints or examples.
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 the verb 'creates' and resource 'new file', making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'overwrite' or 'set_file', which might also involve file creation or modification, leaving room for ambiguity in tool selection.
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 for creating new files and automatically handling parent directories, but provides no explicit guidance on when to use this tool versus alternatives like 'overwrite' or 'set_file'. It mentions automatic post-creation actions (first line selection), which hints at context, but lacks clear when-to-use or when-not-to-use directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the tool reads lines and returns them in a specific dictionary format, which is useful. However, it lacks details on error handling, file state changes, or permissions needed, leaving behavioral gaps for a read operation.
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 appropriately sized and front-loaded with the core functionality in the first sentence. The Args and Returns sections are structured but slightly verbose; every sentence adds value, though it could be more streamlined.
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?
Given the tool's low complexity, no annotations, and an output schema present, the description is fairly complete. It explains the purpose, parameters, and return format adequately. However, it could improve by addressing error cases or interaction with sibling tools for better context.
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 schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'start' and 'end' are line numbers and are optional in the Args section, clarifying their role in selecting lines. However, it doesn't detail default behaviors or constraints beyond basic types.
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 specific action ('Read lines from the current file') and resource ('current file'), distinguishing it from siblings like 'skim' or 'select'. It precisely defines what the tool does without being vague or tautological.
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 for editing by mentioning 'easier to find the precise lines to select for editing', but does not explicitly state when to use this tool versus alternatives like 'skim' or 'find_line'. No exclusions or clear alternatives are provided, leaving usage context somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool's behavior: it finds function/method definitions using AST parsers and returns line numbers and ranges. However, it doesn't mention error handling (e.g., if file doesn't exist or function isn't found), performance characteristics, or whether it searches recursively in directories. It adds value beyond the minimal schema but lacks comprehensive behavioral details.
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 efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence earns its place: the first sentence defines the tool's core functionality, and the subsequent lines provide essential parameter and return value information without redundancy.
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?
Given the tool's moderate complexity (AST parsing across two languages), no annotations, and an output schema that likely defines the return dict structure, the description is reasonably complete. It covers what the tool does, the parameter meaning, and return format. However, it could better address error cases or language-specific quirks (e.g., JSX vs JS differences) for full completeness.
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 schema has 0% description coverage, so the description must compensate. It clearly explains the single parameter 'function_name' as 'Name of the function or method to find', which adds essential semantic meaning not present in the bare schema. However, it doesn't specify case-sensitivity, partial matching, or handling of nested methods (e.g., 'ClassName.method_name'), leaving some ambiguity.
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 specific action ('Find a function or method definition'), the target resources ('in a Python or JS/JSX file'), and the implementation method ('Uses AST parsers'). It distinguishes itself from siblings like 'find_line' (general line search) and 'skim' (likely file overview) by focusing specifically on function/method definitions with AST parsing.
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 by specifying 'Python or JS/JSX file' and 'function or method definition', suggesting it should be used when searching for function definitions in those file types. However, it doesn't explicitly state when NOT to use it or name alternatives like 'find_line' for non-function searches or 'skim' for file overviews.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. It discloses key behavioral traits: it's a read operation (implied by 'Read text'), truncates output based on `SKIM_MAX_LINES`, and returns a dict with specific keys. However, it doesn't mention permissions, error conditions, or how `SKIM_MAX_LINES` is defined (e.g., environment variable, default value), 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 highly concise and well-structured: the first sentence states the core action and constraint, and the second sentence clearly outlines the return format. Every sentence earns its place with no wasted words, making it easy to parse and front-loaded with essential information.
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?
Given the tool's low complexity (0 parameters, read-only operation) and the presence of an output schema (implied by 'Returns: dict'), the description is mostly complete. It covers purpose, behavior, and output structure. However, it lacks details on `SKIM_MAX_LINES` (e.g., source or default) and any prerequisites (e.g., needing a file set via 'set_file'), which would enhance completeness for 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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on behavior and output. A baseline of 4 is applied since no parameters exist, and the description adds value by explaining the tool's operation beyond the empty schema.
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's purpose with specific verbs ('Read text from the current file') and resource ('current file'), distinguishing it from siblings like 'read' (which presumably reads the entire file) by specifying truncation behavior. It explicitly mentions the truncation limit ('first `SKIM_MAX_LINES` lines'), making the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying it reads from 'the current file' (suggesting a file must already be selected/opened) and truncates output, which differentiates it from tools like 'read' (full file reading) or 'select' (line selection). However, it doesn't explicitly state when NOT to use it or name alternatives, missing full sibling differentiation.
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:

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

Score Badge

Copy to your README.md:

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

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/danielpodrazka/editor-mcp'

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