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., "@project-knowledge-mcp show me the full workflow for the user login feature across all projects"
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.
A cross-project knowledge graph for the Model Context Protocol (MCP). Map features across mobile, backend, and admin codebases so your AI agent has full-stack context when testing, writing code, debugging, or adding features.
npx -y project-knowledge-mcp --knowledge-file ./project-knowledge.jsonThen add to your MCP settings:
{
"mcpServers": {
"project-knowledge": {
"command": "npx",
"args": [
"-y",
"project-knowledge-mcp",
"--knowledge-file", "C:\\projects\\project-knowledge.json"
],
"autoApprove": []
}
}
}Related MCP server: OpenCodeHub MCP Server
When working on a project with multiple codebases — for example, a React Native mobile app, a NestJS backend, and a Next.js admin panel — the AI agent has no awareness of how a single feature flows across all three. This leads to incomplete context, missed dependencies, and breaking changes that could have been caught earlier.
This MCP server stores a knowledge graph of your features, mapping each workflow step to the relevant screens, endpoints, controllers, and files in every project. The AI agent can then query this graph to understand end-to-end feature flows, detect cross-project impacts before editing files, and keep type definitions synchronized across codebases.
Multi-project awareness — register any number of projects (mobile, backend, admin, etc.)
Feature workflow mapping — define features as ordered steps across all projects
Auto-scanning — discover NestJS endpoints, Next.js pages, and React Native screens automatically
Full-text search — search across features, endpoints, files, and screens
Cross-reference lookup — given a file path, find which features reference it
Rich context — retrieve all endpoints, screens, and files for a feature at a specific workflow step
Breaking change detection — before editing a file, see which other projects will be affected
Type/schema synchronization — map equivalent types across projects (e.g., ProductCreateDto ↔ ProductFormSchema)
Architecture exploration — browse any project's directory tree with keyword filtering and content highlighting
Health validation — verify that all registered file paths still exist; auto-detect stale entries
Persistent knowledge — auto-saves to a JSON file after every mutation; can be git-tracked and shared
100% dynamic — all configuration via CLI arguments and runtime tools; no source code edits required
Node.js >= 18
npm >= 9 (or pnpm / yarn equivalent)
An MCP-compatible client (e.g., VS Code with Cline, any AI-powered IDE)
npm install --save-dev project-knowledge-mcpOr run directly without installing:
npx -y project-knowledge-mcp --knowledge-file ./project-knowledge.jsongit clone https://github.com/punic-pillars/project-knowledge-mcp.git
cd project-knowledge-mcp
npm install
npm run buildAll configuration is provided via CLI arguments. No environment variables or configuration files are required.
Flag | Description | Default |
| Absolute path to the backend project | — |
| Backend framework ( |
|
| Custom name for the backend project |
|
| Absolute path to the mobile project | — |
| Mobile framework |
|
| Custom name for the mobile project |
|
| Absolute path to the admin project | — |
| Admin framework |
|
| Custom name for the admin project |
|
| Absolute path to persist the knowledge JSON |
|
Basic setup — register projects at runtime via tools:
{
"mcpServers": {
"project-knowledge": {
"command": "npx",
"args": [
"-y",
"project-knowledge-mcp",
"--knowledge-file", "C:\\projects\\project-knowledge.json"
],
"autoApprove": []
}
}
}Bootstrap setup — pre-register projects at startup:
{
"mcpServers": {
"project-knowledge": {
"command": "npx",
"args": [
"-y",
"project-knowledge-mcp",
"--knowledge-file", "C:\\projects\\project-knowledge.json",
"--backend-path", "C:\\projects\\backend",
"--mobile-path", "C:\\projects\\mobile",
"--admin-path", "C:\\projects\\admin"
],
"autoApprove": []
}
}
}The knowledge file is a plain JSON file that stores all registered projects, feature workflows, and type mappings. Understanding where it lives is essential for maintaining a consistent knowledge graph.
If your fullstack projects live in separate directories (e.g., backend/, mobile/, admin/), each IDE window starts the MCP server from a different working directory. Without --knowledge-file, each instance creates its own fragment:
backend/
└── project-knowledge.json ← only backend context
mobile/
└── project-knowledge.json ← only mobile context
admin/
└── project-knowledge.json ← only admin contextThis defeats the purpose of cross-project awareness. Always use --knowledge-file with an absolute path to point all IDE windows to the same file:
projects/
├── project-knowledge.json ← single source of truth
├── backend/
├── mobile/
└── admin/Use the same --knowledge-file path in every IDE window, regardless of which sub-project you have open. All instances read and write to the same file, keeping the knowledge graph complete and consistent.
The default path (no --knowledge-file) is only safe when you open the monorepo root — the single directory containing all sub-projects:
my-monorepo/ ← open this in your IDE
├── project-knowledge.json ← created here, covers everything
├── backend/
├── mobile/
└── admin/If your projects are in separate repositories or directories, always use --knowledge-file.
Since the knowledge file is plain JSON, you can commit it to version control and share it with your team:
# Track the knowledge graph
git add project-knowledge.json
git commit -m "chore: add project knowledge graph"
# Or keep it local
echo "project-knowledge.json" >> .gitignoreGuideline: One fullstack project = one knowledge file. Use
--knowledge-filewith an absolute path whenever your projects live in separate directories.
Tool | Description |
| Register a project with name, path, and framework |
| Remove a registered project |
| Auto-discover endpoints, screens, or pages from a project |
Tool | Description |
| Define a feature with its multi-project workflow steps |
| Remove a feature |
| Retrieve full feature details (compact or verbose, with optional health check) |
Tool | Description |
| Search across features, endpoints, files, and screens |
| Find all cross-project references to a file (graph-registered + scan-discovered), plus which features reference it |
| Retrieve cross-project context for a feature or step (with optional impact analysis) |
Tool | Description |
| Register one or more type mappings (accepts single object or array) |
| Find all files across projects that define or reference a type |
| Auto-detect potential type mappings by scanning all projects |
Tool | Description |
| Explore a project's directory tree with optional |
Tool | Description |
| Check all registered file paths for stale entries; optionally auto-fix with |
Tool | Description |
| Confirm the knowledge file path and trigger an explicit save (auto-persist handles this after every mutation) |
| Load knowledge from a JSON file (merge or replace, with preview) |
This walkthrough demonstrates the core workflow using a real multi-project setup (NestJS backend, React Native mobile, Next.js admin panel). Domain names have been anonymized — "products" instead of "stations", "orders" instead of "reports" — but every command shown was run against actual projects.
register_project { name: "backend", path: "C:/projects/backend", framework: "nestjs" }
register_project { name: "mobile", path: "C:/projects/mobile", framework: "react-native" }
register_project { name: "admin", path: "C:/projects/admin", framework: "auto" }Discover endpoints, screens, and pages automatically:
scan_project { projectName: "backend" }
scan_project { projectName: "mobile" }
scan_project { projectName: "admin" }The scanners discover 150+ endpoints, 200+ screens, and multiple admin pages across all registered projects.
Register an auth feature — a straightforward flow that touches all three projects:
register_feature {
name: "auth",
description: "Authentication flow — login, register, forgot password, email confirmation",
workflow: [
{
step: 1, name: "Login",
description: "User logs in with email and password",
mobile: { screen: "LoginScreen", api: "POST /api/v1/auth/email/login" },
backend: { endpoint: "POST /api/v1/auth/email/login", controller: "AuthController", file: "src/auth/auth.controller.ts" },
admin: { page: "/login", file: "src/pages/Login" }
},
{
step: 2, name: "Register",
description: "User registers a new account",
mobile: { screen: "RegisterScreen", api: "POST /api/v1/auth/email/register" },
backend: { endpoint: "POST /api/v1/auth/email/register", controller: "AuthController", file: "src/auth/auth.controller.ts" }
},
{
step: 3, name: "Email Confirmation",
description: "Confirm email address",
mobile: { api: "POST /api/v1/auth/email/confirm" },
backend: { endpoint: "POST /api/v1/auth/email/confirm", controller: "AuthController", file: "src/auth/auth.controller.ts" }
},
{
step: 4, name: "Forgot Password",
description: "Request password reset",
mobile: { screen: "ForgotPasswordScreen", api: "POST /api/v1/auth/forgot/password" },
backend: { endpoint: "POST /api/v1/auth/forgot/password", controller: "AuthController", file: "src/auth/auth.controller.ts" }
},
{
step: 5, name: "Reset Password",
description: "Reset password with token",
mobile: { screen: "ResetPasswordScreen", api: "POST /api/v1/auth/reset/password" },
backend: { endpoint: "POST /api/v1/auth/reset/password", controller: "AuthController", file: "src/auth/auth.controller.ts" }
}
],
test_scenarios: [
"Login with valid credentials returns token",
"Login with invalid email returns 401",
"Register with existing email returns conflict",
"Forgot password sends email",
"Reset password with valid token works"
]
}Compact mode — get a summary:
get_feature { name: "auth" }Returns: 5 steps, 5 test scenarios, mobile=5 screens, backend=5 endpoints, admin=1 page.
Verbose mode — get full workflow details:
get_feature { name: "auth", verbose: true }Returns all 5 steps with full mobile screens, backend endpoints, controllers, and file paths.
With health check — verify all registered paths exist:
get_feature { name: "auth", includeHealth: true }Returns: Health: 5/5 backend ok, mobile=5/5, admin=1/5, 5 test scenarios.
Search across the knowledge graph:
search { query: "product" }Returns 100+ results across features, workflow steps, backend mappings, mobile mappings, type mappings, and file contents.
Find cross-project references to a file:
reverse_lookup { filePath: "auth.controller.ts" }Returns:
Feature associations: Which features reference this file (steps 1–5 of the auth feature)
Graph-registered: 5 exact matches (steps 1–5 of the auth feature, all backend), plus the admin Login page
Scan-discovered: All files across all projects that import or reference auth.controller.ts
Register a cross-project type mapping:
register_type_mappings {
mapping: {
typeName: "productId",
sourceProject: "backend",
sourceFile: "src/products/infrastructure/persistence/relational/entities/product.entity.ts",
targetProject: "mobile",
targetFile: "app/_types/ProductTypes.ts",
description: "Standardizing productId as numeric INTEGER across all projects"
}
}Check what references a type before changing it:
check_type_mapping { typeName: "productId" }Returns all files across all projects that define or reference productId.
Auto-discover potential type mappings:
suggest_type_mappings { limit: 5, confidence: "high" }Scans all registered projects and finds exact type name matches — returns suggestions with source and target file paths ready to register.
Validate knowledge health:
validate_knowledgeChecks all registered file paths across all features and type mappings. Returns a report of existing and missing entries.
Confirm persistence:
The knowledge graph is auto-persisted after every mutation — register_project, register_feature, register_type_mappings, and validate_knowledge with fix=true all write to disk immediately. Use export_knowledge to confirm the file path before committing to version control:
export_knowledgeReturns the path to the knowledge file. Git-track this file to share context with your team.
Knowledge file is plain JSON — you control where it is stored and who has access
No credentials stored — this MCP only stores project paths and feature mappings
File scanning is read-only — scanners only read files, never modify them
Contributions are welcome. Please open an issue or pull request for any improvements, bug fixes, or feature requests.
Given a type name, find all files across all projects that define or reference it. Use this BEFORE changing a type to know exactly which files in which projects need updating. For example: check_type_mapping('stationId') returns all files in backend, mobile, and admin that use stationId.
| Name | Required | Description | Default |
|---|---|---|---|
| typeName | Yes | Type name to search for (e.g., 'stationId', 'StationCreateDto', 'User') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It transparently states the scan scope ('all files across all projects') and gives a concrete example of the return content. It doesn't explicitly say the tool is read-only, but the query nature implies no side effects.
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 with an embedded example, delivering the essential information without any fluff. It is front-loaded with the core action and then adds usage context.
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 single-parameter tool with no output schema, the description provides sufficient context: what it does, when to use it, and a representative result. It doesn't detail exact return formatting, but the example implies the nature of the result, which is adequate.
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 already fully documents the only parameter 'typeName' with examples. The description adds a few additional examples in context, but does not significantly extend the parameter's meaning beyond what the schema provides. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: given a type name, find all files across all projects that define or reference it. This specific verb+resource (find files for type) distinguishes it from siblings like suggest_type_mappings or reverse_lookup by emphasizing impact analysis.
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 explicitly instructs to use this tool 'BEFORE changing a type' and explains the benefit (knowing which files need updating). It does not mention when not to use it or alternative tools, but the situational guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the current knowledge base to the configured JSON file. Note: the knowledge base is auto-persisted after every mutation, so this call is not required to save your work. Use it as an explicit confirmation — it returns the file path so you know where the file lives before committing to git.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It reveals that the knowledge base is auto-persisted after every mutation, making this call redundant, and states it returns the file path. This is non-obvious context that helps the agent decide whether to call 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?
The description is two sentences with no wasted words. It front-loads the purpose and immediately adds the caveat.
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, parameterless export tool with no output schema, this description covers what it does, when to use it, and what it returns. It is complete for the tool's 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?
The tool has zero parameters, so schema coverage is 100%. The description does not need to explain parameters, and it doesn't; the baseline of 4 applies.
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 'Save the current knowledge base to the configured JSON file' with a specific verb and resource. It also distinguishes from siblings by noting it's an explicit confirmation rather than a necessary save, giving unique purpose.
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?
It explicitly says 'this call is not required to save your work' and provides guidance on when to use it: 'as an explicit confirmation — it returns the file path so you know where the file lives before committing to git.' This tells the agent when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explore a registered project's directory structure as a formatted tree view. Use this to understand the project layout, find relevant files, or navigate the codebase. Supports optional filtering by path keyword, and optional content highlighting to find files containing a specific keyword (marked with ★). When using highlight, set showAll=true to see the full tree with matches marked, or omit showAll (default false) to show only matching files.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional keyword — only show files/folders whose path contains this keyword (case-insensitive) | |
| showAll | No | When used with highlight: if true, show the full tree but mark matching files with ★. If false (default), only show matching files. | |
| highlight | No | Optional keyword — scan file contents and mark files containing this keyword with ★ | |
| projectName | Yes | Name of the registered project to explore |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does a good job: it explains the formatted tree view output, how filter and highlight work, and the exact showAll behavior with ★ markers. It doesn't explicitly state non-destructiveness, but 'explore' implies 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?
The description is three sentences long, each earning its place: purpose, use case, and parameter behavior. It is front-loaded with the primary action and avoids any fluff or repetition of schema 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?
Despite having no output schema or annotations, the description fully explains what the tool returns (tree view, ★ markers) and how to control output via parameters. It covers all 4 parameters and their relationships, making it sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3. The description goes further by explaining how showAll interacts with highlight, and how filter and highlight differ (path vs content), adding meaningful contextual meaning beyond the field-level descriptions.
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 opens with a specific verb+resource: 'Explore a registered project's directory structure as a formatted tree view.' This clearly distinguishes the tool from siblings like search or scan_project, and states its purpose in practical terms (understand layout, find files, navigate codebase).
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 says 'Use this to understand the project layout, find relevant files, or navigate the codebase,' giving clear contexts for usage. It does not explicitly compare against alternatives or state when not to use it, but the use-case framing is strong enough for most situations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get rich cross-project context for a feature at a specific workflow step. Returns all relevant endpoints, screens, pages, and files across all projects. Use this before testing or implementing a feature step. Set analyzeImpact=true to also check for breaking changes across projects. Set verbose=true for full per-step breakdown (default: compact summary).
| Name | Required | Description | Default |
|---|---|---|---|
| verbose | No | If true, return full per-step breakdown with endpoints/screens/pages. If false (default), return a compact summary. | |
| stepNumber | No | Workflow step number (optional — returns all steps if omitted) | |
| featureName | Yes | Feature name | |
| analyzeImpact | No | If true, also run a breaking change analysis on files referenced in the context. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It explains what is returned (endpoints, screens, pages, files) and how the analyzeImpact and verbose flags modify behavior. However, it does not explicitly state that the tool is read-only, nor does it mention side effects, auth requirements, or rate limits. The behavioral transparency is adequate but not rich.
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 three sentences long, with the primary purpose front-loaded. Every sentence contributes essential information: what it does, when to use it, and how to control output. There is zero 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?
The description covers the tool's purpose, usage, output type (endpoints, screens, pages, files), and optional behavior (analyzeImpact, verbose). It does not provide a detailed return structure, but no output schema exists, and the overview is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description goes beyond the schema by explaining the purpose of analyzeImpact ('check for breaking changes') and verbose ('full per-step breakdown') in the context of the tool's workflow. This adds meaningful semantic context, warranting a 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 uses a specific verb ('Get') and resource ('rich cross-project context for a feature at a specific workflow step'). It clearly differentiates from sibling tools like get_feature (which likely fetches a single feature) and search (which might search broadly) by emphasizing cross-project context and workflow steps.
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 explicitly states when to use the tool: 'Use this before testing or implementing a feature step.' This provides clear contextual guidance. However, it does not explicitly mention alternative tools or when not to use it, so it stops short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a feature — all workflow steps with cross-project mappings. Use this to understand how a feature works end-to-end before testing or coding. Set includeHealth=true to also run a health check on the feature. Set verbose=true for full workflow step details (default: compact summary).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Feature name | |
| verbose | No | If true, return full workflow step details. If false (default), return a compact summary. | |
| includeHealth | No | If true, also run a health check and append results to the output. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: the tool returns workflow steps and cross-project mappings, supports an optional health check (includeHealth), and toggles between compact and full summaries (verbose). It does not mention error handling or auth, but the disclosed behaviors cover the main usage patterns.
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, front-loaded with the core purpose, and each sentence adds necessary context (use case and parameter guidance). There is no fluff, making it highly efficient.
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?
No output schema exists, so the description should explain return values. It mentions 'full details' and 'compact summary' but does not specify the structure or content of the response (e.g., fields, format). Given the tool's moderate complexity and missing output schema, the description is adequate but not fully complete.
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%, so parameters are fully documented. The description adds minimal extra meaning beyond the schema, merely restating the effect of verbose and includeHealth. It does not clarify parameter syntax or edge cases, but the schema already handles the basics, earning a baseline 3.
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 uses a specific verb 'Get' with a clear resource 'full details of a feature' and adds scope 'all workflow steps with cross-project mappings'. This clearly distinguishes it from sibling tools like get_context or scan_project, making the purpose unambiguous.
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 states 'Use this to understand how a feature works end-to-end before testing or coding', providing a clear when-to-use context. It does not explicitly mention exclusions or alternatives, but the usage context is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load knowledge from a JSON file. Can merge with existing data or replace it entirely. When merge=false, the current state is auto-backed up before overwriting. Set preview=true to see a diff of what would change without actually importing.
| Name | Required | Description | Default |
|---|---|---|---|
| merge | No | If true, merge with existing data. If false, replace. | |
| preview | No | If true, show a diff of what would change without actually importing. Use this to preview before applying. | |
| filePath | Yes | Absolute path to the JSON knowledge file to import |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses important behaviors: auto-backup when merge=false, and preview mode that shows a diff without importing. It doesn't cover error handling or return values, but the key side effects are explained.
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?
Three concise sentences, each providing essential information. Front-loaded with the core action, followed by merge/replace options and backup/preview behaviors. No unnecessary words.
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 description covers the tool's core functionality, parameter semantics, and side effects adequately for a simple import tool. No output schema exists, but the description doesn't explain return values; however, this is not critical since the tool's primary output is the state change itself.
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%, but the description adds meaningful context beyond the schema by explaining the backup side effect when merge=false and the purpose of preview mode. This enriches the parameter semantics.
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 loads knowledge from a JSON file, with specific merge/replace behavior. This distinguishes it from siblings like export_knowledge (which exports) and validate_knowledge (which validates).
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 clear context for use: importing knowledge from a JSON file, with options to merge or replace, and a preview mode to check before applying. It doesn't explicitly mention when not to use it or alternatives, so it loses one point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Define or update a feature with its multi-project workflow steps. Each step maps what happens in mobile, backend, and admin. Steps are ordered — the AI will use this order to understand user flows. Use overwrite=true to replace an existing feature.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Feature name (e.g., 'report', 'stations', 'auth') | |
| workflow | Yes | Ordered list of workflow steps. Each step describes what happens in mobile, backend, and/or admin at that point in the flow. | |
| overwrite | No | If true, overwrite an existing feature with the same name. If false (default), error if feature already exists. | |
| description | Yes | What this feature does end-to-end | |
| test_scenarios | No | List of test scenarios for this feature |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It transparently states that steps are ordered and that the AI will use this order to understand flows, and informs about overwrite semantics. It does not mention side effects like validation or persistence, but the 'Define or update' phrasing implies mutation, and the overwrite guidance adds practical behavior. No contradictions.
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 three sentences, front-loaded with the action, and every sentence earn its place: defining the resource, explaining the key structure, and providing the critical overwrite guidance. No filler or redundant information.
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 complex (nested workflow array, optional test_scenarios, overwrite logic), but the description covers the core usage and ordering behavior. The schema provides extensive parameter docs, and the description highlights the AI's use of order. It could mention that project names must be pre-registered, but this is in the schema's project description. Overall, adequate for the complexity level.
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%, so baseline is 3. The description adds value by explaining the workflow parameter's semantics ('Each step maps what happens in mobile, backend, and admin') and the overwrite parameter's purpose ('Use overwrite=true to replace an existing feature'). This goes slightly beyond the schema, but doesn't cover all parameters like test_scenarios, though those are well-documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Define or update' with resource 'a feature with its multi-project workflow steps', immediately distinguishing it from sibling tools like remove_feature and get_feature. It also specifies the key structure (steps mapped to mobile/backend/admin), making the tool's purpose unambiguous.
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 explains that the tool can both create and update features, and explicitly mentions the overwrite=true flag for replacing existing features. It does not mention when to prefer this over other tools, but the purpose is clear enough that usage context is implied. Lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a project (mobile, backend, admin) so the MCP knows its path and framework. Framework can be 'nestjs', 'nextjs', 'react-native', or 'auto' for auto-detection.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Short name (e.g., 'backend', 'mobile', 'admin') | |
| path | Yes | Absolute path to the project directory | |
| framework | No | 'nestjs', 'nextjs', 'react-native', or 'auto' | auto |
| description | No | Optional description of the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It explains the effect ('so the MCP knows its path and framework') and lists valid framework values, including auto-detection. However, it does not mention persistence, potential side effects, or what happens if registration fails or is repeated, leaving some behavioral gaps.
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: the first states the purpose, the second lists allowed framework values. It is concise, front-loaded, and every sentence provides useful information without waste.
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 description covers the tool's purpose, input parameters' meaning (via schema and added examples), and valid framework choices. It does not mention error behavior, idempotency, or return values, but for a simple registration tool with well-documented parameters, it is mostly complete. Sibling tools indicate this is part of a larger project management context.
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%, so the schema already explains all parameters. The description adds a bit of context by framing name examples ('backend', 'mobile', 'admin') and reaffirming the framework enum values. This is helpful but does not significantly go beyond the schema, so a 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 uses a specific verb ('Register') with a clear resource ('project') and provides concrete examples of project types (mobile, backend, admin). It also distinguishes the tool from siblings like remove_project and scan_project by focusing on making the MCP aware of the project's path and framework.
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 clearly states the tool's purpose: register a project so the MCP knows its path and framework. It implies use when you need to add a project to MCP's knowledge, but does not explicitly mention when not to use it or provide alternative tools, though the sibling list shows distinct operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register one or more type mappings between projects. Accepts either a single mapping object OR an array of mappings. For example, if 'StationCreateDto' in the backend corresponds to 'StationFormSchema' in mobile, register that mapping here. Then when you change one, you can check what else needs updating. When registering multiple mappings, this reduces 50+ tool calls to 1, providing massive token savings.
| Name | Required | Description | Default |
|---|---|---|---|
| mappings | Yes | Array of type mapping objects to register (or pass a single mapping object directly) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a write operation ('register') but does not disclose side effects such as persistence semantics, duplicate handling, prerequisites (e.g., whether projects must be pre-registered), idempotency, or what happens on failure. This is a significant gap for a mutation 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?
Four sentences each earn their place: purpose, input flexibility, a concrete example, and a clear benefit. It is front-loaded and concise, with no fluff. The structure flows naturally from what to how to why.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must cover return values, error conditions, and behavioral nuances. It does not mention what the tool returns, whether it overwrites existing mappings, or whether it requires pre-existing projects. For a mutation tool, these gaps make the description incomplete.
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 schema already covers 100% of parameter details, including the ability to pass a single mapping object or array via the mappings parameter description. The tool description adds a clarifying example but no new semantic meaning beyond what the schema provides. Thus, 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 begins with a clear verb+object: 'Register one or more type mappings between projects.' It distinguishes from sibling tools like suggest_type_mappings and check_type_mapping by explicitly framing this as the action to record known mappings. The example with StationCreateDto/StationFormSchema makes the purpose concrete.
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 clear context for when to use: 'Then when you change one, you can check what else needs updating.' It also highlights the batch efficiency benefit, implying use when registering multiple mappings. However, it does not explicitly mention alternatives or when NOT to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a feature from the knowledge base.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Feature name to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior. It only says 'remove' without explaining whether removal is permanent, cascades to dependent entities, requires special permissions, or is reversible. This is a significant gap for a destructive operation.
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 with no extraneous words. It is front-loaded with the action and target, making it easy to parse. There is 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?
For a destructive tool with no annotations and no output schema, the description is too sparse. It fails to mention consequences, error conditions, or what happens after removal. The schema only explains the parameter, leaving the operational context incomplete.
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 already provides 100% coverage, including a description for the only parameter ('Feature name to remove'). The tool description adds no further meaning to the parameter, but baseline 3 is appropriate because the schema handles the semantics adequately.
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 (remove) and the target resource (a feature from the knowledge base). It distinguishes itself from sibling tools like remove_project and aligns with register_feature/get_feature. The scope is specific enough for an agent to know when to use it.
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 gives no guidance on when to use this tool versus alternatives such as remove_project or other feature-related tools. It does not mention prerequisites, side effects, or conditions under which removal is appropriate. An agent would have to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a registered project from the knowledge base.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the project to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It only says 'remove' without explaining whether the removal is permanent, whether related data is affected, or any permission requirements. This is insufficient for a destructive operation.
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, direct sentence with no filler. It efficiently conveys the purpose and is well-structured.
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 one parameter and no output schema, but the description lacks any detail about return behavior, side effects, or reversibility. It adequately states the action but is not fully complete for a destructive operation with no annotations.
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 already documents the sole parameter 'name' with a clear description, giving 100% schema coverage. The description adds no additional semantic information about the parameter, so it meets the baseline but provides no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function using the verb 'Remove' and specifies the resource ('registered project') and context ('knowledge base'). This distinguishes it from siblings like remove_feature and register_project.
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 projects already in the knowledge base (via 'registered'), but it provides no explicit guidance on when to use it versus alternatives, nor any prerequisites or exclusions. It's a basic statement with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a file path, find all cross-project references to it — both from the Knowledge Graph and by scanning import/require/type-usage in file contents across all registered projects. Use this before editing a file to understand its full blast radius, even when the graph is incomplete. Returns two labeled buckets: graph-registered (formally tracked) and scan-discovered (found ad hoc). Also shows which features and workflow steps reference this file.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Relative path to the file within its project (e.g., 'src/auth/auth.controller.ts') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels: it discloses that the tool performs both graph lookups and ad-hoc scans of imports/requires/type-usages, returns two labeled buckets, and also reports feature/workflow references. It even notes it works when the graph is incomplete, giving a thorough behavioral picture.
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 three focused sentences, front-loaded with the core action. Each sentence adds distinct value: what it does, when to use it, and what it returns. There is no redundancy or fluff.
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?
Despite having no output schema, the description thoroughly explains the return structure (two buckets) and additional feature/workflow references. For a single-parameter lookup tool, this is complete and self-contained.
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 already provides 100% coverage with a clear description of filePath (relative path, with example). The description adds no additional parameter-specific meaning beyond what the schema contains, so the baseline of 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 uses a specific verb ('find') and resource ('cross-project references to a file'), and clearly distinguishes the tool from siblings by explaining its dual strategy (Knowledge Graph + content scanning) and its specific output buckets. This makes the tool's unique role evident.
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 explicitly says 'Use this before editing a file to understand its full blast radius, even when the graph is incomplete,' providing a clear scenario and a key advantage. It does not explicitly mention alternatives or when-not-to-use, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-discover endpoints (backend), screens (mobile), or pages (admin) from a registered project. Returns discovered items for you to link to features.
| Name | Required | Description | Default |
|---|---|---|---|
| projectName | Yes | Name of the registered project to scan |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for disclosing behavioral traits. It says 'auto-discover' and 'returns discovered items,' which implies a read-only, non-destructive operation, but it does not explicitly state whether the tool modifies state or requires special permissions. It adds some context but lacks explicit safety/behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, with the action front-loaded. Every sentence earns its place without fluff.
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 parameter and no output schema, the description explains the purpose and the return value at a high level ('discovered items for you to link to features'). It lacks details on the return format or potential errors, but is sufficient for basic understanding.
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 schema covers 100% of the parameter (`projectName` with a clear description), so the baseline is 3. The description does not add extra parameter meaning beyond the schema, but it reinforces that the project must be registered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: auto-discovering endpoints, screens, or pages from a registered project. It uses a specific verb ('auto-discover') and identifies the resource (project), distinguishing it from siblings like register_project and get_feature.
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 clear context for use: it returns discovered items intended for linking to features. It implies the project must already be registered, but does not explicitly state when not to use this tool or mention alternatives. This is clear context with no exclusions, warranting a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across features, endpoints, files, and screens by keyword. Searches both the in-memory knowledge graph (features, workflow steps, type mappings) AND project file contents on disk. Returns all matches with their context (feature name, step, project, or file path + snippet).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search keyword (e.g., 'report', 'station', 'auth', 'controller') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the dual-source behavior (in-memory knowledge graph + files on disk) and the return format (matches with context). It does not mention safety (read-only) but 'Search' implies a non-mutating operation. The added detail about sources is valuable.
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, front-loaded with the action and scope. Every word adds value; no fluff 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?
For a single-parameter search tool with no output schema, the description is quite complete: it states sources, return format, and what context comes with matches. It lacks pagination/limit details, but for a tool with this low complexity, that is acceptable.
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%, so the baseline is 3. The description repeats that the search is 'by keyword' but does not add significant meaning beyond the schema's example list. It gives some context on what the keyword searches across, but not enough to raise the score.
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 'Search' and the resources searched (features, endpoints, files, screens). It conveys the broad scope but does not explicitly distinguish from sibling tools like reverse_lookup or get_context, so it earns a 4 rather than a 5.
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 clear context on what the tool searches (knowledge graph and file contents) and what it returns, making usage understandable. It does not explicitly mention alternatives or when not to use it, but the context is sufficient for a general-purpose search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-detect potential type mappings by scanning all registered projects for type/interface/class/enum definitions. Finds exact name matches across projects (HIGH confidence) and name-similar matches (MEDIUM confidence) by stripping common prefixes/suffixes like Dto, Schema, Form, Payload, etc. Use this to quickly populate the type mapping registry without manual discovery. Set autoRegister=true to automatically register HIGH confidence matches (exact name matches with exactly 2 occurrences).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of suggestions to return (0 = no limit). Default: 10. | |
| verbose | No | If true, return full details with file paths and registration instructions. If false (default), return a compact summary. | |
| typeName | No | Optional — if provided, only show suggestions related to this type name (case-insensitive partial match). | |
| confidence | No | Minimum confidence level to include ('high' = exact matches only, 'medium' = exact + similar, 'all' = everything). Default: 'high'. | high |
| projectName | No | Optional — if provided, only scan this specific project for type definitions. | |
| autoRegister | No | If true, automatically register HIGH confidence matches (exact name matches with exactly 2 occurrences). Default: false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the tool scans all registered projects, identifies exact and similar name matches, and describes the autoRegister side effect (registering HIGH confidence matches with exactly 2 occurrences). This is substantial transparency for a tool with read and optional write 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?
The description is three sentences, front-loaded with the core purpose, and each sentence adds meaningful detail. It is not overly verbose, though the third sentence could be seen as slightly redundant with the schema's autoRegister description. Overall, it is efficient and well-structured.
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 6 parameters and no output schema, the description is quite complete. It explains the scanning scope, confidence levels, the auto-registration side effect, and the intended use case. It does not detail return values, but given the schema covers parameter semantics and this is a suggestion tool, the description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are already documented. The description adds value by elaborating on the autoRegister parameter ('Set autoRegister=true to automatically register HIGH confidence matches') and clarifying the confidence parameter's meaning. This goes beyond the schema's baseline, earning a 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 uses a specific verb ('Auto-detect potential type mappings') and clearly identifies the resource (registered projects), distinguishing it from sibling tools like register_type_mappings (manual registration) and check_type_mapping (checking existing mappings). It also explains the confidence levels and auto-registration behavior, fully clarifying the tool's function.
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 explicitly states when to use the tool: 'Use this to quickly populate the type mapping registry without manual discovery.' It implies a contrast with manual registration tools and provides guidance on confidence levels. However, it does not explicitly mention when not to use it or name alternative tools, so it falls just short of the highest tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check all registered file paths across projects, features, and type mappings to detect stale entries. Files that have been renamed, moved, or deleted will be flagged as MISSING. Use this periodically to keep the knowledge graph in sync with the actual codebase. Optionally pass a featureName to validate only files related to that specific feature. Set fix=true to automatically remove stale entries (use with caution).
| Name | Required | Description | Default |
|---|---|---|---|
| fix | No | If true, automatically remove entries pointing to non-existent files. Use with caution. | |
| featureName | No | Optional — if provided, only validate files related to this feature. If omitted, validate everything. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that files are flagged as MISSING, and that fix=true will automatically remove stale entries, with a caution. It doesn't mention all edge cases (e.g., reversibility, dry-run), but the key destructive behavior is clearly stated.
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 four sentences long, with the main purpose upfront, followed by concrete behavioral details, usage cadence, and parameter guidance. No wasted words 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?
For a moderate-complexity tool with no output schema and no annotations, the description covers purpose, behavior, usage, and both parameters. It could be slightly more detailed about return values, but the core information is complete enough for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully describes both parameters. The description restates the parameter usage (featureName and fix) but doesn't add significant new meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'check' and the resource 'registered file paths across projects, features, and type mappings', with the specific outcome of detecting stale entries. This distinguishes it from narrower sibling tools like check_type_mapping by emphasizing the broad scope.
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 clear context for when to use the tool ('periodically to keep the knowledge graph in sync') and how to narrow scope with featureName. It doesn't explicitly mention alternatives or when not to use it, but the usage context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.6check_type_mappingexport_knowledgeget_architectureget_contextget_featureimport_knowledgeregister_featureregister_projectregister_type_mappingsremove_featureremove_projectreverse_lookupscan_projectsearchsuggest_type_mappingsvalidate_knowledgeMost tools have clearly distinct purposes, but there is slight overlap between reverse_lookup (find references by file) and check_type_mapping (find references by type), and between suggest_type_mappings (auto-detect) and register_type_mappings (manual registration). However, descriptions clarify the intended use for each.
All tool names follow a consistent snake_case verb_noun pattern (e.g., register_project, get_feature, validate_knowledge). Even 'reverse_lookup' and 'search' fit a predictable style, making the set easy to navigate.
With 16 tools, the set is well-scoped for managing projects, features, type mappings, and knowledge base operations. Each tool serves a distinct function without unnecessary bloat, and the count is appropriate for the domain.
Core operations for projects, features, and type mappings are covered, including create/update/remove/read. Minor gaps exist: there is no explicit 'list_projects' or 'list_features' tool, requiring reliance on search or memory to enumerate items, but this is workable.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted code graph over MCP: exact callers, dependencies, and cross-repo blast radius for AI agents.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
Graph-native persistent memory for AI agents — 33 MCP tools, zero-LLM writes.
One shared context your team's AI tools read & write over MCP. No re-explaining. Free.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/punic-pillars/project-knowledge-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
