FullScopeSee more code. Get better answers.
A context optimization layer for LLMs that enables full-codebase reasoning without losing logic or requiring indexing.
FullScope compresses code structurally so LLMs can process significantly more context — without losing executable logic.
LLMs struggle with real-world codebases. You're forced into tradeoffs:
Read full files -- too many tokens
Use search/RAG -- lose global context
Use summaries -- lose accuracy
FullScope removes that tradeoff. It reduces token usage without rewriting or abstracting your code, allowing models to reason over entire files and larger portions of your project at once.
The result: better answers, not just smaller inputs.
Related MCP server: project-graph-mcp
Understand full modules instead of fragments
Trace logic across functions and files
Refactor with complete context
Debug with full visibility
Onboard faster to unfamiliar codebases
In practice, context mode lets models read ~2x more code per prompt. Skeleton mode enables ~5x for architecture review. Actual multiplier depends on file shape and comment density.
FullScope | RAG/Search | Summarization | |
Preserves executable logic | Yes | Partial | No |
Whole-file reasoning | Yes | No (fragments) | No (lossy) |
Zero risk to code | Yes (read-only, SHA-256 verified) | Yes | Yes |
Requires indexing | No | Yes | Sometimes |
Deterministic output | Yes | Varies | No |
What this is not: not a replacement for RAG or search. Not a code editing agent. Not a summarization tool. FullScope is a context amplifier -- it improves how LLMs reason, not how they retrieve or modify code.
Add to your MCP config:
{
"mcpServers": {
"fullscope": {
"command": "npx",
"args": ["-y", "fullscope"]
}
}
}Ask your agent:
Use fullscope_project to understand this repoPick any file from the project tree and:
Show me the skeleton of index.jsDrill into a function:
Expand fn:login from that fileFullScope gives models three levels of code visibility:
Mode | What the LLM sees | What's stripped |
Context | Full logic, original line numbers | Comments, docstrings, types, whitespace |
Skeleton | Structure only (signatures, imports, expand handles) | All function/class bodies |
Expand | One function's full logic | Everything else in the file |
The agent chooses its minification level per file, per call. Start with skeleton (cheapest), expand only what you need, use context for full logic review.
Raw read: 1 call, 1,060 tokens
FullScope flow: 2 calls, 431 tokens (59% saved)
Representative excerpt from Step 1 -- fullscope_skeleton (180 tokens):
import { db } from './db';
import { hash, verify } from './crypto';
import jwt from 'jsonwebtoken';
const ACCESS_TOKEN_EXPIRY = '15m';
const MAX_LOGIN_ATTEMPTS = 5;
export class AuthService extends EventEmitter { /* 319 lines -- expand: fn:AuthService */ }Step 2 -- fullscope_expand fn:login (251 tokens): returns the 85-line login method with comments stripped.
Same answer. 59% fewer tokens. 2 targeted calls instead of 1 bulk read.
Try it: npx fullscope --demo
Benchmarked on 30 files (30,830 lines) across 5 open-source projects and 16 bundled fixtures. Reproducible: npm run benchmark
No modifications were made to source files — all benchmarks run on unedited upstream code.
File | Source | Lang | Lines | Context | Skeleton |
applications.py | FastAPI | Python | 4,692 | 78% | 99% |
routing.py | FastAPI | Python | 4,957 | 68% | 94% |
defs.rs | Ripgrep | Rust | 7,780 | 4% | 47% |
walk.rs | Ripgrep | Rust | 2,495 | 51% | 30% |
controller_utils.go | Kubernetes | Go | 1,461 | 46% | 40% |
controller_ref_manager.go | Kubernetes | Go | 597 | 56% | 41% |
fluentd-gcp-configmap.yaml | Kubernetes | YAML | 466 | 0% | 0% |
response.js | Express | JS | 1,048 | 68% | 88% |
application.js | Express | JS | 632 | 99% | 82% |
item.py | python-projects | Python | 484 | 65% | 96% |
main.py (Chess) | python-projects | Python | 662 | 1% | 89% |
Selected to represent different languages, coding styles, and file types:
Express / FastAPI — heavily documented, high comment density (best case for context)
Kubernetes — production Go with moderate comments + real YAML config
Ripgrep — dense Rust systems code with doc comments (tests large files)
python-projects — varied beginner code (tests minimal-comment worst case)
Includes: JavaScript, TypeScript, Python, Rust, Go, Java, C#, JSON, YAML, TOML, Markdown, HTML, CSS, log files, and broken/malformed edge cases.
Scope | Files | Lines | Context | Skeleton |
External code (5 projects) | 14 | 28,063 | 44% | 64% |
Bundled fixtures (7 langs + docs) | 16 | 2,767 | 23% | 41% |
Combined | 30 | 30,830 | 42% | 62% |
Tested across code, config, documentation, and logs.
Task | Baseline | FullScope | Savings | Result |
Explain how login works | 1,060 tokens (1 call) | 431 tokens (2 calls) | 59% | Pass |
Find symbol usages | 3,155 tokens (3 calls) | 318 tokens (1 call) | 90% | Pass |
Orient in new repo | 1,740 tokens (3 calls) | 246 tokens (1 call) | 86% | Pass |
Inspect Python handler | 953 tokens (1 call) | 590 tokens (1 call) | 38% | Pass |
Verify line before edit | 1,060 tokens (1 call) | 66 tokens (1 call) | 94% | Pass |
Estimated 30-file session: 32,700 tokens saved ($0.49 at $15/1M).
Savings are minimal when files have few comments (Rust: 4-51%), are mostly data/config (JSON/YAML: 0%), or have no function bodies to collapse (C# property classes: 0% skeleton). In these cases, FullScope prioritizes fidelity over minification.
Token counts are estimated using a lightweight word-count heuristic, not a production tokenizer. Relative savings remain accurate.
// .mcp.json or ~/.claude/settings.json
{
"mcpServers": {
"fullscope": {
"command": "npx",
"args": ["-y", "fullscope"]
}
}
}Settings > Features > MCP > Add New MCP Server
Name: fullscope / Type: command / Command: npx -y fullscope
// .vscode/mcp.json
{
"servers": {
"fullscope": {
"command": "npx",
"args": ["-y", "fullscope"]
}
}
}// ~/.gemini/settings.json
{
"mcpServers": {
"fullscope": {
"command": "npx",
"args": ["-y", "fullscope"]
}
}
}fullscope_project -- Codebase overview in one call. Returns filtered directory tree (.gitignore-aware), compressed config files, git status, detected entry points with critical-path dependencies.
fullscope_skeleton -- Signatures-only view. Shows function/class signatures with bodies replaced by expand handles. Detects standalone functions, class methods, and property-assigned functions (e.g. const handler = () => {}). Includes IMPORTS and EXPORTS summary.
fullscope_expand -- Per-function drill-down. Takes an expand handle from skeleton output (e.g. fn:login or fn:AuthService.login for class methods). Supports multi-line signatures. Returns just that function body with context-level compression.
fullscope_context -- Compressed full-file read. Strips comments, docstrings, types, whitespace. Preserves all logic with original line numbers and virtual markers showing where content was stripped. Supports mode: "schema" for JSON files (keys+types only) and diff: true for compact re-read diffs.
fullscope_batch_context -- Read multiple files in one call. Supports intent parameter (preserves lines matching intent keywords), token budgeting (auto-downshifts to skeleton), cross-file import dedup, and dependency-ordered output.
fullscope_search -- Compressed grep via ripgrep. Filters results through language recipes. Path compaction strips the project root.
fullscope_usages -- Symbol usage finder. Searches for per-language import patterns and call sites. Results grouped by file, imports distinguished from usages.
fullscope_verify_line -- Confirms raw file content at a given line number. Optionally accepts expected content for explicit match verification before editing.
fullscope_stats -- Session savings tracker. Shows files compressed, tokens saved, estimated cost savings, and context-rot warnings.
FullScope is read-only by design. It cannot corrupt your code because it never opens a file for writing.
Never modifies, patches, or rewrites source files
Never executes code or sends data externally
If minification fails, raw content is returned unchanged
Search uses argument arrays, not shell interpolation (injection-safe)
Verified: 0 byte-level file changes across 203 operations on 34 files, confirmed by SHA-256 hashing before and after every operation. See docs/INTEGRITY.md.
Every compressed output includes:
COMPRESSED VIEW -- do not use these line numbers for editing. Read the raw file before applying changes.
Editing a file -- use the built-in read tool (exact content needed for search/replace)
Exact formatting matters -- comments and whitespace are stripped
You need type annotations -- TypeScript types are removed in skeleton mode
FullScope is for reading and understanding, not editing.
Tier 1 (recipe + skeleton): JavaScript, TypeScript, Python, Rust, Go, Java, C#, C/C++
Tier 2 (recipe only): Ruby, PHP, Swift, Kotlin, Scala, HCL/Terraform
Tier 3 (docs + data): Markdown, JSON (compact + schema modes), YAML, TOML, HTML, CSS, XML, config files, log files (with line dedup)
Node.js 18+ (developed and tested on v24)
ripgrep (rg) recommended for search/usages (falls back to grep)
Python 3 optional -- improves Python skeletonization (regex fallback available)
esbuild optional -- improves TypeScript type-stripping (installed as optional dependency)
Compressed output is for reading, not editing. Always use raw reads before making changes.
Skeletonization is heuristic. C-family languages use brace-depth counting, which can break on complex macros or #ifdef nesting. Property-assigned functions and class methods are detected via pattern matching. Tree-sitter support is planned.
Intent filtering is keyword-based, not semantic ranking.
Diff cache is session-local (in-memory only, opt-in via diff: true).
Savings vary by code style. Comment-heavy code (FastAPI: 78%) saves far more than minimal-comment code (Rust: 8-13%).
Skeleton savings depend on structure. Files without functions (data/config) see minimal benefit.
Line-number recovery is heuristic. Text matching after compression is verified for common patterns but could mis-anchor on files with many repeated identical lines. Use fullscope_verify_line to confirm before editing.
npm test # 271 tests across 17 files
npm run benchmark # File + task benchmarks across 30 files
npm run task-benchmark # 5 real tasks, all passing, avg 76% savings
npm run verify-integrity # SHA-256 hash verification (34 files, 203 ops)
npx fullscope --demo # Live demo: skeleton -> expand -> 59% savings on the bundled auth fixtureAll results committed to data/ (benchmarks.json, task-benchmark.json, integrity-results.json).
Full documentation:
docs/INTEGRITY.md -- integrity proof with actual SHA-256 hashes
docs/TEST_MATRIX.md -- complete test coverage matrix
examples/auth-service-demo.md -- before/after task comparison
SECURITY.md -- design guarantees
CHANGELOG.md -- v0.1.1 release notes
npm install
npm test
npm run benchmark
npm run verify-integrityBuilt by Adi Levinshtein.
If you use this in a product, attribution is appreciated.
MIT
Read multiple files in one call, each minified. Saves tool-call overhead. Supports: (1) intent parameter — tell the tool WHY you're reading these files and it biases minification to preserve relevant content; (2) token budgeting — files auto-downshift from context to skeleton using information density; (3) cross-file import dedup; (4) dependency-ordered output (leaf deps first as skeleton, importers after with full context).
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | Array of files to read | |
| intent | No | Why you're reading these files (e.g. "understand the authentication flow"). Biases compression to preserve relevant content. | |
| max_total_tokens | No | Optional token budget — files auto-downshift to skeleton based on information density |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses key behaviors: minification, intent-based compression, token budgeting, import dedup, and dependency ordering. However, it does not mention error handling, caching, or output format, though the tool is clearly read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, front-loading the main purpose and listing features with numbered points. Each sentence adds value, though it could be slightly more terse (e.g., removing the introductory intro).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and three parameters, the description explains the tool's features well but fails to describe the output format (e.g., minified content structure, skeleton representation, file paths). This gap leaves agents guessing the response structure for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds meaning beyond the schema: it explains how the 'intent' parameter biases compression, how 'max_total_tokens' enables token budgeting, and that 'priority' in files ensures full context for high-priority files. This context helps agents use the parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'multiple files' with the key differentiator 'in one call, each minified.' It distinguishes from siblings like fullscope_context (likely single file) and fullscope_skeleton by emphasizing batch reading and overhead savings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case—reading multiple files to save overhead—but does not explicitly state when to use this tool versus siblings (e.g., fullscope_context for single files, fullscope_skeleton for outlines). No 'when-not-to-use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compressed file read for CONTEXT ONLY — strips comments, docstrings, types, and whitespace. Typical savings: 10-50% depending on comment density (up to 80% on heavily documented code, as low as 8% on minimal-comment code). Shows virtual line markers where content was stripped. NEVER use for files you plan to edit — comments and formatting are permanently removed from output. Use the built-in Read tool when you need to Edit a file.
| Name | Required | Description | Default |
|---|---|---|---|
| diff | No | Enable diff mode: if file was read before and changed slightly, return a compact diff instead of full re-read | |
| mode | No | For JSON files: "schema" returns keys+types only (no values), "compact" is default | |
| limit | No | Number of lines to read (optional) | |
| offset | No | Start line number (1-based, optional) | |
| file_path | Yes | Absolute path to the file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that comments, docstrings, types, and whitespace are permanently stripped, mentions virtual line markers, and provides compression savings examples. This is thorough behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by savings, a warning, and an alternative. It is concise but covers all necessary points without fluff. Slightly longer than strictly necessary due to saving examples, but still well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage guidelines, and behavioral transparency. With 5 parameters and no output schema or annotations, it provides sufficient context for usage. It does not explain standard error handling (e.g., missing file), but that is acceptable as it is likely handled externally.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 5 parameters have descriptions in the schema). The description does not add additional parameter-specific meaning beyond what the schema provides. Baseline 3 is appropriate since the schema already defines parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('compressed file read for CONTEXT ONLY') and resource ('file'), and distinguishes the tool from the built-in Read tool by specifying it strips comments, docstrings, types, and whitespace. It explicitly warns against using it for editing, providing a clear alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when not to use the tool ('NEVER use for files you plan to edit') and provides the alternative ('Use the built-in Read tool when you need to Edit a file'). It also gives typical compression savings to help decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drill into a specific function from a fullscope_skeleton output. Takes a file path + expand handle (e.g. "fn:login" from the skeleton placeholder). Returns just that function body with context-level compression (comments stripped, logic preserved). Use this to progressively disclose detail: start with fullscope_skeleton (cheapest), then fullscope_expand only for functions you care about.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | Expand handle from skeleton output (e.g. "fn:login") | |
| file_path | Yes | Absolute path to the file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that output is 'just that function body with context-level compression (comments stripped, logic preserved)', and mentions input format. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then details, then usage guidance. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 params and no output schema, description is complete: explains input origin, output transformation, and usage pattern. No output schema but description covers return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description adds meaning beyond schema by explaining handle comes from skeleton output and file_path is absolute path, and provides example format. Baseline 3 increased due to added context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool drills into a specific function from a fullscope_skeleton output, specifying verb 'drill into', resource 'specific function', and source. It distinguishes from siblings by explaining the progressive disclosure pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use: 'Use this to progressively disclose detail: start with fullscope_skeleton (cheapest), then fullscope_expand only for functions you care about.' This contrasts with fullscope_skeleton but does not explicitly mention when not to use or other exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compressed codebase orientation — returns filtered directory tree, key config files (package.json/Cargo.toml/etc compressed), git status, and detected entry points with their critical-path dependencies. Use this as the first call when exploring a new codebase.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Project root directory (defaults to cwd) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes what the tool returns but does not explicitly state that it is read-only, non-destructive, or any behavioral traits like authentication or rate limits. The description is adequate but lacks explicit disclosure of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences—first detailing outputs, second giving usage advice. No wasted words; information is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter, no output schema, and no annotations, the description covers essential information: what it returns and when to use it. It could mention performance or read-only nature, but is sufficiently complete for an orientation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'path' described as 'Project root directory (defaults to cwd)'. The description adds little beyond the schema; it does not elaborate on format or constraints. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'compressed codebase orientation' with specific outputs: filtered directory tree, config files, git status, entry points with dependencies. It differentiates itself from siblings by positioning itself as the first call when exploring a new codebase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use as the first call when exploring a new codebase, providing clear context. While it doesn't detail when not to use or list alternatives, the guidance is sufficient given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search files with compressed results — runs ripgrep and filters output through fullscope to save tokens. Use instead of Grep/Bash for exploratory searches where you need to scan many results. For precise searches where you need exact line content, use the built-in Grep tool.
| Name | Required | Description | Default |
|---|---|---|---|
| glob | No | File pattern filter (e.g. "*.ts", "*.py") | |
| path | No | Directory or file to search in (defaults to cwd) | |
| pattern | Yes | Regex pattern to search for | |
| max_results | No | Max lines to return (default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'compressed results' and 'saves tokens', indicating some behavioral trait, but without annotations, it does not fully disclose the output format, loss of information, or any side effects. More detail would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with three sentences that efficiently convey purpose and usage guidelines without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain the output structure of compressed results. The current description leaves ambiguity about what the tool returns, making it somewhat incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description does not provide additional details beyond the schema, so it meets the baseline but adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches files with compressed results, specifying it runs ripgrep and filters through fullscope to save tokens. It distinguishes itself from the built-in Grep tool, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using this tool for exploratory searches where many results need scanning, and advises using the built-in Grep tool for precise searches requiring exact line content. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ultra-compressed file read showing ONLY function/class/method signatures with IMPORTS and EXPORTS summary — all implementation bodies are replaced with expand handles. Strong on function-heavy code (80-99% savings), weaker on flat data/config files. Use when you need to understand a module API surface without reading implementation details. NEVER use for files you plan to edit. For implementation details, use fullscope_context. For editing, use the built-in Read tool.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses compression behavior, savings range, and weakness on flat files. Does not mention non-read actions (none exist), so transparency is high.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each adding value: tool function, strengths, usage guidance, alternatives. No fluff, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, description compensates by explaining return format (signatures only, expand handles) and usage context. Could mention error handling but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter file_path has 100% schema description coverage ('Absolute path to the file'). Description adds no extra meaning beyond schema, meeting baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: showing only function/class/method signatures with imports/exports, replacing implementation with expand handles. It also contrasts with siblings like fullscope_context and Read tool, establishing distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-use ('understand a module API surface') and when-not ('NEVER use for files you plan to edit'), plus direct alternatives (fullscope_context for details, Read for editing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show session savings: total files compressed, tokens saved, estimated cost savings, and context-rot warnings for files read too many times.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states 'Show', implying a read-only operation with no side effects, and lists the data returned. However, it does not explicitly confirm idempotency or state that no modifications occur, leaving slight room for ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and lists the specific data items. Every part is relevant and there is no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description fully covers what the tool returns by enumerating the four components of the session savings. It is complete enough for an agent to understand the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since there are no parameters (0 params, schema coverage 100%), the baseline is 4. The description adds no parameter information because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows session savings with specific metrics: total files compressed, tokens saved, estimated cost savings, and context-rot warnings. It uses a specific verb 'Show' and resource 'session savings', distinguishing it from sibling tools that likely perform other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing session statistics but does not provide explicit guidance on when to use this tool versus siblings, nor does it mention any preconditions or scenarios where the tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find where a symbol (function, class, variable) is imported or referenced across the project. Returns results grouped by file. Complements fullscope_skeleton — skeleton shows what a file provides, usages shows where those exports are consumed. Best for: debugging "who calls this?", understanding dependencies.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Directory to search in (defaults to cwd) | |
| symbol | Yes | Symbol name to find usages of | |
| max_results | No | Max matches to return (default 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It states that results are grouped by file and that it searches across the project, but doesn't mention performance, side effects, or any restrictions. It is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: action, grouping detail, contrast, use case. No wasted words, information is front-loaded and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description states return format (grouped by file). It doesn't detail pagination or result shape, but given the tool's simplicity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no parameter-specific details beyond what schema provides, though it does mention grouping behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Find where a symbol is imported or referenced across the project', with specific verb and resource, clearly differentiating from sibling tool fullscope_skeleton.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Best for: debugging who calls this? understanding dependencies' and explicitly contrasts with fullscope_skeleton, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a line number from a compressed view against the raw file. Since compressed output preserves original line numbers via virtual markers, this confirms the line content matches. Returns the raw line with ±5 lines of context. Optionally pass expected_content to verify the match. Use before editing to confirm the exact location.
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | Line number from the compressed view | |
| file_path | Yes | Path to the file | |
| expected_content | No | Optional snippet expected at this line — verifies the match |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It explains that compressed output preserves original line numbers via virtual markers, confirms content matches, and returns raw line with ±5 lines context. While this is good, it could also state that the tool is read-only and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: purpose, behavioral details, and usage guidance. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool’s simplicity (3 params, no output schema), the description fully covers what the tool does, how it works, and when to use it. It explains return context (±5 lines) and optional verification. No gaps or missing info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with param descriptions. The description adds value by explaining the relationship between compressed view and raw file, the ±5 lines context, and the optional expected_content parameter's role in verifying the match. This enhances understanding beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Verify a line number from a compressed view against the raw file.' It specifies the action (verify), resource (line number from compressed view vs raw file), and distinguishes from sibling tools like fullscope_context or fullscope_expand by focusing on confirmation and context retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'Use before editing to confirm the exact location,' providing clear context for when to use the tool. However, it does not explicitly mention when not to use or name alternatives among siblings, leaving slight room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1fullscope_batch_contextfullscope_contextfullscope_expandfullscope_projectfullscope_searchfullscope_skeletonfullscope_statsfullscope_usagesfullscope_verify_lineEach tool serves a distinct purpose: compressed context reading, skeleton signatures, drill-down expansion, batch reading, project overview, search, stats, symbol usages, and line verification. No overlap in functionality.
All tools follow the 'fullscope_' prefix pattern with descriptive verb or noun after it (e.g., context, skeleton, expand). The naming is consistent and predictable.
With 9 tools, the server covers all necessary operations for compressed codebase exploration without being excessive. Each tool justifies its existence.
The set covers the full workflow: project orientation, search, various compression levels, batch reading, drill-down, symbol usages, line verification, and session stats. No obvious gaps for its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/justguy/FullScope-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
