Skip to main content
Glama
Sign In
vs-token-safer

vs-token-safer

by JSungMin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

search_symbol

Locate symbol declarations by name or substring using semantic index, returning file and line references without code bodies. Replaces grep for symbol search.

Instructions

Find a symbol DECLARATION (class/function/type/var) by name/substring — semantic index, not grep. → capped kind name @ file:line, no bodies. Use instead of grep/rg to locate a symbol.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "q": "<q>"
    },
    "name": "search_symbol"
  }
}

Input Schema

NameRequiredDescriptionDefault
qYesSymbol name or substring.
pathNoScope to a file/class (basename or path substring). An inherited symbol not declared there is reported tree-wide.
backendNo
maxResultsNo
projectPathNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.5
  2. Removedv1.1.2
  3. Changed1 schema field changedv0.42.21
    • addedInput schema / properties / path
      Added value: +{
+  "description": "Scope to a file/class (basename or path substring). An inherited symbol not declared there is reported tree-wide.",
+  "type": "string"
+}
  4. Changed4 schema fields changedv0.37.3
    • removedInput schema / properties / backend / description
      Removed value: -"clangd | roslyn | typescript | pyright (default: auto-detect from the root)."
    • removedInput schema / properties / maxResults / description
      Removed value: -"Cap on returned locations (default 60)."
    • removedInput schema / properties / projectPath / description
      Removed value: -"Project root (default: configured projectPath or cwd)."
    • changedInput schema / properties / q / description
      Previous value: -"Symbol name or substring to search for."New value: +"Symbol name or substring."
  5. First observed

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does a solid job: it discloses semantic indexing, capped results, the output format, and that bodies are not returned. It does not mention exact cap limits or backend behavior, but the core behavioral profile is clear.

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 two tight sentences with the main purpose front-loaded and an efficient arrow-style output spec. Every phrase earns its place with no filler.

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 definition provides the core usage rule, the output shape, and the distinction from grep, which is enough for basic invocation. However, with no annotations, no output schema, and several undocumented optional parameters, it is adequate but not fully complete.

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 only 40%, and the description mostly reinforces the meaning of q and vaguely gestures at cap behavior. Parameters like backend, maxResults, and projectPath remain unexplained, so the description does not compensate for the schema gaps.

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 states a specific verb and resource: find a symbol DECLARATION by name/substring. It also clarifies the semantic-index nature and distinguishes itself from grep-style search, though it does not explicitly name sibling 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?

It explicitly says to use this instead of grep/rg to locate a symbol, giving a clear substitution rule. It does not fully spell out when to prefer find_references or search_text, but the declaration-oriented wording implies the boundary.

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

Deploy Server

Other Tools