ai_analyze
[CORTEX] Use AI (Gemini/OpenAI/Claude) to perform semantic analysis on a file. Reads the file's source code and its dependents to explain what might break when modified and how to safely make changes.
LABSCO SUMMARY
The gate is the opinionated part: gate_build calls itself MANDATORY before any build, deploy or test, and a FAIL is written as an instruction to stop rather than a score to weigh.
Most of what SYKE knows is a single graph of what imports what, and the tools are different questions asked of it — check_safe for a one-line verdict, analyze_impact for the dependent list, get_hub_files for the files everything leans on, get_dependencies for the imports a file makes. That graph is a snapshot, which makes refresh_graph part of the routine after adding or removing files rather than a repair. The [CORTEX] tools leave the graph entirely: ai_analyze and scan_project read source through an external model, and scan_project says outright that you bring the key. Worth knowing before you plan around it — analyze_impact, get_hub_files, refresh_graph and check_warnings carry a [PRO] tag, so the dependent list sits behind that tag while check_safe's one-line verdict does not.
What it is
A dependency-graph server over your source tree that scores the blast radius of a file change, gates builds on that score, and can hand a file plus its dependents to an LLM for a semantic read.
What you get
- A verdict you call before a build: gate_build takes the changed files and returns PASS, WARN or FAIL with the reasons behind it, and its description marks it as the final check before any compilation or deployment.
- Blast radius on a named file: analyze_impact returns direct and transitive dependents with a risk level, and check_safe compresses the same question into a one-line HIGH, MEDIUM, LOW or NONE verdict carrying the count of impacted files.
- The graph read in the forward direction: get_dependencies lists the internal files a given file imports.
- Ranking by how much leans on a file: get_hub_files applies PageRank across the graph and returns the top_n files that the most other files depend on.
- A semantic read instead of a graph read: ai_analyze sends a file's source and its dependents to Gemini, OpenAI or Claude and explains what might break and how to change it safely.
- An onboarding document for a codebase you did not write: scan_project walks the whole project and reports architecture, key files, dependencies and patterns.
- Follow-up after the edit: check_warnings returns unresolved warnings from SYKE's real-time monitoring about changes that may have broken dependents, and clears them when acknowledge is set.
- refresh_graph re-scans the source files and rebuilds the dependency graph after files are added or removed.
Requirements
The source tree itself, and an AI API key of your own for the [CORTEX] tools — scan_project states that it needs one (BYOK), and ai_analyze reads through Gemini, OpenAI or Claude. No environment credentials are configured. analyze_impact, get_hub_files, refresh_graph and check_warnings carry a [PRO] tag.
Setup effort
One command — npx @syke1/mcp-server@latest
USE CASES
01
Deciding whether a file is safe to touch
Ask for the one-line risk verdict first, then pull the dependent list when the verdict is not NONE, and look at what the file itself imports before you rewrite it.
02
Stopping a broken change before the build runs
Gate the changed files and read the reasons behind a WARN or FAIL, then check afterwards whether the monitoring caught anything the edit broke.
03
Getting oriented in a codebase you have just joined
Have the project written up as an onboarding document, then find out which files everything else leans on so you know where the care is needed.
04
Understanding why a change is risky rather than only that it is
Get the dependent list from the graph, then have the file and those dependents read semantically for what could actually break and how to avoid it.
9 tools
Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.
analyze_impact
[PRO] Analyze which files are impacted when a given file is modified. Returns direct and transitive dependents with risk level.
check_safe
Quick safety check for modifying a file. Returns a one-line verdict: HIGH/MEDIUM/LOW/NONE risk with impacted file count.
check_warnings
[PRO] Check for unresolved warnings from SYKE's real-time monitoring. Returns warnings about file changes that may have broken dependents. Use this AFTER modifying files to see if SYKE caught any issues you may have missed. Pass acknowledge=true to clear warnings after reading them.
gate_build
MANDATORY: Call this BEFORE any build, deploy, or test command. Returns PASS, WARN, or FAIL verdict with detailed reasons. If FAIL, do NOT proceed with build — fix issues first. Always call this as the final check before any compilation or deployment.
get_dependencies
List the internal files that a given file imports (forward dependencies).
get_hub_files
[PRO] Rank files by how many other files depend on them (PageRank). High-hub files are risky to modify.
refresh_graph
[PRO] Re-scan all source files and rebuild the dependency graph. Use after adding/removing files.
scan_project
[CORTEX] Scan the entire project and generate a comprehensive onboarding document. Analyzes architecture, key files, dependencies, and patterns to help new team members understand the codebase quickly. Requires AI API key (BYOK).
BEFORE YOU INSTALL
What to know first
Tools you get
9 tools when we connected.
Requires
npx on PATH
Where it runs
All 3 documented clients run the server on your machine.
CONTEXT COST
Light Standing cost
Rated by the size of the 9 tool definitions that ride along on every turn, not by how many there are
INSTALLATION
Connect your client
Server setup
TERMINAL
npx @syke1/mcp-server@latestMCP Clients
Claude Code
CLAUDE CODE · TERMINAL
claude mcp add syke -- npx @syke1/mcp-server@latestCursor, Windsurf
JSON
{
"mcpServers": {
"syke": {
"command": "npx",
"args": [
"@syke1/mcp-server@latest"
]
}
}
}
