Provides code analysis and context for Dart projects, enabling AI agents to understand project structure, symbols, relationships, and change impact.
Provides code analysis and context for Flutter projects, enabling AI agents to understand project structure, symbols, relationships, and change impact.
Provides code analysis and context for JavaScript projects, enabling AI agents to understand project structure, symbols, relationships, and change impact.
Provides code analysis and context for Kotlin projects, enabling AI agents to understand project structure, symbols, relationships, and change impact.
Provides code analysis and context for Node.js projects, enabling AI agents to understand project structure, symbols, relationships, and change impact.
Provides code analysis and context for PHP projects, enabling AI agents to understand project structure, symbols, relationships, and change impact.
Provides code analysis and context for Python projects, enabling AI agents to understand project structure, symbols, relationships, and change impact.
Provides code analysis and context for Ruby projects, enabling AI agents to understand project structure, symbols, relationships, and change impact.
Provides code analysis and context for Rust projects, enabling AI agents to understand project structure, symbols, relationships, and change impact.
Provides code analysis and context for TypeScript projects, enabling AI agents to understand project structure, symbols, relationships, and change impact.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Blindspot MCP Analyze the impact of changing the User class in models/user.py."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Blindspot is a local, general-purpose context engine for AI coding agents.
It exists for one job:
help the agent understand a project
help the agent understand symbols and relationships
help the agent estimate change impact before editing
do this across different languages and project layouts
Blindspot is intentionally small. It is not trying to be a deployment system, policy engine, rollout manager, or autonomous edit platform.
Most agents can edit files, search text, and run commands. What they usually lack is a compact, reusable understanding layer for:
project structure
symbol ownership
callers and references
inheritance and composition
likely blast radius of a change
That is the gap Blindspot fills.
Paid context engines already proved this model is useful. Blindspot is the local and reusable alternative.
Related MCP server: Headless Codebase Indexer
Small MCP surface
Works across languages and frameworks
Gives structured context instead of file dumps
Helps any agent write better code with fewer blind edits
Stays useful even when framework-specific intelligence is missing
Blindspot keeps one public API and improves the engine underneath it.
Strong support: Python, PHP, JavaScript, TypeScript, Go
Solid project-structure and syntax-aware support: Dart / Flutter, React Native, Node.js
Additional generic support: Java, Kotlin, C#, Ruby, Rust, mixed repos
The contract does not change per language. get_context(...) stays the same; only the quality of the internal enrichment improves.
Blindspot now exposes only the core context-engine surface:
set_project_path: call once to bind Blindspot to the repo
get_project_snapshot: one-shot repo overview at session start
get_context: main entrypoint for file, symbol, relationship, and impact context
get_symbol_body: exact symbol metadata or bounded source excerpt
get_edit_region: small numbered excerpt around a symbol or line range
search_code: fallback text search when structured context is not enough
find_files: locate candidate files before drilling into one with get_context
refresh_index: rebuild the shallow file index if discovery gets stale
build_deep_index: rebuild the deep symbol index for richer relationship analysis
Call set_project_path(...)
Call get_project_snapshot() once at the start of a session
Before any important edit, call get_context(target=..., intent="before_edit", symbol=...)
If exact source is needed, call get_symbol_body(...) or get_edit_region(...)
If the returned context is still insufficient, use search_code(...)
Agents should default to get_context.
Use get_project_snapshot for orientation
use get_context for understanding and edit planning
use get_symbol_body for one symbol
use get_edit_region for a tight excerpt
use find_files to locate candidates
use search_code only as fallback
use index rebuild tools only when index data is missing or stale
The agent should not decide between 40 different analysis tools.
Instead, it should call one entrypoint and receive a normalized context envelope:
project
target
overview
file_context
symbol_context
relationship_context
impact_context
direct_callers
indirect_dependents
blast_radius
risk_reasons
safe_edit_hints
related_files
related_file_reasons
missing_context
confidence
confidence_details
edit_plan
suggested_next_steps
That is what get_context(...) returns.
get_context(...) supports these intents:
project
file
symbol
before_edit
impact
This keeps the public API small while still covering the main agent workflows.
get_context(...) also accepts change_type:
modify
rename
delete
signature_change
contract_change
Use a stronger change_type when you want Blindspot to plan a coordinated refactor instead of a local edit.
pip install blindspot-mcpAdd this to ~/.claude/settings.json:
{
"mcpServers": {
"blindspot": {
"command": "blindspot-mcp",
"args": ["--project-path", "/path/to/your/project"]
}
}
}Add this to .cursor/mcp.json:
{
"mcpServers": {
"blindspot": {
"command": "blindspot-mcp",
"args": ["--project-path", "."]
}
}
}Developer: Change the User status behavior
Agent:
1. get_project_snapshot()
2. get_context(target="app/models/user.py", intent="before_edit", symbol="is_active")
3. get_symbol_body("app/models/user.py", "is_active")
4. edit with full awareness of related files and likely impacta code editor
a release gate system
a deployment orchestrator
a policy approval workflow
a giant framework tool catalog
Those concerns make the product noisier and make agents choose tools instead of understanding code.
Blindspot runs locally and analyzes the codebase on your machine.
Blindspot should become:
a stable context layer any AI agent can use
easy to plug into different editors and agent runtimes
reliable across Python, PHP, TypeScript, JavaScript, Go, Java, Ruby, Rust, C#, and mixed repos
reliable across Dart / Flutter, React Native, Node.js, and mixed monorepos
useful even in plain projects with no heavy framework detection
The standard for success is simple:
fewer blind edits
better relationship awareness
better change impact awareness
better code written by the agent
Run the core test suite:
python3 -m unittest tests.test_context_engine_service -vRun the lightweight context evaluation harness:
.venv/bin/python evals/run_context_eval.pyBuild the deep symbol index required for rich relationship and impact analysis.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as whether the tool is destructive, safe, or incremental. For a build operation, details like impact on existing index or required permissions are missing.
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, front-loaded sentence that directly states the tool's purpose. No unnecessary words or repetitions.
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 simplicity of the tool (no parameters, has output schema), the description is somewhat complete but lacks comparison with the sibling 'refresh_index' and does not explain the output or side effects. It is minimally adequate.
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?
The input schema has no parameters, so schema coverage is 100%. The description does not need to add parameter details, but it could mention if the tool has implicit configuration. Baseline score of 4 is appropriate for a zero-parameter tool.
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 ('Build the deep symbol index') and its purpose ('required for rich relationship and impact analysis'). However, it does not distinguish itself from the sibling tool 'refresh_index', which likely has a similar function.
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?
No guidance is provided on when to use this tool versus alternatives like 'refresh_index'. The description lacks context for appropriate usage scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate likely files by glob pattern, then use get_context on the best candidate.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It says 'locate likely files' but does not clarify whether results are multiple or single, ordering, or whether hidden files are included.
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?
Single sentence, front-loaded, no wasted words. Efficiently conveys purpose and suggests next action.
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 simple parameter and existence of output schema, the description is adequate but could explain how to select the best candidate or what constitutes a match.
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 0%, so description adds value by explaining the pattern parameter as a glob pattern. However, it lacks specifics on glob syntax or examples.
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 locates files by glob pattern and suggests using get_context on the best candidate. It distinguishes itself from sibling tools like search_code.
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?
No explicit guidance on when to use this tool vs alternatives like search_code or build_deep_index. The description only mentions a next step but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Primary tool. Returns normalized file, symbol, relationship, and impact context before editing.
Pass owner (for example the enclosing class) when a symbol name is
ambiguous within a file, so the engine can disambiguate identically
named methods such as User.save vs Order.save.
Pass query as a free-text description (e.g. "pricing quote total")
when you do not know the exact file or symbol. The engine runs a BM25
search over the indexed symbols, resolves target/symbol/owner from
the top match, and echoes the inference under query_resolution.
If target points to a previously-saved detail file under
.blindspot/output/*.json, the stored payload is returned verbatim
so oversized responses never strand the caller.
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | ||
| intent | No | before_edit | |
| symbol | No | ||
| include_source | No | ||
| max_related | No | ||
| change_type | No | modify | |
| owner | No | ||
| query | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses behaviors like BM25 search for queries, returning stored payload from saved files, and normalizing context. It does not explicitly confirm it is read-only, but the nature of returning context implies no 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?
The description is well-structured with paragraphs for different parameter usage and front-loads the main purpose. It is informative but could be slightly more concise; however, 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 8 parameters, no annotations, and having an output schema, the description covers the main functionality and two key parameter cases. It explains the primary use and special features well, though not all parameters are individually described. Overall, it is adequate for the tool's complexity.
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 0%, so the description must compensate. It adds meaning for `owner` and `query` by explaining their use cases, and mentions that `target` can point to a saved file. However, other parameters like `intent`, `include_source`, `max_related`, and `change_type` are not elaborated beyond their names.
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: "Primary tool. Returns normalized file, symbol, relationship, and impact context before editing." It uses a specific verb (returns) and resource (context), and distinguishes itself from siblings by being the primary tool for context retrieval before editing.
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 provides explicit guidance on when to use the `owner` and `query` parameters, such as "Pass ``owner`` (for example the enclosing class) when a symbol name is ambiguous" and "Pass ``query`` as a free-text description when you do not know the exact file or symbol." It does not explicitly state when not to use the tool, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a tight numbered excerpt around a symbol or line range for precise edits.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| symbol | No | ||
| start_line | No | ||
| end_line | No | ||
| context_lines | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits such as side effects, permissions, or rate limits. It only states the output, leaving behavioral assumptions unaddressed.
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 single-sentence description is concise and front-loaded with the core action. However, it could be slightly more structured by separating purpose and behavior.
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 5 parameters and an output schema, the description is too minimal. It does not explain how context_lines works, what 'numbered excerpt' means precisely, or how symbol and line range options interact.
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 0%, yet the description only mentions 'symbol or line range' without explaining parameters like context_lines, file_path, or how symbol and line range interact. The default for context_lines is 5 but not explained.
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 numbered excerpt around a symbol or line range, with a specific verb and resource. It distinguishes from siblings like get_symbol_body and get_context which return broader or different content.
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?
No guidance on when to use this tool versus alternatives. Sibling tools exist (e.g., get_symbol_body, get_context) but description provides no conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Session-start overview of the repo. Use this once before drilling into a specific edit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'overview' without disclosing what data is returned (e.g., file structure, statistics) or behavioral traits like speed or side effects. Output schema exists but description adds no behavioral context.
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 key term 'Session-start overview'. Every sentence provides value with no 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?
For a 0-parameter tool with an output schema, the description is mostly complete. It covers usage context but could specify the nature of the overview (e.g., files, configuration). Still sufficient for basic guidance.
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?
No parameters present, so baseline is 4. Description does not need to add parameter details; schema coverage is 100% vacuously.
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 clearly states it provides a 'session-start overview of the repo', implying a verb and resource. It distinguishes from siblings by positioning itself as the initial step before drilling into specific edits, but does not explicitly name alternatives.
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 says 'Use this once before drilling into a specific edit', giving clear when-to-use guidance. However, it lacks when-not-to-use or explicit alternative tool comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one symbol's metadata or bounded source. Use this when exact symbol code is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| symbol_name | Yes | ||
| compact | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the return type but omits side effects, error handling, output format details, and the effect of the 'compact' parameter. The boundary between 'metadata' and 'bounded source' is undefined.
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 concise sentences: the first states purpose, the second adds usage context. Every word is necessary, with no redundancy or fluff.
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 moderate complexity (3 params, output schema exists), the description covers the high-level purpose but lacks parameter details and behavioral nuance. It is minimally adequate but leaves gaps for an AI agent.
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 0%, and the description does not explain any parameters. While 'file_path' and 'symbol_name' are intuitive, 'compact' is ambiguous. The description adds no value over the raw parameter names.
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 uses a specific verb ('Return') and resource ('one symbol's metadata or bounded source'), clearly defining the tool's function. It distinguishes from siblings like 'search_code' by implying exact symbol lookup.
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 provides clear context ('Use this when exact symbol code is needed'), indicating the tool is for precise symbol retrieval. However, it does not explicitly mention when to avoid it or name alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rebuild the shallow file index when file discovery looks stale.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a rebuild operation (implying mutation) but lacks details on permissions, side effects, or performance impact. It is minimally adequate.
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 sentence with no wasted words, front-loaded with the action verb 'rebuild'. It is concise and easily parsable.
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 0 parameters and an output schema, the description is mostly complete. It could benefit from noting whether it is a safe operation or its effect on performance, but it is adequate for a simple trigger.
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?
The tool has zero parameters, and the schema coverage is 100% trivial. Per the guidelines, 0 params yield a baseline of 4, and the description does not need to add parameter meaning.
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 rebuilds the shallow file index, using a specific verb and resource. It distinguishes from the sibling tool 'build_deep_index' by specifying 'shallow' index.
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 explicitly states 'when file discovery looks stale,' indicating a clear use case. However, it does not mention when not to use or provide alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fallback text search. Use this only when get_context and symbol tools are not enough.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | ||
| case_sensitive | No | ||
| context_lines | No | ||
| file_pattern | No | ||
| fuzzy | No | ||
| regex | No | ||
| start_index | No | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must carry transparency. It says 'text search' but gives no details on behavior (e.g., search scope, output format, side effects). An output schema exists but not described.
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 concise sentences, each serving a purpose: stating functionality and providing usage condition. No 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?
For a tool with 8 parameters and no schema descriptions, the description lacks essential details about how to use parameters and what results look like, relying solely on output schema (not explained).
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 0%. The description does not explain any of the 8 parameters (pattern, case_sensitive, context_lines, etc.), leaving agents without guidance on values or defaults.
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 'Fallback text search' and specifies when to use it ('only when get_context and symbol tools are not enough'), distinguishing it from sibling tools.
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 says to use as a fallback after other tools, providing clear guidance on when and when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this first. Sets the active repo and initializes the available index state.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions that it initializes index state but does not detail whether this operation is destructive (overwrites previous state), requires specific permissions, or has side effects on other tools. The description is lacking in 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 extremely concise with two short sentences. The instruction 'Call this first' is front-loaded, making it immediately actionable. Every word earns its place; no fluff.
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 tool has an output schema, so return values don't need full description, but the description should clarify what 'initializes the available index state' entails. It lacks information on expected outcomes, error conditions, or state changes. The description is incomplete given the tool's role as a setup step.
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 0%, so the description must explain the 'path' parameter. It does not mention what 'path' should be (e.g., absolute/relative, directory/file, local/remote). The description only says 'Sets the active repo' without linking to the parameter. This is inadequate for correct invocation.
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: 'Sets the active repo and initializes the available index state.' This distinguishes it from sibling tools which are for searching, building indexes, etc. The instruction 'Call this first' further clarifies its role as a setup step.
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 says 'Call this first', indicating it should be used before other tools. However, it does not provide explicit when-not-to-use scenarios or alternatives, but given its nature as a setup tool, the guidance is clear.
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.2.0build_deep_indexfind_filesget_contextget_edit_regionget_project_snapshotget_symbol_bodyrefresh_indexsearch_codeset_project_pathEach tool has a distinct purpose: initialization, index building, file discovery, context retrieval, symbol extraction, edit region extraction, overview, search fallback, and path setting. No two tools appear to do the same thing, minimizing ambiguity.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., build_deep_index, get_context, set_project_path). No mixing of naming conventions, which aids predictability.
With 9 tools, the server covers essential operations for code analysis and edit preparation without being bloated. Each tool earns its place, and the scope is well-defined.
The tool set covers project initialization, index management, file discovery, context retrieval, symbol detail, edit regions, and project overview. Minor gaps like a path-switching tool or direct edit application are absent, but the primary focus on analysis and context is well-served.
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.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
Context engineering for AI coding agents: product context, project missions, and 360 memory.
Project memory, semantic code search, and grounded agent context.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/umuterdal/blindspot-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
