mcp-agent-opt

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
With 9 tools, the server covers all necessary operations for compressed codebase exploration without being excessive. Each tool justifies its existence.
Completeness5/5
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.
Average 4.3/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
Add a glama.json file to provide metadata about your server.
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

Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
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: '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.
Usage Guidelines4/5
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.

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:

[![FullScope-MCP MCP server](https://glama.ai/mcp/servers/justguy/FullScope-MCP/badges/card.svg)](https://glama.ai/mcp/servers/justguy/FullScope-MCP)

Score Badge

Copy to your README.md:

[![FullScope-MCP MCP server](https://glama.ai/mcp/servers/justguy/FullScope-MCP/badges/score.svg)](https://glama.ai/mcp/servers/justguy/FullScope-MCP)

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/justguy/FullScope-MCP'

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