Skip to main content
Glama
Sign In
atlas-brief-mcp

atlas-brief-mcp

by drproof
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

atlas_code_find

Read-onlyIdempotent

Locate function or class definitions across a codebase by symbol and return file, line, and signature; optionally scan call sites to verify whether the symbol is used.

Instructions

Locate function or class definitions across the codebase (file, line, signature) and optionally inspect call sites.

Use this tool BEFORE reading source files to find where a symbol lives (~30 tokens per signature vs.
thousands of tokens for a full file) or set `usage=True` to check if a symbol is actually called before
marking a task done. Supports GDScript (`.gd`/`.tscn`), Python, TypeScript/JavaScript, Rust, C#, Go,
Java, Kotlin, and Swift.

Behavior & Output:
- Read-only static scan of project source files; ignores build directories and `.atlas/`.
- Returns a formatted summary of matching definitions (`path:line — signature`) and, when `usage=True`,
  the caller/reference count and file:line call sites for each symbol.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of matching symbol definitions to return (1-100, default 10).
usageNoIf true, also scan the repository for call sites and references to each matched symbol (including Godot `.tscn` signal bindings) to verify whether the symbol is wired up (default false).
symbolYesFunction, method, or class name (or substring) to search for across the codebase (e.g. 'apply_damage' or 'TurnManager'). Does not match local variables.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.1
    • addedInput schema / properties / limit / description
      Added value: +"Maximum number of matching symbol definitions to return (1-100, default 10)."
    • addedInput schema / properties / limit / maximum
      Added value: +100
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • addedInput schema / properties / symbol / description
      Added value: +"Function, method, or class name (or substring) to search for across the codebase (e.g. 'apply_damage' or 'TurnManager'). Does not match local variables."
    • addedInput schema / properties / symbol / minLength
      Added value: +1
    • addedInput schema / properties / usage / description
      Added value: +"If true, also scan the repository for call sites and references to each matched symbol (including Godot `.tscn` signal bindings) to verify whether the symbol is wired up (default false)."
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real value on top: static scan scope, exclusion of build directories and .atlas/, supported languages, and the shape of returned results. It stops short of noting limits on accuracy or behavior for unresolved/dynamic symbols.

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 purpose in the first line, then usage rationale, then a labelled 'Behavior & Output' block. Slightly verbose in the token-cost aside, but every section carries information an agent needs.

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?

Covers purpose, when to use, language support, scan exclusions, and output format, and an output schema exists for return details. Nothing material is missing for a read-only lookup tool with three well-documented 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?

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining what usage=True actually does (call-site/reference scanning, including Godot .tscn signal bindings) and by justifying its purpose in the workflow. The limit parameter is left entirely to the 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?

States a specific verb and resource ('Locate function or class definitions across the codebase') plus the returned fields (file, line, signature) and an optional mode. This clearly separates it from siblings like atlas_read (file contents) and atlas_search (text search).

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?

Gives explicit when-to-use guidance: call it BEFORE reading source files, with a token-cost rationale, and set usage=True to verify call sites before marking a task done. It never names a specific sibling tool as the alternative (e.g. atlas_search or atlas_read), so routing is implied rather than stated.

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