vs-token-safer

by JSungMin

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.1.2
Disambiguation5/5
Each tool has a clearly distinct purpose: find_files (file search), search_text (text/regex), find_references (symbol references), goto_definition (definitions), diagnostics (errors), hover (type info), document_symbols (outline), safe_delete (declaration removal), rename, replace_symbol_body, insert_symbol (editing), and detect_changes (diff impact). No confusing overlap.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern, predominantly in verb_noun form (find_files, search_text, find_references, replace_symbol_body, insert_symbol, detect_changes). Even safe_delete and document_symbols fit the pattern. No mixed conventions.
Tool Count5/5
12 tools is a well-scoped number for a code manipulation and analysis server. It covers navigation, search, diagnostics, and safe editing without being bloated or too sparse. Each tool earns its place.
Completeness4/5
The set covers core navigation, diagnostics, and safe editing operations (delete, rename, replace, insert). However, it lacks some common refactoring operations like moving symbols or changing signatures, which is a minor gap for comprehensive code manipulation.
Average 4/5 across 11 of 12 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 332 commits in the last 12 weeks
- Last stable release on July 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions the tool does not open a file, but does not disclose side effects, required permissions, or error behavior (e.g., when symbol not found). Very limited transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loading the core purpose. Every word adds value with no redundancy.
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?
With 5 parameters and no output schema, the description is far too brief. It does not explain what 'type/signature' means, how results are formatted, or what happens on errors. Incomplete for effective use.
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?
Schema description coverage is 60% (3/5 parameters described). The description does not add any parameter-specific meaning; it only restates that position is 0-based, which is already in the schema. No compensation for the two undocumented parameters (projectPath, backend).
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 it retrieves type/signature at a position (hover). It distinguishes itself from siblings by mentioning it returns only a few lines and does not open a file, but does not explicitly name alternatives.
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?
There is no guidance on when to use this tool versus alternatives like goto_definition or read_symbol. The description implies it is for quick lookup without opening a file, but no explicit conditions or exclusions.
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 exist, so the description carries full weight. It mentions resolving declaration, returning all refs in one call, and capping output at file:line. Does not disclose error handling, performance implications, or limitations (e.g., on large projects). Adequate but not thorough.
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?
Two sentences, packed with information but front-loaded. The first sentence is dense with multiple ideas; could be split for clarity. Nonetheless, no wasted words and all content is relevant.
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 11 parameters and no output schema, the description covers core functionality and provides a usage hint. However, it omits details on many parameters and does not fully explain return format beyond 'capped file:line'. Incomplete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 64%. The description adds meaning for 'symbol' (resolved via index) and 'detail'/'direction' (purpose). But several parameters (includeDeclaration, depth, projectPath, etc.) are not explained in the description, relying on schema. Baseline 3, with modest added value.
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?
Clearly states the tool finds semantic call sites of a symbol, distinguishing from grep. Mentions alternative modes (blast-radius, call hierarchy). However, does not explicitly differentiate from sibling tools like 'search_symbol' or 'goto_definition', leaving some ambiguity.
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?
Provides a clear usage recommendation ('Use before changing a function') and explains alternative modes (detail, direction). Lacks explicit when-not-to-use guidance or comparison to siblings, but the given context is helpful.
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 provided, so the description carries full burden. It discloses output format (capped, sorted, with count) and that empty output means clean. However, it does not mention side effects, rate limits, or auth requirements, leaving some behavioral aspects unclear.
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 concise, conveying purpose, format, and defaults in a single sentence. It could be structured more clearly (e.g., separate sentences for parameters), but overall it is not verbose.
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 no output schema, the description explains return values (format, sorted, count). It covers main parameters but leaves some (backend, maxResults) undocumented. Siblings are many, but the description sufficiently distinguishes the tool's purpose.
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?
Schema description coverage is 40% (2 of 5 parameters described). The description adds context for path and scope (defaults and interaction). But projectPath, backend, and maxResults are unexplained in both schema and description, failing to compensate for low coverage.
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 returns compiler/linter diagnostics in a specific format (file:line:col severity [code]: message), sorted by severity with a count. It distinguishes from sibling tools like symbol or search tools by specifying its role as a 'compact stand-in for raw build output'.
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 when to use (as a compact stand-in for raw build output) and explains default behavior and scope options. However, it does not explicitly state when not to use or provide alternatives among siblings.
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?
The description discloses key behavioral traits: capped file list, walk-bounded (skips node_modules/build, time-boxed). With no annotations provided, this adds significant transparency beyond the basic purpose. It does not cover all aspects like permissions or side effects, but the disclosed traits are valuable.
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 concise sentence that front-loads the core action and key behavioral constraints. Every part adds value, with no redundant or extraneous words.
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 has 3 parameters, no output schema, and no annotations, the description covers purpose, usage hint, and behavioral boundaries. However, it lacks details on return value format, error conditions, or permission requirements, leaving some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the `q` parameter by explaining it supports substring and glob patterns. It also hints at `maxResults` with 'capped file list'. However, `projectPath` is entirely undocumented, and schema coverage is low (33%). The description partially compensates but not fully.
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: finding files by name using substring or glob patterns. It also distinguishes itself by mentioning it replaces Bash `find -name` and describes its bounded behavior, making it distinct from sibling tools like search_text or concept_search.
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 provides some guidance by stating it replaces Bash `find -name`, implying usage in place of shell commands. However, it lacks explicit when-to-use vs. alternatives like search_text or concept_search, and does not mention when not to use the tool.
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?
The description discloses that no code bodies are sent and nothing is transmitted, implying privacy. However, it does not clarify required permissions, side effects, or prerequisites like git repository access. Given no annotations, some behavioral gaps remain.
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 concise, using dense symbols and keywords to pack information. It is front-loaded with the core purpose and key usage. Slightly cryptic but efficient for those familiar with git and impact analysis.
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?
With 6 parameters, no output schema, and no annotations, the description covers the core workflow and output format but leaves several parameters (depth, backend, maxResults, projectPath) unexplained. Sufficient for basic use, incomplete for full parameter understanding.
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?
Schema coverage is 50%; the description adds meaning for 'staged' and 'base' beyond the schema. Other params (backend, maxResults, projectPath) lack schema descriptions and are not explained in the tool description, so partial compensation.
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 reviews a diff by impact, performing git diff, identifying changed symbols, and assessing blast radius and risk. It distinguishes from siblings like find_references and diagnostics by focusing on impact analysis and risk levels.
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?
Explicitly suggests use before committing and explains the staged parameter for index vs working tree, as well as base ref. Lacks explicit when-not-to-use or alternatives, but the context is clear enough for appropriate selection.
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?
The description adds some behavioral context by noting the output is 'capped `file:line`', indicating a result limit and format. However, no annotations exist, and the description does not disclose error handling, permission requirements, or details about the cap (e.g., max results). This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and a note. Every part is essential, and key information is front-loaded. No wasted words.
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 7 parameters, no output schema, and no annotations, the description falls short of full completeness. It does not explain the return value structure beyond 'file:line', nor does it cover optional parameters like projectPath, backend, or maxResults. However, for a focused navigation tool, the core behavior is captured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'kind' parameter by listing its options and default value. Other parameters (path, line, character, projectPath, backend, maxResults) are not elaborated beyond their schema descriptions. Since schema coverage is 57%, the description partially compensates but leaves gaps for non-kind parameters.
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: 'Jump from a 0-based position to a definition (semantic)'. It distinguishes from sibling tool 'find_references' by explicitly stating 'For usages, use find_references'.
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 when-to-use context: navigation to definitions, type definitions, implementations, or declarations. It also gives a clear alternative for usages (find_references), guiding the agent on tool selection.
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?
Discloses preview mode by default, write when apply=true, and that it uses outline without read step. No annotations provided, so description carries burden well.
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?
Two sentences with key information front-loaded; every clause adds value without redundancy.
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?
No output schema, so description should explain return values or errors, but does not. Lacks details on preview output format and error handling for symbol resolution.
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?
Adds meaning for key parameters (symbol, text, position, apply) but does not describe path, line, projectPath, backend, maxResults beyond schema. Schema coverage 67% so moderate compensation.
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?
Clearly states 'Insert text next to a named declaration' with position option, and distinguishes from siblings like 'Read-then-Edit' and other modification tools.
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?
Explicitly says 'Use instead of Read-then-Edit to add a declaration' and notes preview default vs. apply=true, but does not list when to avoid using it.
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?
No annotations exist, so description fills gap. Discloses output is a capped list, cost advantage, and scope behavior. Does not mention error conditions or parameter effects beyond path/scope.
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?
Two efficient sentences. First sentence defines core purpose and output format; second adds usage tip and scope option. No fluff, front-loaded.
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?
With 5 parameters (0 required) and no output schema, description covers core behavior and directory scope. Missing documentation for three less critical parameters, but overall sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 40% (only path and scope have descriptions). Description adds meaning for path and scope (e.g., subtree behavior) but ignores projectPath, backend, and maxResults. Partially compensates but incomplete.
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?
Description explicitly states it outlines a file listing classes/functions/types in a capped 'kind name :line' format. It distinguishes itself from siblings like 'read_symbol' by highlighting it's cheaper for structure overview.
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?
Clearly states when to use (cheaper than reading full file) and explains scope='directory' behavior. Lacks explicit exclusions or alternatives but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses key behaviors: default preview mode showing affected file:line, and apply=true to write. It also clarifies semantic scope (every reference).
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?
Two sentences that are front-loaded with the core purpose and behavior. Every sentence adds essential information without redundancy.
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?
The description explains the main workflow (preview vs. apply) and scope but lacks output format details and does not cover optional parameters. No annotations or output schema exist, so more completeness would be beneficial, but core functionality is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 63% (5 of 8 parameters described in schema). The description adds the preview/apply behavior to the apply parameter but does not explain projectPath, backend, or maxResults. It refers to 0-based position, which matches schema descriptions of line and character.
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 renames a symbol at a 0-based position project-wide, emphasizing semantic rename (every reference) and distinguishing from a simple sed replacement.
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 explicitly recommends using this tool 'instead of editing call sites by hand,' providing a clear usage context. However, it does not mention when not to use or compare with sibling tools like replace_symbol_body or safe_delete.
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, the description discloses key behaviors: preview by default, apply=true writes in one call. Lacks details on error handling or side effects but covers the main behavioral traits.
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?
Two efficient sentences that front-load purpose and usage, with no wasted words.
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?
For a complex replace operation, description covers main behavior but lacks return value info and error handling. Undocumented params not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 63%; description adds meaning for key params (symbol, body, apply) but doesn't explain projectPath, backend, maxResults. Adequate for required params but incomplete overall.
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 it changes functions/classes/methods by naming them, and distinguishes itself from sibling tools like read_symbol and insert_symbol by positioning as a replacement for read-file + edit.
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?
Explicitly says 'USE INSTEAD OF Read-the-file + Edit' and explains preview vs apply behavior, giving clear context on when and how to use it.
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?
No annotations are provided, so the description carries the full burden. It discloses the output format as 'capped `file:line: line`' and mentions widening the search for docs/config text via the docs parameter. However, it lacks explicit statements about safety (read-only) or potential limitations like rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an arrow note. Every sentence adds value and is front-loaded with the core purpose. No fluff.
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 no output schema, the description partially covers return format ('capped file:line: line'). It covers key parameters and usage context but omits details on maxResults and projectPath. For a search tool with 6 parameters, it is fairly complete but not exhaustive.
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?
Schema coverage is 67%; the description adds value beyond the schema by explaining the 'docs' parameter behavior ('widen the sweep to docs/config text') and clarifying that 'path' searches one file and 'glob' filters basename. It does not cover projectPath or maxResults, but those are somewhat self-explanatory. The total value added is moderate.
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 performs raw text/regex search, specifies the resource (text like string literals, comments, config), and distinguishes it from sibling search_symbol. The verb 'search' and resource 'text' are explicit.
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 explicitly tells when to use this tool ('when you need text, not symbols') and when not to ('For code symbols prefer search_symbol'). It also mentions it replaces Bash grep, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description fully discloses key behaviors: it refuses deletion if the symbol is still referenced (listing references), allows override via force=true, and operates with a preview mode by default (apply=true writes to disk). This transparency helps the agent understand the tool's safety mechanisms.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, packing critical information into two sentences. It uses capitalization for emphasis and front-loads the key purpose ('Delete a named declaration') while efficiently conveying behavioral details.
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?
The description covers the main behavior and key parameters but lacks explanation of the return value (e.g., what the preview returns) and omits descriptions for three parameters (projectPath, backend, maxResults). While the essential safety features are well-documented, the overall completeness is hindered by these gaps, especially given the tool's complexity with 8 parameters.
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 covers 63% of parameters with descriptions. The description adds value by explaining the semantics of 'force' (overrides refusal) and 'apply' (writes to disk), which are not fully detailed in the schema. However, it does not address the remaining 37% (projectPath, backend, maxResults), 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 it deletes a named declaration, using the verb 'Delete' and specifying the resource. It also distinguishes itself from alternative actions like 'Edit-deleting' by emphasizing safety features, making the purpose unambiguous.
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 explicitly tells when to use this tool ('USE INSTEAD OF Edit-deleting it') and explains its behavior under different conditions (refuses if referenced, force overrides, preview vs. apply). This provides clear guidance on usage and when to apply force or apply modes.
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:

[![vs-token-safer MCP server](https://glama.ai/mcp/servers/JSungMin/vs-token-safer/badges/card.svg)](https://glama.ai/mcp/servers/JSungMin/vs-token-safer)

Score Badge

Copy to your README.md:

[![vs-token-safer MCP server](https://glama.ai/mcp/servers/JSungMin/vs-token-safer/badges/score.svg)](https://glama.ai/mcp/servers/JSungMin/vs-token-safer)

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/JSungMin/vs-token-safer'

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