TypeScript-ориентированный MCP-сервер для обнаружения репозиториев, анализа кода и контекста веб-рабочих пространств.
[
](https://github.
Inspect a local root path and return workspace files, monorepo packages, tsconfig files, and package classification hints.
| Name | Required | Description | Default |
|---|---|---|---|
| root | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses what data is returned (files, packages, hints), but lacks safety confirmation (read-only nature), performance characteristics (scanning cost), or error behavior given zero annotations. 'Inspect' implies read-only but doesn't guarantee it.
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, 16 words. Front-loaded action verb followed by parameter reference and return value enumeration. 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?
Lists return categories compensating for missing output schema, but omits parameter format details, error cases, and return structure shape needed for a tool with zero annotations and 0% schema coverage.
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?
With 0% schema coverage, the description compensates by specifying 'local root path', confirming the parameter represents a filesystem path to project root. Could further clarify absolute vs. relative paths.
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?
Clear verb ('Inspect') and resource ('local root path'), with specific enumerated outputs (workspace files, monorepo packages, tsconfig files, classification hints) that distinguish it from symbol-focused siblings like get_definition and get_references.
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 versus alternatives, prerequisites (e.g., path must exist), or relationship to sibling tools like get_web_project_context. Purely descriptive without strategic direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve the definition locations for a symbol at a 1-based line and column in a file.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| workspaceRoot | No | ||
| projectTsconfigPath | No | ||
| line | Yes | ||
| column | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full disclosure burden. It adds crucial behavioral context by specifying '1-based' indexing for coordinates, which prevents off-by-one errors. However, it omits other important behaviors: whether it returns multiple locations (overloads), what happens when no definition is found, or whether it triggers project reload/analysis.
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 is front-loaded with the action ('Resolve') and avoids redundancy. However, given the lack of schema documentation and annotations, the brevity may be excessive rather than efficient—it leaves significant gaps that require inference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters (2 optional), 0% schema coverage, no annotations, and no output schema, the description is insufficient. It ignores the workspace configuration parameters which are likely critical for monorepo or multi-project contexts, and provides no indication of return value structure or error conditions.
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%, requiring the description to compensate. It partially explains semantics for 'line' and 'column' (1-based) and implies 'file', but completely omits explanation of the two optional parameters 'workspaceRoot' and 'projectTsconfigPath' which likely control project resolution scope and TypeScript configuration.
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 resolves definition locations for symbols using specific coordinates (line/column) in a file. The verb 'Resolve' and resource 'definition locations' are specific, though it doesn't explicitly contrast with the sibling tool 'get_references' (which finds usages rather than declarations).
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 provided on when to use this versus alternatives like 'get_references' or 'get_symbol_summary'. No prerequisites mentioned (e.g., requiring a valid project configuration or when the optional workspaceRoot/projectTsconfigPath parameters should be used).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return TypeScript syntactic and semantic diagnostics for a single file using project-aware configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| workspaceRoot | No | ||
| projectTsconfigPath | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Return' correctly implies a read-only operation, and 'project-aware' hints at configuration resolution behavior. However, it omits error handling, performance characteristics, and cache behavior.
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 efficient sentence with no redundancy. Every clause contributes essential information: operation (Return), resource (diagnostics), type (syntactic/semantic), scope (single file), and mechanism (project-aware configuration).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three undocumented parameters (0% coverage), no output schema, and no annotations, the description is insufficient. It explains the concept of diagnostics but fails to document parameter semantics or return structure adequately for the 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%, requiring the description to compensate. It loosely maps 'single file' to the file parameter and 'project-aware configuration' to workspaceRoot/projectTsconfigPath, but provides no format details, path requirements, or guidance on when optional parameters are needed.
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 TypeScript syntactic and semantic diagnostics, distinguishing it from sibling navigation tools like get_definition or get_references. It specifies the scope (single file) and mechanism (project-aware configuration).
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 phrase 'using project-aware configuration' implies usage context (when project context is needed), but there are no explicit when-to-use guidelines, prerequisites, or comparisons to alternatives like reload_project or discover_repository_structure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve project-aware definition and usage references for the symbol at a 1-based line and column in a file.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| workspaceRoot | No | ||
| projectTsconfigPath | No | ||
| line | Yes | ||
| column | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Specifies '1-based' coordinate system (critical for line/column parameters) and 'project-aware' scope. However, with no annotations and no output schema, it omits what gets returned (locations? symbols?), error behavior when symbol not found, and whether results include the definition site or only usages.
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 no waste. Front-loaded with the action and target. However, excessive brevity given the need to explain 5 parameters with zero schema documentation.
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?
Inadequate for a 5-parameter tool with 0% schema coverage, no annotations, and no output schema. Missing: optional parameter semantics, return value structure, prerequisites (e.g., project initialization), and sibling differentiation.
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?
With 0% schema coverage, the description must compensate fully. It successfully adds semantics for line/column (1-based) and file, but leaves workspaceRoot and projectTsconfigPath completely undocumented despite being important for the 'project-aware' behavior mentioned.
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?
Clear verb ('Resolve') and resource ('definition and usage references'), with scope ('project-aware', specific file location). Distinguishes from sibling get_definition by implying both definitions and usages are returned. Slight ambiguity in whether 'definition and usage references' means definitions plus usages, or just references.
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 versus get_definition (which likely returns just the definition) or get_symbol_summary. No mention that workspaceRoot and projectTsconfigPath are optional or when to provide them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return symbol kind, display text, declaration location, and project metadata for a 1-based source position.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| workspaceRoot | No | ||
| projectTsconfigPath | No | ||
| line | Yes | ||
| column | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the 1-based indexing behavior for line/column which is crucial for correct invocation. With no annotations provided, the description carries the full burden but omits error handling (invalid positions), side effects (caching), and output format 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?
Single 18-word sentence efficiently packs return value types, resource target, and coordinate system constraint. No redundancy or filler.
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?
Compensates somewhat for missing output schema by enumerating return fields. However, with 5 parameters and 0% schema coverage, the failure to document file path format and optional configuration parameters leaves significant gaps.
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%, requiring the description to compensate. It only covers line/column semantics via '1-based source position', leaving 3 parameters (file, workspaceRoot, projectTsconfigPath) completely undocumented regarding their format, requirements, and relationships.
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?
States specific return values (symbol kind, display text, declaration location, project metadata) and the target (1-based source position). Implicitly distinguishes from get_definition by emphasizing summary-level data rather than full definition 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?
Provides the critical constraint that positions are 1-based, but offers no guidance on when to use this versus sibling tools like get_definition or get_references, nor when the optional workspaceRoot and projectTsconfigPath parameters are required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a local root path and return frontend-oriented context such as entrypoints, routing surfaces, config files, and framework hints.
| Name | Required | Description | Default |
|---|---|---|---|
| root | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Implies read-only operation through verbs 'inspect' and 'return', which compensates for missing annotations. However, lacks critical behavioral details: whether it follows symlinks, handles missing paths (error vs empty result), recursion depth, or performance characteristics for large projects.
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 with action verbs, zero redundancy. Every clause adds distinct value: action (inspect), target (local root path), and return value specifics (frontend context with four concrete examples).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description partially compensates by listing example return categories (entrypoints, etc.), giving callers conceptual understanding. However, for a tool with 0% schema coverage and no annotations, it should explicitly document the 'root' parameter requirements and return structure/schema.
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% (no descriptions), so the text must carry full load. The phrase 'local root path' in the description implicitly maps to the 'root' parameter and clarifies it expects a filesystem path. However, it doesn't specify expected format (absolute vs relative), trailing slash behavior, or validation rules beyond the schema's 'minLength: 1'.
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?
Excellent specificity with concrete examples of returned context (entrypoints, routing surfaces, config files, framework hints). The 'frontend-oriented' qualifier effectively distinguishes this from the general 'discover_repository_structure' sibling. Minor gap: could explicitly state this is for local filesystem inspection versus remote.
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 versus 'discover_repository_structure' or other siblings. Given the overlap in scanning directories, explicit differentiation (e.g., 'Use this instead of discover_repository_structure when you need frontend-specific analysis') would prevent incorrect selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invalidate cached TypeScript project state and reload it from tsconfig.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | ||
| workspaceRoot | No | ||
| projectTsconfigPath | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'Invalidate cached' implies state mutation, but lacks details on blocking behavior, failure modes if tsconfig is malformed, or whether this affects in-flight operations. Just barely adequate for a stateful tool.
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 efficient sentence front-loaded with the action. However, extreme brevity is inappropriate given three undocumented parameters and the absence of annotations - conciseness becomes under-specification here.
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?
Mutation tool with 0% schema coverage, no annotations, and no output schema requires substantial description support. Currently explains the operation but fails to document parameter meanings, return values, or error conditions necessary for safe invocation.
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%, requiring description compensation. While 'reload it from tsconfig' hints at projectTsconfigPath, parameters 'file' and 'workspaceRoot' are completely undocumented with no indication of their purpose or which is required when.
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?
Clear action (invalidate cache, reload) and resource (TypeScript project state from tsconfig). Distinguishes from siblings like get_definition or get_diagnostics by describing a cache-mutation operation rather than a query.
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 versus letting the server auto-detect changes, or when it's necessary to manually reload. No mention of prerequisites or side effects on concurrent operations.
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.
v0.1.0discover_repository_structureget_definitionget_diagnosticsget_referencesget_symbol_summaryget_web_project_contextreload_projectScored across 7 tools
Each tool has a clearly distinct purpose with no overlap: discover_repository_structure inspects workspace files, get_definition resolves symbol definitions, get_diagnostics provides TypeScript diagnostics, get_references finds usage references, get_symbol_summary returns symbol metadata, get_web_project_context focuses on frontend context, and reload_project refreshes project state. The descriptions make each tool's unique role unambiguous.
All tool names follow a consistent verb_noun pattern using snake_case: discover_repository_structure, get_definition, get_diagnostics, get_references, get_symbol_summary, get_web_project_context, and reload_project. The naming is predictable and readable throughout the set.
With 7 tools, the count is well-scoped for a TypeScript/workspace analysis server. Each tool earns its place by covering distinct aspects like structure discovery, symbol resolution, diagnostics, references, metadata, frontend context, and project reloading, without being too sparse or bloated.
The tool set provides complete coverage for code analysis and workspace inspection in a TypeScript environment. It includes discovery (repository and web context), symbol operations (definition, references, summary), diagnostics, and project management (reload), with no obvious gaps for the server's purpose.
Repository knowledge graph MCP server for codebase understanding and debugging.
An MCP server that gives your AI access to the source code and docs of all public github repos
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
