The CodeLogic MCP server integrates with AI programming assistants to provide impact analysis for code and database changes before modifications are made.
Analyze method impacts: Use codelogic-method-impact to assess downstream effects of modifying specific methods within classes
Analyze database impacts: Use codelogic-database-impact to understand dependencies between code and database entities (columns, tables, views)
Multi-language support: Works with Java, JavaScript, TypeScript, and C# .NET codebases
IDE integration: Compatible with Visual Studio Code, Claude Desktop, Windsurf IDE, and Cursor
Configurable setup: Customize behavior via environment variables for server host, credentials, workspace, and debug settings
Debug capabilities: Enable detailed performance timing logs and raw impact data for troubleshooting
Version control: Pin specific server versions for stability and compatibility
Enables Windsurf IDE to leverage Codelogic's software dependency analysis for assessing the impact of code modifications
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., "@CodeLogic what's the impact of changing the saveUser method in the UserService class?"
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.
An MCP Server to utilize Lineai's rich software dependency data in your AI programming assistant.
The server implements eight tools: two impact tools plus six graph tools backed by the Lineai graph HTTP API.
lineai-method-impact: Pulls an impact assessment from the Lineai server's APIs for your code.
Takes the given "method" that you're working on and its associated "class".
lineai-database-impact: Analyzes impacts between code and database entities.
Takes the database entity type (column, table, or view) and its name.
These call POST / GET endpoints under /api/ai-retrieval/graph/ on the same host as LINEAI_SERVER_HOST, using the same session auth as other MCP tools. If graph routes are not deployed, the server returns a clear “graph not available” style message (often after HTTP 404).
lineai-graph-capabilities: GET — discover supported relationship types, limits, and flags for the workspace materialized view (materializedViewId defaults from LINEAI_WORKSPACE_NAME like other tools).
lineai-graph-search: Search nodes by text query / q and/or identity_prefix; optional scan_space, limit, etc.
lineai-graph-impact: Dependency / blast-radius style traversal from seed_node_ids.
lineai-graph-path-explain: Shortest-path style explanation between from_node_id and to_node_id.
lineai-graph-validate-change-scope: Heuristic checklist / risk summary for a proposed change given seed nodes and proposed_change_summary.
lineai-graph-owners: Resolve a node by node_id or identity_prefix and surface property fields whose names contain "owner".
Tool arguments accept snake_case aliases (for example materialized_view_id, seed_node_ids) where noted in the MCP schema; request bodies sent to Lineai use camelCase JSON keys.
The MCP server relies upon Astral UV to run, please install
There is a known issue with uvx on MacOS where the Lineai MCP server may fail to launch in certain IDEs (such as Cursor), resulting in errors like:
See issue #11
Failed to connect client closedThis appears to be a problem with Astral uvx running on MacOS. The following can be used as a workaround:
Clone this project locally.
Configure your mcp.json to use uv instead of uvx. For example:
{
"mcpServers": {
"lineai-mcp-server": {
"type": "stdio",
"command": "<PATH_TO_UV>/uv",
"args": [
"--directory",
"<PATH_TO_THIS_REPO>/lineai-mcp-server-main",
"run",
"lineai-mcp-server"
],
"env": {
"LINEAI_SERVER_HOST": "<url to the server e.g. https://myco.app.lineai.net>",
"LINEAI_USERNAME": "<my username>",
"LINEAI_PASSWORD": "<my password>",
"LINEAI_WORKSPACE_NAME": "<my workspace>",
"LINEAI_DEBUG_MODE": "true"
}
}
}
}Restart Cursor.
Ensure the Cursor Global Rule for Lineai is in place.
Open the MCP tab in Cursor and refresh the lineai-mcp-server.
Ask Cursor to make a code change in an existing class. The MCP server should now run the impact analysis successfully.
Related MCP server: NOMIK
To configure this MCP server in VS Code:
First, ensure you have GitHub Copilot agent mode enabled in VS Code.
Create a .vscode/mcp.json file in your workspace with the following configuration:
{
"servers": {
"lineai-mcp-server": {
"type": "stdio",
"command": "uvx",
"args": [
"lineai-mcp-server@latest"
],
"env": {
"LINEAI_SERVER_HOST": "<url to the server e.g. https://myco.app.lineai.net>",
"LINEAI_USERNAME": "<my username>",
"LINEAI_PASSWORD": "<my password>",
"LINEAI_WORKSPACE_NAME": "<my workspace>",
"LINEAI_DEBUG_MODE": "true"
}
}
}
}Note: On some systems, you may need to use the full path to the uvx executable instead of just "uvx". For example:
/home/user/.local/bin/uvxon Linux/Mac orC:\Users\username\AppData\Local\astral\uvx.exeon Windows.
Alternatively, you can run the MCP: Add Server command from the Command Palette and provide the server information.
To manage your MCP servers, use the MCP: List Servers command from the Command Palette.
Once configured, the server's tools will be available to Copilot agent mode. You can toggle specific tools on/off as needed by clicking the Tools button in the Chat view when in agent mode.
To use the Lineai tools in agent mode, you can specifically ask about code impacts or database relationships, and the agent will utilize the appropriate tools.
Configure Claude Desktop by editing the configuration file:
On MacOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%/Claude/claude_desktop_config.json
On Linux: ~/.config/Claude/claude_desktop_config.json
Add the following to your configuration file:
"mcpServers": {
"lineai-mcp-server": {
"command": "uvx",
"args": [
"lineai-mcp-server@latest"
],
"env": {
"LINEAI_SERVER_HOST": "<url to the server e.g. https://myco.app.lineai.net>",
"LINEAI_USERNAME": "<my username>",
"LINEAI_PASSWORD": "<my password>",
"LINEAI_WORKSPACE_NAME": "<my workspace>"
}
}
}Note: On some systems, you may need to use the full path to the uvx executable instead of just "uvx". For example:
/home/user/.local/bin/uvxon Linux/Mac orC:\Users\username\AppData\Local\astral\uvx.exeon Windows.
After adding the configuration, restart Claude Desktop to apply the changes.
To run this MCP server with Windsurf IDE:
Configure Windsurf IDE:
To configure Windsurf IDE, you need to create or modify the ~/.codeium/windsurf/mcp_config.json configuration file.
Add the following configuration to your file:
"mcpServers": {
"lineai-mcp-server": {
"command": "uvx",
"args": [
"lineai-mcp-server@latest"
],
"env": {
"LINEAI_SERVER_HOST": "<url to the server e.g. https://myco.app.lineai.net>",
"LINEAI_USERNAME": "<my username>",
"LINEAI_PASSWORD": "<my password>",
"LINEAI_WORKSPACE_NAME": "<my workspace>"
}
}
}Note: On some systems, you may need to use the full path to the uvx executable instead of just "uvx". For example:
/home/user/.local/bin/uvxon Linux/Mac orC:\Users\username\AppData\Local\astral\uvx.exeon Windows.
After adding the configuration, restart Windsurf IDE or refresh the tools to apply the changes.
To configure the Lineai MCP server in Cursor:
Configure the MCP server by creating a .cursor/mcp.json file:
{
"mcpServers": {
"lineai-mcp-server": {
"command": "uvx",
"args": [
"lineai-mcp-server@latest"
],
"env": {
"LINEAI_SERVER_HOST": "<url to the server e.g. https://myco.app.lineai.net>",
"LINEAI_USERNAME": "<my username>",
"LINEAI_PASSWORD": "<my password>",
"LINEAI_WORKSPACE_NAME": "<my workspace>",
"LINEAI_DEBUG_MODE": "true"
}
}
}
}Note: On some systems, you may need to use the full path to the uvx executable instead of just "uvx". For example:
/home/user/.local/bin/uvxon Linux/Mac orC:\Users\username\AppData\Local\astral\uvx.exeon Windows.
Restart Cursor to apply the changes.
The Lineai MCP server tools will now be available in your Cursor workspace.
To help the AI assistant use the Lineai tools effectively, you can add the following instructions/rules to your client's configuration. We recommend customizing these instructions to align with your team's specific coding standards, best practices, and workflow requirements:
When the graph API is available on your Lineai host, extend your rules with the same guidance the server already advertises in its MCP instructions: use lineai-graph-* tools (search, impact, path-explain, validate-change-scope, owners, capabilities) for bounded graph discovery; if graph calls fail with “not available”, fall back to lineai-method-impact / lineai-database-impact.
Create a .vscode/copilot-instructions.md file with the following content:
# Lineai MCP Server Instructions
When modifying existing code methods:
- Use lineai-method-impact to analyze code changes
- Use lineai-database-impact for database modifications
- When the Lineai graph API is available, use lineai-graph-* tools (search, impact, path-explain, validate-change-scope, owners, capabilities) for bounded graph discovery; otherwise rely on method/database impact tools
- Highlight impact results for the modified methods
When modifying SQL code or database entities:
- Always use lineai-database-impact to analyze potential impacts
- Highlight impact results for the modified database entities
To use the Lineai tools effectively:
- For code impacts: Ask about specific methods or functions
- For database relationships: Ask about tables, views, or columns
- For graph discovery: Prefer lineai-graph-* tools when available
- Review the impact results before making changes
- Consider both direct and indirect impactsCreate a file ~/.claude/instructions.md with the following content:
# Lineai MCP Server Instructions
When modifying existing code methods:
- Use lineai-method-impact to analyze code changes
- Use lineai-database-impact for database modifications
- When the Lineai graph API is available, use lineai-graph-* tools (search, impact, path-explain, validate-change-scope, owners, capabilities) for bounded graph discovery; otherwise rely on method/database impact tools
- Highlight impact results for the modified methods
When modifying SQL code or database entities:
- Always use lineai-database-impact to analyze potential impacts
- Highlight impact results for the modified database entities
To use the Lineai tools effectively:
- For code impacts: Ask about specific methods or functions
- For database relationships: Ask about tables, views, or columns
- For graph discovery: Prefer lineai-graph-* tools when available
- Review the impact results before making changes
- Consider both direct and indirect impactsCreate or modify the ~/.codeium/windsurf/memories/global_rules.md markdown file with the following content:
When modifying existing code methods:
- Use lineai-method-impact to analyze code changes
- Use lineai-database-impact for database modifications
- When the Lineai graph API is available, use lineai-graph-* tools (search, impact, path-explain, validate-change-scope, owners, capabilities) for bounded graph discovery; otherwise rely on method/database impact tools
- Highlight impact results for the modified methods
When modifying SQL code or database entities:
- Always use lineai-database-impact to analyze potential impacts
- Highlight impact results for the modified database entities
To use the Lineai tools effectively:
- For code impacts: Ask about specific methods or functions
- For database relationships: Ask about tables, views, or columns
- For graph discovery: Prefer lineai-graph-* tools when available
- Review the impact results before making changes
- Consider both direct and indirect impactsTo configure Lineai rules in Cursor:
Open Cursor Settings
Navigate to the "Rules" section
Add the following content to "User Rules":
# Lineai MCP Server Rules
## Codebase
- The Lineai MCP Server is for java, javascript, typescript, and C# dotnet codebases
- don't run the tools on python or other non supported codebases
## AI Assistant Behavior
- When modifying existing code methods:
- Use lineai-method-impact to analyze code changes
- Use lineai-database-impact for database modifications
- When the Lineai graph API is available, use lineai-graph-* tools (search, impact, path-explain, validate-change-scope, owners, capabilities) for bounded graph discovery; otherwise rely on method/database impact tools
- Highlight impact results for the modified methods
- When modifying SQL code or database entities:
- Always use lineai-database-impact to analyze potential impacts
- Highlight impact results for the modified database entities
- To use the Lineai tools effectively:
- For code impacts: Ask about specific methods or functions
- For database relationships: Ask about tables, views, or columns
- Review the impact results before making changes
- Consider both direct and indirect impactsThe following environment variables can be configured to customize the behavior of the server:
LINEAI_SERVER_HOST: The URL of the Lineai server.
LINEAI_USERNAME: Your Lineai username.
LINEAI_PASSWORD: Your Lineai password.
LINEAI_WORKSPACE_NAME: The name of the workspace to use.
LINEAI_DEBUG_MODE: Set to true to enable debug mode. When enabled, additional debug files such as timing_log.txt and impact_data*.json will be generated. Defaults to false.
Tests only
LINEAI_GRAPH_E2E_REQUIRED: Set to 1 when running graph MCP integration tests if you want missing graph APIs (HTTP 404 / “Graph API not available”) to fail the suite instead of skipping those tests.
"env": {
"LINEAI_SERVER_HOST": "<url to the server e.g. https://myco.app.lineai.net>",
"LINEAI_USERNAME": "<my username>",
"LINEAI_PASSWORD": "<my password>",
"LINEAI_WORKSPACE_NAME": "<my workspace>",
"LINEAI_DEBUG_MODE": "true"
}instead of using the latest version of the server, you can pin to a specific version by changing the args field to match the version in pypi e.g.
"args": [
"lineai-mcp-server@0.2.2"
],This MCP server has the following version compatibility requirements:
Version 0.3.1 and below: Compatible with all Lineai API versions
Version 0.4.0 and above: Requires Lineai API version 25.10.0 or greater
If you're upgrading, make sure your Lineai server meets the minimum API version requirement.
Graph tools: Require your Lineai deployment to serve the graph endpoints under /api/ai-retrieval/graph/. Older or partial deployments may return 404; the MCP tools surface that as a clear error instead of opaque failures.
When LINEAI_DEBUG_MODE=true, debug files are written to the system temporary directory:
Windows: %TEMP%\lineai-mcp-server (typically C:\Users\{username}\AppData\Local\Temp\lineai-mcp-server)
macOS: /tmp/lineai-mcp-server (or $TMPDIR/lineai-mcp-server if set)
Linux: /tmp/lineai-mcp-server (or $TMPDIR/lineai-mcp-server if set)
Debug files include:
timing_log.txt - Performance timing information
impact_data_*.json - Raw impact analysis data for troubleshooting
Finding your log directory:
import tempfile
import os
print("Log directory:", os.path.join(tempfile.gettempdir(), "lineai-mcp-server"))The project uses unittest for testing. You can run unit tests without any external dependencies:
python -m unittest discover -s test -p "unit_*.py"Unit tests use mock data and don't require a connection to a Lineai server.
If you want to run integration tests that connect to a real Lineai server:
Copy test/.env.test.example to test/.env.test and populate with your Lineai server details
Run the integration tests:
python -m unittest discover -s test -p "integration_*.py"Note: Integration tests require access to a Lineai server instance.
test/integration_test_graph.py drives the real MCP handler path (handle_call_tool) for lineai-graph-capabilities and a chained flow (search → impact → path → validate → owners) against LINEAI_SERVER_HOST. Configure credentials the same way as other integration tests (test/.env.test from test/.env.test.example).
If the host does not expose graph routes, tests skip by default.
Set LINEAI_GRAPH_E2E_REQUIRED=1 to turn missing graph APIs into hard failures (useful in CI when graph must be present).
From the repo root:
./scripts/run_graph_e2e.shEquivalent:
uv run python -m unittest test.integration_test_graph -vmcp-name: io.github.lineai-intelligence/lineai-mcp-server
Analyze impacts between code and database entities. Uses CODELOGIC_WORKSPACE_NAME environment variable to determine the target workspace. Recommended workflow:
Use this tool before implementing code or database changes
Search for the relevant database entity
Review the impact analysis to understand which code depends on this database object and vice versa Particularly crucial when AI-suggested modifications are being considered or when modifying SQL code.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the database entity to search for | |
| entity_type | Yes | Type of database entity to search for (column, table, or view) | |
| table_or_view | No | Name of the table or view containing the column (required for columns only) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses use of environment variable CODELOGIC_WORKSPACE_NAME and mentions the tool is read-only in nature (analysis, no mutations). But with no annotations, it fails to describe output format, performance, authentication needs, or rate limits. The description is partially transparent but lacks critical behavioral details.
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?
Description is concise (4 sentences) and front-loaded with purpose. Numbered workflow improves structure. Every sentence contributes value, though the workflow could be more compact.
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 partially compensates by explaining the workflow and environment variable. However, it lacks details on the output format (e.g., list of dependencies, JSON structure), limiting the agent's ability to use results effectively.
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 clear descriptions for each parameter. The tool description adds minimal extra context beyond what the schema already provides (e.g., entity types). Baseline score of 3 is appropriate as description does not significantly enhance parameter understanding.
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?
Clearly states it analyzes impacts between code and database entities, with specific verb 'Analyze' and resource 'impacts'. Tool name and parameters (entity_type: column/table/view) reinforce database focus, distinguishing it from siblings like codelogic-method-impact and codelogic-graph-impact.
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?
Provides a recommended workflow (use before changes, search entity, review impacts) and emphasizes relevance for AI-suggested or SQL modifications. However, it does not explicitly contrast with sibling tools or state 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.
Fetch graph API capabilities/manifest from the CodeLogic server (GET). Returns label and relationship metadata when the graph tier is deployed; otherwise explains missing routes. Uses CODELOGIC_WORKSPACE_NAME for MV id unless materialized_view_id is set.
| Name | Required | Description | Default |
|---|---|---|---|
| materialized_view_id | No | Optional materialized view id; default from workspace name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the GET method, conditional returns (metadata vs missing routes), and default parameter behavior. It lacks statements on auth or side effects, but for a read-only fetch, this is 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?
Two sentences with no redundancy. The first sentence states the core action and why, the second adds parameter detail. Every word contributes 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?
For a simple tool with one optional parameter and no output schema, the description covers purpose, behavior, and default logic. It could mention if the endpoint requires authentication or if there are rate limits, but overall it is sufficient.
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 only parameter is optional and well described in both schema and description. The description adds context about defaulting from the CODELOGIC_WORKSPACE_NAME environment variable, which is valuable beyond the schema.
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 fetches graph API capabilities/manifest, specifies HTTP method (GET), and distinguishes return content based on deployment status. This sets it apart from siblings like search or impact, which focus on different 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 context by mentioning deployment-dependent behavior and default from workspace, but does not explicitly state when to use this tool over alternatives like codelogic-graph-search. No when-not guidelines provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bounded graph impact from seed node ids (curated HTTP API). Optional direction (upstream|downstream|both), depth, scan_space, materialized_view_id.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | ||
| direction | No | ||
| scan_space | No | ||
| seed_node_ids | Yes | Graph node ids to expand from | |
| materialized_view_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions 'bounded' (by depth/scan_space) and optional parameters, but omits details on defaults, idempotency, authentication, rate limits, or whether the operation is read-only. The description is insufficient for safe invocation.
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 that front-loads the core purpose. It lists optional parameters succinctly without redundancy. Could be slightly improved with structured bullet points for parameter details.
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 complexity (5 parameters, no output schema) and the sparse schema descriptions, the description is incomplete. It fails to explain the return value format, how 'impact' is computed, or provide examples. Sibling tools exist, but no comparative context is given.
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 only 20% (only seed_node_ids has a description). The description lists parameter names and direction enum values but adds no meaningful semantics for depth, scan_space, or materialized_view_id. It does not explain the purpose or constraints of these parameters.
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 it performs 'graph impact' from seed node ids, using a 'curated HTTP API'. It distinguishes from siblings like codelogic-database-impact and codelogic-method-impact by specifying 'graph'. However, it does not define what 'impact' means (e.g., affected nodes/edges).
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 versus alternatives like codelogic-graph-search or codelogic-graph-validate-change-scope. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up owners/reviewers for a graph node (curated HTTP API). Provide node_id or identity_prefix.
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | No | ||
| scan_space | No | ||
| identity_prefix | No | ||
| materialized_view_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'curated HTTP API' but does not disclose read-only behavior, error conditions, rate limits, or side effects. The behavioral profile is largely opaque.
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 (two sentences) and front-loaded with the core purpose. Every sentence adds value without repetition.
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 4 parameters and no output schema, yet the description does not explain return values or the role of unspecified parameters. It is insufficient for fully informed usage.
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 description must compensate. It only explains node_id and identity_prefix, ignoring scan_space and materialized_view_id. Users are left guessing about these parameters.
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 action (look up owners/reviewers) and resource (graph node), distinguishing it from sibling tools that focus on impact, search, or capabilities. However, 'graph node' could be more precisely defined.
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 hints at parameter usage ('Provide node_id or identity_prefix') but does not specify when to use this tool versus siblings like codelogic-graph-search or codelogic-graph-impact. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain bounded paths between two graph nodes (curated HTTP API). Requires from_node_id, to_node_id; optional max_depth, scan_space, materialized_view_id.
| Name | Required | Description | Default |
|---|---|---|---|
| max_depth | No | ||
| scan_space | No | ||
| to_node_id | Yes | ||
| from_node_id | Yes | ||
| materialized_view_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only mentions 'curated HTTP API' but does not indicate whether the operation is read-only, destructive, or has side effects. There is no information about performance, rate limits, or permissions.
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 of 20 words, efficiently conveying the tool's purpose and key parameters. It is front-loaded with the primary action and resource.
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 5 parameters, no output schema, and no annotations, the description covers the purpose and parameters but does not explain what the tool returns or any error conditions. The sibling tools list provides some context, but the description itself leaves gaps in completeness for an agent to use correctly.
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%, yet the description lists all five parameters by name and distinguishes required from optional ones. This adds meaningful context beyond the raw schema, which only defines types and requirements. However, it lacks detailed semantics like allowed values for 'scan_space' or format constraints.
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: 'Explain bounded paths between two graph nodes'. It uses a specific verb ('Explain') and resource ('bounded paths between two graph nodes'), and distinguishes itself from sibling tools like codelogic-graph-search or codelogic-graph-impact.
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 specifies required and optional parameters, giving clear context on what inputs are needed. However, it does not explicitly state when to use this tool versus alternatives or when not to use it, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the CodeLogic knowledge graph (curated HTTP API). Provide query or identity_prefix; optional scan_space, materialized_view_id, limit. Requires server route POST .../ai-retrieval/graph/search.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Alias for query | |
| limit | No | Suggested max hits (server may cap) | |
| query | No | Symbol or text query (alias: q) | |
| scan_space | No | Optional scan-space / branch filter | |
| identity_prefix | No | Prefix of stable graph identity | |
| prefer_latest_scan | No | ||
| materialized_view_id | No | Override MV id; default from workspace name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions HTTP route and limit cap, but fails to disclose read-only nature, side effects, return format, or error handling.
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 with front-loaded core action, efficient listing of parameters, 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?
Adequate for a search tool but lacks output format details, explicit required parameters, and clearer differentiation from siblings. With 7 parameters and no annotations, more context would be beneficial.
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 high (86%). Description adds value by indicating alternatives (query or identity_prefix) and grouping optional parameters, but adds little beyond what the schema already provides.
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?
Clearly states 'Search the CodeLogic knowledge graph' with specific verb and resource, but does not differentiate from sibling tools like codelogic-graph-impact or codelogic-graph-path-explain.
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?
Provides minimal guidance on providing query or identity_prefix with optional parameters, but lacks explicit when-to-use or when-not-to-use instructions and does not mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate whether a proposed change scope is safe given seed graph nodes (curated HTTP API).
| Name | Required | Description | Default |
|---|---|---|---|
| scan_space | No | ||
| seed_node_ids | Yes | ||
| materialized_view_id | No | ||
| proposed_change_summary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It says 'validate whether...safe' but does not disclose if the tool is read-only, modifies state, requires authentication, or what 'safe' means. Minimal behavioral context beyond the core action.
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, concise and front-loaded with the core purpose. However, it could be more structured (e.g., listing parameters or usage context) to compensate for missing schema descriptions.
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 4 parameters, no output schema, and no annotations, the description is grossly incomplete. It fails to explain return values, parameter formats, safety criteria, or any preconditions, leaving the agent unable to use the tool reliably.
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 adds no parameter explanations. Only 'seed graph nodes' hints at seed_node_ids, but scan_space, materialized_view_id, and proposed_change_summary remain entirely opaque, severely limiting 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 states the tool validates safety of a proposed change scope, which is a specific verb+resource. It differentiates from sibling tools like 'codelogic-graph-impact' by focusing on validation vs. impact analysis, though no explicit alternative guidance is given.
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 vs alternatives. It mentions 'seed graph nodes' and 'curated HTTP API' but does not specify prerequisites or exclusions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze impacts of modifying a specific method within a given class or type. Uses CODELOGIC_WORKSPACE_NAME environment variable to determine the target workspace. Recommended workflow:
Use this tool before implementing code changes
Run the tool against methods or functions that are being modified
Carefully review the impact analysis results to understand potential downstream effects Particularly crucial when AI-suggested modifications are being considered.
| Name | Required | Description | Default |
|---|---|---|---|
| class | Yes | Name of the class containing the method | |
| method | Yes | Name of the method being analyzed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states the tool 'analyzes impacts' (implying read-only) and uses an environment variable, but does not disclose specific behaviors like whether it mutates data, auth requirements, or rate limits. It also omits details on what the results contain, which is important given no output schema.
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 a clear front-loaded purpose and a numbered workflow list. Every sentence adds value, though the workflow could be slightly shortened without losing meaning.
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 only two parameters, the description covers purpose, workflow, and environment variable. However, it lacks information about the output format or how to interpret results, which would be helpful for an impact analysis tool. The absence of an output schema increases the need for description completeness.
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?
Input schema has 100% coverage with descriptions for both required parameters ('Name of the class containing the method' and 'Name of the method being analyzed'). The description adds minimal extra meaning ('within a given class or type') but does not significantly enrich parameter understanding beyond the schema.
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: analyzing impacts of modifying a specific method within a class or type. It uses a specific verb ('Analyze impacts') and resource ('method within class'), distinguishing it from sibling tools like codelogic-database-impact or codelogic-graph-impact.
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 a recommended workflow with three steps, including when to use (before implementing changes) and context (when AI-suggested modifications are considered). It also mentions the environment variable requirement, but lacks explicit exclusion of alternatives or when-not-to-use.
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.
v1.3.0codelogic-civ1.2.0codelogic-cicodelogic-graph-capabilitiescodelogic-graph-impactcodelogic-graph-ownerscodelogic-graph-path-explaincodelogic-graph-searchcodelogic-graph-validate-change-scopev1.0.0codelogic-database-impactcodelogic-method-impactEach tool targets a distinct aspect of CodeLogic: CI integration, database impact, graph capabilities, graph impact, owners, path explanation, search, change scope validation, and method impact. There is no overlap even among impact tools as they operate on different entities (database, graph, methods).
All tools use a consistent 'codelogic-<domain>-<action>' pattern in snake_case (e.g., codelogic-database-impact, codelogic-graph-search). The naming is uniform and descriptive.
With 9 tools, the set is well-scoped for a code intelligence and impact analysis server. Each tool covers a necessary functionality without being excessive or minimal.
The tool set covers core workflows: CI integration, impact analysis on multiple levels (database, graph, methods), search, path explanation, and validation. Minor gaps exist (e.g., no explicit workspace management), but the environment variable approach mitigates this.
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.
Read-only AI coding tools for change verification, release readiness, capacity, and guidance.
AI Agent with Architectural Memory. Impact analysis (free), tests and code from the graph (pro).
Ground-truth code graph for your codebase: exact callers, callees, symbols & dependencies.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lineai-intelligence/lineai-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
