Skip to main content
Glama
Sign In
nexus-mcp-ci

nexus-mcp-ci

by jaggernaut007
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Find a symbol

find_symbol
Read-onlyIdempotent

Retrieve full code, file locations, line ranges, callers, and callees for functions, classes, methods, or constants by name—pass multiple names or use fuzzy matching instead of file reads or grep.

Instructions

Look up functions, classes, methods or constants by name and get the whole code of each, with file, line range and direct callers and callees. Use it when you know the name ("show me create_order", "where is TokenBudget defined"), and in place of a file read or a grep for a definition. Pass several names in one call. A class longer than 2,000 characters gives an outline (its head and one line per method); ask for "Class.method" for a method's code. Other code longer than 6,000 characters is cut and marked (truncated). Set exact=false to match part of a name when you are unsure of the spelling. For every use of a name, use graph.

Input Schema

NameRequiredDescriptionDefault
exactNoTrue for exact match, False for fuzzy substring
symbol_nameYesOne name, or several with commas (e.g. 'create_server, TokenBudget, MAX_RETRIES')

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.1.0
    • removedInput schema / properties / name
      Removed value: -{
-  "description": "Symbol name (e.g. 'create_server', 'TokenBudget')",
-  "type": "string"
-}
    • addedInput schema / properties / symbol_name
      Added value: +{
+  "description": "One name, or several with commas (e.g. 'create_server, TokenBudget, MAX_RETRIES')",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "name"
-]New value: +[
+  "symbol_name"
+]
  2. First observedv1.0.4

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description instead discloses non-obvious behaviors: classes over 2,000 chars return an outline, other code over 6,000 chars is cut and marked `(truncated)`, and several names can be batched in one call. It doesn't mention ordering or how missing symbols are reported, which is a minor gap given an output schema exists.

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?

Front-loaded with the verb and the returned artifact, then usage examples, then caveats. Dense but nearly every clause carries information; the truncation thresholds are the only slightly over-specified part, though they change how the agent interprets output.

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

Completeness5/5

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

For a two-parameter read tool with a full output schema, the description covers purpose, alternatives, batching, naming patterns and output truncation. Nothing an agent needs in order to call it correctly is missing.

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 100% (both parameters documented), so the baseline is 3. The description adds real meaning on top: comma-separated multi-name batching, the "Class.method" addressing form for method bodies, and the intent behind exact=false (match part of a name when unsure of spelling).

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?

States a specific verb and resource (look up functions, classes, methods or constants by name) plus what comes back (code, file, line range, callers and callees). It explicitly separates itself from file reads/greps and points to `graph` for a different question, so an agent can distinguish it from siblings without opening the schema.

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?

Gives concrete when-to-use triggers ("show me create_order", "where is TokenBudget defined") and a when-not-to-use rule: use `graph` for every use of a name, and don't use a file read or grep for a definition. Alternatives are named explicitly.

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