Automatically detects lerna-managed monorepos and allows querying diagnostics per package.
Automatically detects npm workspaces and allows querying diagnostics per workspace package in monorepos.
Automatically detects pnpm workspaces and allows querying diagnostics per workspace package in monorepos.
Provides real-time TypeScript diagnostics with intelligent caching, allowing instant queries for errors and warnings without running tsc.
Automatically detects yarn workspaces and allows querying diagnostics per workspace package in monorepos.
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., "@ts-diagnostics-mcp check for TypeScript errors in the project"
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.
Live TypeScript type checking without constant recompilation - A Model Context Protocol (MCP) server that provides real-time TypeScript diagnostics with intelligent caching, perfect for AI agents working in TypeScript codebases.
When multiple AI agents work simultaneously in a TypeScript codebase, they often run tsc or type-check commands repeatedly, causing:
Massive performance degradation - Each agent triggers full recompilation
System slowdown - Multiple concurrent TypeScript processes consume CPU/memory
Redundant work - Same files get type-checked repeatedly
Poor agent responsiveness - Agents wait for slow compilation before proceeding
Related MCP server: code-dev-intel
ts-diagnostics-mcp runs TypeScript's compiler in watch mode once, maintaining a live cache of diagnostics that all agents can query instantly:
80-95% faster than running tsc repeatedly
Single background process serves all agents
Instant queries - milliseconds instead of seconds
Monorepo support - handles multiple packages seamlessly
Smart caching - LRU cache with file-level granularity
Real-time TypeScript diagnostics via MCP
Monorepo support - Auto-detects pnpm, yarn, npm workspaces, Rush, Lerna
Intelligent caching - LRU cache with configurable size limits
Package filtering - Query diagnostics by workspace package
Fast queries - has_errors() in microseconds
Watch mode - TypeScript Compiler API with incremental builds
Zero configuration - Auto-detects project structure
Flexible - Works with single projects and monorepos
No installation required! Just configure and run via npx.
Edit your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Add this configuration:
{
"mcpServers": {
"ts-diagnostics": {
"command": "npx",
"args": [
"-y",
"ts-diagnostics-mcp@latest",
"/absolute/path/to/your/typescript/project"
]
}
}
}Restart Claude Desktop
Add to your .mcp.json:
{
"mcpServers": {
"ts-diagnostics": {
"command": "npx",
"args": [
"-y",
"ts-diagnostics-mcp@latest",
"/absolute/path/to/your/typescript/project"
]
}
}
}If you prefer a global installation:
npm install -g ts-diagnostics-mcpThen configure with:
{
"mcpServers": {
"ts-diagnostics": {
"command": "ts-diagnostics-mcp",
"args": ["/absolute/path/to/your/project"]
}
}
}Hey Claude, check if there are any TypeScript errors in the project.Claude will use the has_errors tool to instantly check without running tsc!
# Quick error check (microseconds)
Tool: has_errors
Result: { "hasErrors": true }
# Get all errors across project
Tool: get_all_diagnostics
Result: { errors: 12, warnings: 3, diagnostics: [...] }
# Check specific file
Tool: get_file_diagnostics
Args: { "filePath": "src/server/auth.ts" }
# Get diagnostics for specific package (monorepo)
Tool: get_package_diagnostics
Args: { "packageName": "@degentalk/server" }
# Get summary counts
Tool: get_diagnostic_count
Result: { errors: 12, warnings: 3, suggestions: 0 }
# List available packages
Tool: list_packages
Result: { packages: ["@degentalk/app", "@degentalk/server", ...] }Tool | Description | Speed |
| Boolean check for errors | Instant (μs) |
| Get error/warning counts | Instant (μs) |
| Get all diagnostics | Fast (ms) |
| Get diagnostics for specific file | Fast (ms) |
| Get diagnostics for package | Fast (ms) |
| Check watch process status | Instant |
| View cache performance | Instant |
| List monorepo packages | Instant |
| Clear diagnostic cache | Instant |
No configuration needed! The server auto-detects:
Monorepo type (pnpm, yarn, npm, Rush, Lerna)
Workspace packages
TypeScript configs
Create .ts-diagnostics.json in your project root:
{
"maxCacheSize": 100,
"debounceMs": 500,
"enableIncrementalMode": true,
"autoDetectWorkspaces": true,
"ignorePatterns": [
"**/*.test.ts",
"**/*.spec.ts",
"**/test/**",
"**/migrations/**"
]
}Default Ignore Patterns (always applied):
**/node_modules/**
**/dist/**
**/build/**
**/.git/**
**/coverage/**
**/.next/**
**/.turbo/**
**/.cache/**
**/out/**
**/*.min.js
**/*.bundle.js
**/.tsbuildinfo
Add your own patterns to exclude additional files from diagnostics.
TS_DIAG_MAX_CACHE_SIZE=200 # Cache size in MB
TS_DIAG_DEBOUNCE_MS=300 # Debounce delay
TS_DIAG_INCREMENTAL=true # Enable incremental builds
TS_DIAG_AUTO_DETECT=true # Auto-detect workspacesFor complex setups, specify configs manually:
{
"projectRoot": "/path/to/project",
"tsConfigs": [
{
"configPath": "/path/to/packages/app/tsconfig.json",
"name": "@myapp/app",
"rootDir": "/path/to/packages/app"
},
{
"configPath": "/path/to/packages/server/tsconfig.json",
"name": "@myapp/server",
"rootDir": "/path/to/packages/server"
}
]
}✅ pnpm workspaces (via pnpm-workspace.yaml)
✅ Yarn workspaces (via package.json workspaces)
✅ npm workspaces (via package.json workspaces)
✅ Rush (via rush.json)
✅ Lerna (via lerna.json)
# Project structure
my-monorepo/
├── packages/
│ ├── app/tsconfig.json
│ ├── server/tsconfig.json
│ ├── db/tsconfig.json
│ └── shared/tsconfig.json
├── pnpm-workspace.yaml
└── tsconfig.base.json
# Auto-detected configs:
# - @myapp/app
# - @myapp/server
# - @myapp/db
# - @myapp/sharedAgents can query specific packages:
Tool: get_package_diagnostics
Args: { "packageName": "@myapp/server" }Scenario: 4 AI agents working on a TypeScript monorepo
Method | Time | CPU Usage | Result |
Running | ~45s total | 100% spike | System lag |
Using ts-diagnostics-mcp | ~2.3s first, <50ms cached | <15% steady | Smooth |
Performance Gains:
95%+ reduction in type-check time (cached queries)
80%+ reduction in CPU usage
Near-instant feedback for agents
┌─────────────────────────────────────────────────┐
│ AI Agents (Claude, GPT, etc.) │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │Agent1│ │Agent2│ │Agent3│ │Agent4│ │
│ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ │
└─────┼────────┼────────┼────────┼──────────────┘
│ │ │ │
└────────┴────────┴────────┘
│ MCP Protocol
┌────────▼──────────────────┐
│ ts-diagnostics-mcp │
│ ┌─────────────────────┐ │
│ │ Query Router │ │
│ │ (Package Filter) │ │
│ └─────────┬───────────┘ │
│ ┌─────────▼───────────┐ │
│ │ LRU Cache Layer │ │
│ │ (100MB default) │ │
│ └─────────┬───────────┘ │
│ ┌─────────▼───────────┐ │
│ │ TypeScript Watch │ │
│ │ (Compiler API) │ │
│ └─────────┬───────────┘ │
└────────────┼───────────────┘
│
┌────────────▼───────────────┐
│ TypeScript Source Files │
│ (Auto-recompiles) │
└────────────────────────────┘# Install dependencies
pnpm install
# Build
pnpm build
# Development mode (watch)
pnpm dev
# Type check
pnpm typecheck# Build the MCP server
cd ts-diagnostics-mcp
npm install
npm run build
# Run directly with your project
node dist/index.js /path/to/your/typescript/projectCheck if the watch process is active:
Tool: get_watch_statusReduce cache size:
export TS_DIAG_MAX_CACHE_SIZE=50Clear the cache to force refresh:
Tool: clear_cacheContributions welcome! This is an open-source project.
Fork the repository
Create a feature branch
Make your changes
Submit a pull request
MIT License - see LICENSE file for details
Built with:
Issues: GitHub Issues
Discussions: GitHub Discussions
Made with ❤️ for AI agents working in TypeScript
Clear cached diagnostics. Optionally clear cache for a specific file only.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | No | Optional: Path to specific file to clear from cache |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. While it states clearing cache, it omits behavioral details like whether this is reversible, if it affects ongoing diagnostics collection, or performance impact. The optional file-specific mode is mentioned but not elaborated.
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?
Efficient two sentences, front-loaded with main purpose. No redundant content.
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 is minimally adequate. However, given the absence of annotations and the destructive nature, it could provide more context about side effects or safe 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 100% with filePath described. The description adds only the word 'optional' which is already implied by the schema's required: []. No new parameter meaning 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 communicates the action (clear) and subject (cached diagnostics), and distinguishes from sibling tools that are read-only (get_*, has_*) or stats-related. The optional file-specific clearing is also noted.
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, such as waiting for cache invalidation or using other diagnostics tools. The description lacks context about prerequisites or trade-offs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all TypeScript diagnostics from all watched projects. Returns errors, warnings, and suggestions with file locations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states the return content (errors, warnings, suggestions with file locations) but does not mention potential performance implications, whether it triggers compilation, or if it is read-only. Adequate but not comprehensive.
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: the first states the action, the second describes the content. Every word adds value, and no unnecessary details are present.
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 no parameters and no output schema, the description covers the purpose and return type adequately. It is complete enough given the simplicity, though it could mention if the tool is read-only or has side effects.
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 the description does not need to compensate for missing parameter details. Baseline score of 4 is appropriate as it provides no parameter-specific information but none is required.
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 retrieves all TypeScript diagnostics from all watched projects, specifying the types of diagnostics (errors, warnings, suggestions) and that they include file locations. This distinguishes it from sibling tools like get_file_diagnostics and get_diagnostic_count.
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 broad usage for getting all diagnostics across projects, but lacks explicit guidance on when to prefer this over siblings like get_file_diagnostics or get_package_diagnostics. No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cache performance statistics including hit rate, size, and evictions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description indicates it is a read operation with no side effects, which matches common expectations. However, no annotations exist to confirm safety, and the description does not mention authorization or performance impact beyond basic 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?
Single sentence that is direct and informative. No filler or 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?
Description covers the tool's purpose and data returned, but given no output schema, additional details on exact output format or pagination would be beneficial for a complete picture.
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 exist (0 params), so the description is not required to explain them. Schema coverage is 100% trivially. Description adds no param info, but baseline for 0 params is 4.
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?
Explicitly states it retrieves cache performance statistics and lists specific metrics (hit rate, size, evictions). Clearly distinguishes from sibling tools like clear_cache (delete) and diagnostics 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?
No guidance on when to use this tool versus alternatives like get_all_diagnostics or get_watch_status. Does not mention prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get summary counts of errors, warnings, and suggestions. Faster than getting full diagnostics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only mentions speed but does not explicitly state that the tool is read-only, non-destructive, or any other traits. For a query tool, this is a gap.
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 13 words, highly concise, and front-loaded with the key 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 zero parameters and no output schema, the description covers the main purpose and speed advantage. However, it could be more complete by indicating the output format (e.g., counts per severity). Still, it is adequate for a low-complexity tool.
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?
There are no parameters in the input schema, and schema description coverage is 100% (trivially). With 0 parameters, the baseline is 4, and the description does not need to add parameter info.
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 verb 'Get summary counts' and the resource 'errors, warnings, and suggestions', and distinguishes itself from sibling 'get_all_diagnostics' by noting it's faster.
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 context for when to use this tool ('Faster than getting full diagnostics') but does not explicitly state when not to use it or mention alternatives beyond the implied comparison with get_all_diagnostics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get TypeScript diagnostics for a specific file. Much faster than running tsc on the whole project.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the TypeScript file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it gets diagnostics but does not disclose what diagnostics include (e.g., errors, warnings) or any side effects. Adds speed disclaimer but lacks depth.
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, no unnecessary words, front-loaded with the core purpose.
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 simple one-parameter tool without output schema. Explains purpose and speed advantage but lacks details on return format or potential errors.
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 provides complete description of the single parameter 'filePath' (100% coverage). Description does not add extra meaning 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?
Description clearly states it gets TypeScript diagnostics for a specific file and highlights its speed advantage over running tsc on the whole project, distinguishing it from sibling tools like get_all_diagnostics.
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?
Implicitly suggests use when needing diagnostics for a single file quickly, but lacks explicit when-not or alternative guidance. The sibling list provides context but the description itself doesn't direct to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get TypeScript diagnostics for a specific package in a monorepo. Useful for filtering diagnostics by workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| packageName | Yes | Name of the package (e.g., "@degentalk/server") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It only states the basic function without disclosing side effects, prerequisites, error behavior, or response format.
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 with no wasted words, front-loaded with the tool's purpose.
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 lack of output schema and annotations, the description fails to explain what the diagnostics output looks like, error cases, or how it relates to other diagnostic tools. The provided context is insufficient for correct 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 description coverage is 100%, with the parameter clearly documented. The tool description does not add additional meaning beyond the schema, so baseline 3 is appropriate.
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 explicitly states the verb 'Get' and the resource 'TypeScript diagnostics for a specific package', and distinguishes from siblings like get_all_diagnostics by focusing on a single package.
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 indicates it is 'useful for filtering diagnostics by workspace', providing clear context for when to use. It does not explicitly state when not to use, but the sibling tools imply alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get status of the TypeScript watch process including watched configs, file count, and last compilation time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns status information including watched configs, file count, and last compilation time, which implies a read-only operation. However, it does not explicitly state non-destructiveness or potential edge cases.
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 effectively front-loads the action and result, with no redundant or extraneous words. Every phrase contributes to understanding.
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 provides sufficient context about the return value (watched configs, file count, compilation time). It could mention if the tool is synchronous or what happens if no watch is active, but it is largely complete for a zero-parameter tool.
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 schema coverage is 100% (trivially). The description adds value by explaining what the returned status contains, which is more than the schema provides. Baseline for zero params is 4.
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 verb 'Get' and resource 'status of the TypeScript watch process', and specifies what is included (configs, file count, compilation time). This distinguishes it from sibling tools like get_all_diagnostics or clear_cache, which focus on different aspects.
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 the tool is for checking watch process status, but does not provide explicit guidance on when to use it versus alternatives, nor does it mention any prerequisites or exclusions. The purpose is clear enough for straightforward use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quick boolean check if there are any TypeScript errors. Optionally check a specific file. Extremely fast - use this before full diagnostic queries.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | No | Optional: Path to specific file to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions speed and optional file check, but does not specify return value (true/false meaning) or scope (e.g., all files vs. project). Adequate but not fully transparent.
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?
Extremely concise: two sentences with no redundancy. Every word adds value, clearly conveying purpose and usage hint.
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 boolean check with one optional parameter, the description is largely sufficient. Minor gap: does not explicitly state that return is true if errors exist, false otherwise. Overall complete for the tool's simplicity.
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% and already describes filePath as optional. Description adds marginal context ('Optionally check a specific file') but does not significantly enhance 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?
Clearly states it's a quick boolean check for TypeScript errors, with optional file-specific check. Distinguishes from sibling tools by emphasizing speed and simplicity vs. full diagnostic queries.
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 recommends using this before full diagnostic queries, providing clear usage context. Could be improved by listing alternative tools for specific scenarios, but the current guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all packages in the monorepo that are being watched. Useful for discovering available package names.
| Name | Required | Description | Default |
|---|---|---|---|
No 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 that only 'watched' packages are listed, which is a behavioral constraint. For a simple read tool with no parameters, this is adequate, though it does not discuss safety 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 two sentences long, concise, and front-loaded with the core action and purpose. Every word adds value; there is no fluff or 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 is simple with no parameters and no output schema. The description explains what it does but does not specify the return format (e.g., an array of package names). Given the simplicity, it is mostly complete, but a minimal mention of output would improve 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?
The tool has zero parameters, so there is no need for parameter documentation. The description does not need to add meaning beyond the schema, which already covers 100% of 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 'List all packages' and specifies the resource 'in the monorepo that are being watched', making the purpose unambiguous. It also includes a use case 'discovering available package names', which distinguishes it from sibling tools like 'get_package_diagnostics'.
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 'Useful for discovering available package names' provides clear context for when to use this tool. However, it does not explicitly state when not to use it or mention alternatives, though no direct alternative exists among siblings.
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.1.0clear_cacheget_all_diagnosticsget_cache_statsget_diagnostic_countget_file_diagnosticsget_package_diagnosticsget_watch_statushas_errorslist_packagesEach tool has a clearly distinct purpose: retrieving diagnostics by scope (all, file, package), counting, quick boolean check, cache management, cache stats, watch status, and package listing. No overlap.
All tool names follow a verb_noun pattern in snake_case (e.g., get_all_diagnostics, clear_cache, has_errors, list_packages), which is consistent and predictable.
Nine tools cover the key operations for a TypeScript diagnostics server without being excessive. The scope is well-balanced – enough to be useful but not overwhelming.
The tool surface covers all essential operations: retrieving diagnostics at various levels, cache management, status monitoring, and package discovery. No obvious gaps for the intended purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Serves your design system and coding standards to coding agents, so they stop guessing.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/GNARC0TICS/ts-diagnostics-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
