agent-workspace-mcp

by c0sc0s

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3.1/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![agent-workspace-mcp MCP server](https://glama.ai/mcp/servers/c0sc0s/agent-workspace-mcp/badges/card.svg)](https://glama.ai/mcp/servers/c0sc0s/agent-workspace-mcp)

Score Badge

Copy to your README.md:

[![agent-workspace-mcp MCP server](https://glama.ai/mcp/servers/c0sc0s/agent-workspace-mcp/badges/score.svg)](https://glama.ai/mcp/servers/c0sc0s/agent-workspace-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/c0sc0s/agent-workspace-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server