-
Notifications
You must be signed in to change notification settings - Fork 646
[Feat] MCP Server Data Access Enhancement and Advanced features #9067
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Summary by CodeRabbit
WalkthroughThis update introduces a major expansion of the MCP server's capabilities by adding a wide range of new tools for managing products, invoices, expenses, goals, candidates, deals, payments, merchants, incomes, equipment, comments, reports, time-off, employee awards, activity logs, warehouses, pipelines, and skills. It also standardizes logging across the codebase to use Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant MCPServer
participant ToolModule
participant ApiClient
participant GauzyAPI
Client->>MCPServer: Invoke tool (e.g., create_invoice)
MCPServer->>ToolModule: Route call to tool handler
ToolModule->>ApiClient: Validate input, build API request
ApiClient->>GauzyAPI: Send REST API request
GauzyAPI-->>ApiClient: Return response
ApiClient-->>ToolModule: Pass response
ToolModule-->>MCPServer: Format and return result
MCPServer-->>Client: Return JSON/text content
Estimated code review effort🎯 5 (Critical) | ⏱️ ~90+ minutes
Suggested reviewers
Poem
✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Greptile Summary
This PR introduces significant enhancements to the MCP (Model Context Protocol) server infrastructure within the Ever Gauzy platform. The changes focus on two main areas: logging standardization and architectural improvements.
Logging Migration: The PR systematically replaces electron-log
with @nestjs/common
Logger across the entire MCP server package. This affects 15+ files including all tool modules (tasks, employees, projects, daily-plan, organization-contact, etc.), core infrastructure files (auth-manager, api-client, environment), and server management components. The migration standardizes logging patterns with consistent context labeling (e.g., 'AuthTools', 'ProjectTools') and maintains the same logging functionality while improving integration with the NestJS ecosystem.
New MCP Application: A new standalone MCP server application is introduced in apps/mcp/
with comprehensive documentation. This app enables AI assistants like Claude Desktop to interact with Gauzy's project management, time tracking, and employee management features through the Model Context Protocol standard. The application supports stdio-based communication, graceful shutdown handling, and test modes for development.
Package Restructuring: The packages/mcp-server
package has been enhanced with updated dependencies (adding @nestjs/common
, removing electron-log
) and comprehensive documentation. The package now serves as a shared library that can be consumed by both the new standalone MCP app and existing Electron desktop applications.
Desktop Application Enhancement: The existing apps/server-mcp
has been repositioned as an Electron desktop application for managing the Gauzy MCP server with a GUI interface, system tray integration, and enhanced user experience features.
These changes create a comprehensive MCP server ecosystem that supports both programmatic AI integration and user-friendly desktop management, while maintaining consistent logging and error handling throughout the codebase.
PR Description Notes:
- The PR template checkboxes are not completed
- Missing explanation of what the changes do and why they add value
Confidence score: 3/5
• This PR has architectural improvements but contains several concerns that need attention before merging.
• The logging migration is solid, but there are documentation inconsistencies, potential runtime issues with NestJS Logger usage, and incomplete PR requirements.
• Files needing attention: packages/mcp-server/README.md
, apps/server-mcp/README.md
, packages/mcp-server/mcp-server
(symlink), and the PR description itself.
20 files reviewed, 10 comments
const stopSuccess = await this.stop(); | ||
if (!stopSuccess) { | ||
log.error('Failed to stop MCP Server during restart'); | ||
logger.error('Failed to stop MCP Server during restart'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
style: This should use logger.error('Failed to stop MCP Server during restart', error as Error)
to follow the logging custom rule
logger.error('Failed to stop MCP Server during restart'); | |
logger.error('Failed to stop MCP Server during restart', error as Error); |
@@ -170,34 +172,34 @@ export class McpServerManager { | |||
|
|||
this.mcpProcess.on('error', (error) => { | |||
this._lastError = error.message; | |||
log.error('MCP Server process error:', error); | |||
logger.error('MCP Server process error:', error); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
style: This should use logger.error('MCP Server process error:', error as Error)
to follow the logging custom rule
logger.error('MCP Server process error:', error); | |
logger.error('MCP Server process error:', error as Error); |
### Claude Desktop | ||
|
||
1. Start the desktop app and ensure the server is running | ||
2. Note the server path shown in the app (typically: `dist/apps/mcp/index.js`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
logic: Documentation claims path is dist/apps/mcp/index.js
but based on project structure, it should be dist/apps/server-mcp/electron-main.js
No dependency changes detected. Learn more about Socket for GitHub. 👍 No dependency changes detected in pull request |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 14
🔭 Outside diff range comments (6)
packages/mcp-server/src/lib/tools/tasks.ts (1)
1-15
: Consider importingsanitizeForLogging
to keep log output consistent with other tools
Other tool modules (auth.ts
,test-connection.ts
, etc.) run every error throughsanitizeForLogging
before sending it to the logger.tasks.ts
now prints rawError
objects, which can include PII or very large payloads.-import { Logger } from '@nestjs/common'; +import { Logger } from '@nestjs/common'; +import { sanitizeForLogging } from '../common/security-utils.js';packages/mcp-server/src/lib/tools/auth.ts (1)
51-57
:Logger.error()
signature misuse – message is OK, stack is lostAll five invocations pass an object produced by
sanitizeForLogging
as the “stack” parameter, again resulting in[object Object]
in console output.-logger.error('Login tool error:', sanitizeForLogging(error)); +logger.error( + 'Login tool error:', + error instanceof Error ? error.stack : undefined +);Keep the sanitised object if you want to attach it as context:
logger.error('Login tool error', error.stack, JSON.stringify(sanitizeForLogging(error)));Also applies to: 78-84, 119-125, 160-166, 202-208
packages/mcp-server/src/lib/tools/test-connection.ts (1)
52-60
: SameLogger.error()
misuse as aboveReturn the real stack trace (or a sanitised string) instead of the raw object:
-logger.error('Error testing API connection:', sanitizeForLogging(error)); +logger.error( + 'Error testing API connection:', + error instanceof Error ? error.stack : undefined +);Apply to all occurrences shown.
Also applies to: 98-101, 156-158
packages/mcp-server/src/lib/mcp-server-manager.ts (2)
70-80
: UseLogger.error
signature correctly
Logger.error(message, stack?)
expects the second argument to be a stack string, not anError
object or arbitrary data.
Passing the rawerror
object results in[object Object]
in the log and loses the stack trace.-logger.error('Failed to start MCP Server:', error); +logger.error('Failed to start MCP Server', error instanceof Error ? error.stack : String(error)); -logger.error('MCP Server process error:', error); +logger.error('MCP Server process error', error instanceof Error ? error.stack : String(error)); -logger.error('MCP Server stderr:', data.toString()); +logger.error('MCP Server stderr', data.toString());Apply the same pattern to every
logger.error()
call in this file.Also applies to: 170-178, 190-199
152-156
: Substring check is weak path validation
if (!serverScript.includes(__dirname))
only verifies the string contains the directory name.
An attacker could craft a path such as/tmp/${__dirname}../evil.js
that still passes.
Usepath.resolve
+ strict equality orpath.isAbsolute
&path.relative
to ensure the script lives inside the expected directory.- if (!serverScript.includes(__dirname)) { + if (path.relative(__dirname, serverScript).startsWith('..')) { throw new Error('Invalid server script path'); }packages/mcp-server/src/lib/common/auth-manager.ts (1)
380-399
:atob
is not available in Node ≥18 – useBuffer
instead
atob
is a browser global. In recent Node versions it is absent unless--experimental-global-webcrypto
flags are used.
JWT decoding will therefore throw, always triggering the warning.-const jsonPayload = decodeURIComponent( - atob(base64) - .split('') - .map((c) => `%${('00' + c.charCodeAt(0).toString(16)).slice(-2)}`) - .join('') -); +const jsonPayload = Buffer.from(base64, 'base64').toString('utf8');Replace the manual percent-decode dance with the native
Buffer
conversion.
♻️ Duplicate comments (4)
packages/mcp-server/src/lib/tools/employees.ts (2)
2-9
: Same logging concerns as inprojects.ts
Create a shared logger instance and avoid per-file duplication.
81-83
: ReplaceError
object witherror.stack
Replicate the fix suggested for
projects.ts
– everylogger.error()
here passes the raw error object.Also applies to: 121-123, 169-171, 213-215, 257-259, 297-299, 331-333, 369-371, 402-404, 440-442, 469-471, 497-499, 527-529, 557-559, 602-604
packages/mcp-server/src/lib/tools/organization-contact.ts (2)
2-9
: Shared logger utility recommendedSame duplication comment as previous tools.
66-68
:logger.error
argument mismatchPass
error.stack
(or stringified error) instead of the object.Also applies to: 102-104, 161-163, 196-198, 230-232, 261-263, 290-292, 327-329, 357-359, 390-392, 425-427, 459-461, 499-501, 532-534, 567-569, 604-606, 639-641
@RolandM99 this PR now has tons of conflicts and AI suggestions... Can you work on this? I think it must be rebased on top of latest develop branch? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Greptile Summary
This PR introduces a comprehensive MCP (Model Context Protocol) Server Data Access Enhancement that significantly expands the Gauzy platform's AI integration capabilities. The changes implement a complete MCP server infrastructure that enables AI assistants like Claude Desktop to interact with the entire Gauzy business management system through standardized protocol tools.
The enhancement includes:
Core Infrastructure Changes:
- Migrates logging from electron-log to NestJS Logger across all MCP server components for consistency with the broader Gauzy architecture
- Expands the MCP server from 8 to 28 tool categories, adding comprehensive business entity support
- Introduces both standalone CLI application (
apps/mcp
) and Electron desktop wrapper (apps/server-mcp
) deployment options
New Business Entity Support:
The MCP server now provides complete CRUD operations and advanced functionality for products, invoices, expenses, goals, deals, candidates, payments, equipment, time-off management, employee awards, activity logs, warehouses, pipelines, skills, and more. Each entity includes specialized operations like bulk creation, statistics, search, and approval workflows.
Enhanced Tooling:
Adds 630+ lines of comprehensive Zod schemas for data validation, ensuring type safety across all MCP operations. The tools maintain proper organization/tenant scoping for multi-tenant architecture and include authentication context validation throughout.
Documentation and Configuration:
Provides extensive documentation for both deployment modes, configuration examples, and troubleshooting guides. Updates spell checker configuration to support new MCP-related terminology.
The implementation follows established patterns from the existing codebase, maintaining consistency in error handling, authentication, and API integration while dramatically expanding the platform's AI accessibility.
Confidence score: 2/5
- This PR has several critical issues that need attention before merging, including missing schema definitions, potential API endpoint mismatches, and documentation inconsistencies.
- Major concerns include undefined schema imports (MerchantSchema, CandidateSchema, ReportCategoryEnum), API endpoints that may not exist in the backend, and package.json private flag conflicting with installation documentation.
- Files requiring the most attention:
packages/mcp-server/src/lib/tools/candidates.ts
,packages/mcp-server/src/lib/tools/merchants.ts
,packages/mcp-server/src/lib/tools/reports.ts
,packages/mcp-server/src/lib/tools/products.ts
,packages/mcp-server/README.md
, andapps/server-mcp/README.md
.
41 files reviewed, 86 comments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 24
🔭 Outside diff range comments (2)
packages/mcp-server/src/lib/tools/expenses.ts (1)
559-559
: Add missing newline at end of file.The file is missing a newline character at the end. This is a common convention that helps with version control and text processing tools.
-}; +}; +packages/mcp-server/src/lib/tools/reports.ts (1)
578-578
: Add missing newline at end of file.The file is missing a newline character at the end.
-}; +}; +
♻️ Duplicate comments (8)
packages/mcp-server/package.json (1)
19-19
: Past review comment is inconsistent with current package configurationThe existing comment flagged ESM/CommonJS compatibility issues, but this package is configured as
"type": "commonjs"
(line 19), not ESM. The named import patternimport { Logger } from '@nestjs/common'
works correctly in CommonJS packages, so the compatibility concerns in the past review are not applicable here.Also applies to: 32-32
packages/mcp-server/src/lib/common/version.ts (1)
58-58
: Consider logging error stack trace for better debuggingThe past review comment about logging the error stack trace instead of the error object directly is still valid for improved debugging information.
packages/mcp-server/src/lib/tools/timer.ts (1)
42-42
: Stack trace logging enhancement still needed.While the logging standardization is correct, the previous review feedback about exposing meaningful stack traces remains valid. Consider enhancing error logging to include stack traces for better debugging:
-logger.error('Error fetching timer status:', error); +logger.error('Error fetching timer status:', error instanceof Error ? error.stack : error);Apply similar changes to the start timer (line 118) and stop timer (line 166) error handlers.
Also applies to: 118-118, 166-166
packages/mcp-server/src/lib/mcp-server-manager.ts (1)
46-46
: Fix logger.error parameter usage for proper stack trace logging.The
logger.error
calls are passing the error object as the second parameter, but NestJS Logger expects the error stack string for proper stack trace logging.Apply this pattern to fix all instances:
-logger.error('Failed to stop MCP Server during restart', error as Error); +logger.error('Failed to stop MCP Server during restart', error instanceof Error ? error.stack : String(error)); -logger.error('Failed to start MCP Server:', error); +logger.error('Failed to start MCP Server', error instanceof Error ? error.stack : String(error)); -logger.error('Failed to start MCP Server in process:', error); +logger.error('Failed to start MCP Server in process', error instanceof Error ? error.stack : String(error)); -logger.error('MCP Server process error:', error); +logger.error('MCP Server process error', error instanceof Error ? error.stack : String(error)); -logger.error('Failed to start MCP Server:', error); +logger.error('Failed to start MCP Server', error instanceof Error ? error.stack : String(error));Also applies to: 77-77, 135-135, 175-175, 202-202
packages/mcp-server/src/lib/common/api-client.ts (2)
54-62
: Considerlogger.debug
for verbose blocks to reduce log noise.This block emits up to five separate
logger.error
calls per failed request in debug mode, which is very chatty and will report expected 4xx responses with "error" severity during retries.Recommend switching to
logger.debug
or wrapping the details into one structuredlogger.error
call:if (this.isDebug()) { - logger.error('🔴 API Client Error Details:'); - logger.error(` URL: ${error.config?.url}`); - logger.error(` Method: ${error.config?.method?.toUpperCase()}`); - logger.error(` Status: ${error.response?.status}`); - logger.error(` Message: ${error.message}`); + logger.debug('🔴 API Client Error Details:', { + url: error.config?.url, + method: error.config?.method?.toUpperCase(), + status: error.response?.status, + message: error.message, + response: error.response?.data ? sanitizeErrorMessage(error.response.data) : undefined + }); - if (error.response?.data) { - const sanitizedData = sanitizeErrorMessage(error.response.data); - logger.error(` Response: ${JSON.stringify(sanitizedData, null, 2)}`); - } }
235-235
: Pass stack trace instead of sanitized message tologger.error
.
Logger.error
's second argument is intended for the stack trace. Currently, the sanitized message is passed, which duplicates the first parameter and hides the real stack.-logger.error(`🔴 ${method} ${path} failed:`, sanitizeErrorMessage(error)); +logger.error(`🔴 ${method} ${path} failed`, error instanceof Error ? error.stack : sanitizeErrorMessage(error));packages/mcp-server/src/lib/environments/environment.ts (1)
86-86
: Avoidprocess.exit
inside a library module.Calling
process.exit(1)
here will kill any host process (Electron, NestJS app, tests) that merely importsenvironment.ts
. Throw a dedicated configuration error instead and let the top-level application decide how to handle it.logger.error('GAUZY_AUTH_PASSWORD=***'); -process.exit(1); +throw new Error('Invalid environment configuration – see logs above.');packages/mcp-server/src/lib/mcp-server.ts (1)
83-83
: Fixlogger.error
parameter misuse for proper stack trace logging.The
logger.error
calls are incorrectly passing the error object as the second parameter instead of the error stack string, which prevents proper stack trace logging.-logger.error('Error configuring Gauzy MCP Server:', error); +logger.error('Error configuring Gauzy MCP Server', error instanceof Error ? error.stack : String(error)); -logger.error('Fatal error starting Gauzy MCP Server:', error); +logger.error('Fatal error starting Gauzy MCP Server', error instanceof Error ? error.stack : String(error));Also applies to: 128-128
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (1)
yarn.lock
is excluded by!**/yarn.lock
,!**/*.lock
📒 Files selected for processing (38)
.cspell.json
(2 hunks)packages/mcp-server/package.json
(1 hunks)packages/mcp-server/src/lib/common/api-client.ts
(8 hunks)packages/mcp-server/src/lib/common/auth-manager.ts
(11 hunks)packages/mcp-server/src/lib/common/version.ts
(2 hunks)packages/mcp-server/src/lib/environments/environment.ts
(4 hunks)packages/mcp-server/src/lib/mcp-server-manager.ts
(9 hunks)packages/mcp-server/src/lib/mcp-server.ts
(5 hunks)packages/mcp-server/src/lib/schema.ts
(3 hunks)packages/mcp-server/src/lib/tools/activity-logs.ts
(1 hunks)packages/mcp-server/src/lib/tools/auth.ts
(7 hunks)packages/mcp-server/src/lib/tools/candidates.ts
(1 hunks)packages/mcp-server/src/lib/tools/comments.ts
(1 hunks)packages/mcp-server/src/lib/tools/daily-plan.ts
(18 hunks)packages/mcp-server/src/lib/tools/deals.ts
(1 hunks)packages/mcp-server/src/lib/tools/employee-awards.ts
(1 hunks)packages/mcp-server/src/lib/tools/employees.ts
(16 hunks)packages/mcp-server/src/lib/tools/equipment.ts
(1 hunks)packages/mcp-server/src/lib/tools/expenses.ts
(1 hunks)packages/mcp-server/src/lib/tools/goals.ts
(1 hunks)packages/mcp-server/src/lib/tools/incomes.ts
(1 hunks)packages/mcp-server/src/lib/tools/index.ts
(1 hunks)packages/mcp-server/src/lib/tools/invoices.ts
(1 hunks)packages/mcp-server/src/lib/tools/key-results.ts
(1 hunks)packages/mcp-server/src/lib/tools/merchants.ts
(1 hunks)packages/mcp-server/src/lib/tools/organization-contact.ts
(18 hunks)packages/mcp-server/src/lib/tools/payments.ts
(1 hunks)packages/mcp-server/src/lib/tools/pipelines.ts
(1 hunks)packages/mcp-server/src/lib/tools/product-categories.ts
(1 hunks)packages/mcp-server/src/lib/tools/products.ts
(1 hunks)packages/mcp-server/src/lib/tools/projects.ts
(15 hunks)packages/mcp-server/src/lib/tools/reports.ts
(1 hunks)packages/mcp-server/src/lib/tools/skills.ts
(1 hunks)packages/mcp-server/src/lib/tools/tasks.ts
(18 hunks)packages/mcp-server/src/lib/tools/test-connection.ts
(4 hunks)packages/mcp-server/src/lib/tools/time-off.ts
(1 hunks)packages/mcp-server/src/lib/tools/timer.ts
(4 hunks)packages/mcp-server/src/lib/tools/warehouses.ts
(1 hunks)
🧰 Additional context used
🧠 Learnings (33)
📓 Common learnings
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9029
File: packages/mcp-server/src/lib/tools/employees.ts:78-600
Timestamp: 2025-07-25T05:08:34.515Z
Learning: In the ever-co/ever-gauzy packages/mcp-server shared package, electron-log is used consistently across most tool files for logging, but some files (employees.ts, tasks.ts, daily-plan.ts) still use console.error creating an inconsistency. The electron-log library works in both Electron and Node.js contexts, so it's safe to use throughout the shared package for consistent logging behavior.
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9029
File: packages/mcp-server/src/lib/tools/employees.ts:78-600
Timestamp: 2025-07-25T05:08:34.515Z
Learning: In the ever-co/ever-gauzy packages/mcp-server shared package, electron-log is successfully used across multiple core files (api-client.ts, auth-manager.ts, mcp-server.ts, etc.) without any conditional logic or fallbacks. This proves electron-log works reliably in both Electron and standalone Node.js contexts within this codebase. The files using console.error (employees.ts, tasks.ts, daily-plan.ts) are inconsistent outliers that should use log.error for consistency.
📚 Learning: in the ever-co/ever-gauzy project's apps/server-mcp/tsconfig.electron.json, the "electron" type shou...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9068
File: apps/server-mcp/tsconfig.electron.json:17-18
Timestamp: 2025-07-29T21:00:16.321Z
Learning: In the ever-co/ever-gauzy project's apps/server-mcp/tsconfig.electron.json, the "electron" type should be removed from the types array because the project no longer uses Electron APIs and has moved to a Node.js-only architecture. Adding "electron" types causes build errors in their current setup, so only "node" types should be included.
Applied to files:
packages/mcp-server/package.json
packages/mcp-server/src/lib/tools/timer.ts
.cspell.json
packages/mcp-server/src/lib/common/version.ts
packages/mcp-server/src/lib/tools/tasks.ts
packages/mcp-server/src/lib/tools/employees.ts
packages/mcp-server/src/lib/tools/organization-contact.ts
packages/mcp-server/src/lib/tools/projects.ts
packages/mcp-server/src/lib/tools/auth.ts
packages/mcp-server/src/lib/environments/environment.ts
packages/mcp-server/src/lib/tools/test-connection.ts
packages/mcp-server/src/lib/common/api-client.ts
packages/mcp-server/src/lib/tools/daily-plan.ts
packages/mcp-server/src/lib/common/auth-manager.ts
packages/mcp-server/src/lib/mcp-server.ts
packages/mcp-server/src/lib/mcp-server-manager.ts
packages/mcp-server/src/lib/tools/index.ts
📚 Learning: in the ever-co/ever-gauzy packages/mcp-server shared package, electron-log is used consistently acro...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9029
File: packages/mcp-server/src/lib/tools/employees.ts:78-600
Timestamp: 2025-07-25T05:08:34.515Z
Learning: In the ever-co/ever-gauzy packages/mcp-server shared package, electron-log is used consistently across most tool files for logging, but some files (employees.ts, tasks.ts, daily-plan.ts) still use console.error creating an inconsistency. The electron-log library works in both Electron and Node.js contexts, so it's safe to use throughout the shared package for consistent logging behavior.
Applied to files:
packages/mcp-server/package.json
packages/mcp-server/src/lib/tools/timer.ts
packages/mcp-server/src/lib/common/version.ts
packages/mcp-server/src/lib/tools/tasks.ts
packages/mcp-server/src/lib/tools/employees.ts
packages/mcp-server/src/lib/tools/organization-contact.ts
packages/mcp-server/src/lib/tools/projects.ts
packages/mcp-server/src/lib/tools/auth.ts
packages/mcp-server/src/lib/environments/environment.ts
packages/mcp-server/src/lib/tools/test-connection.ts
packages/mcp-server/src/lib/common/api-client.ts
packages/mcp-server/src/lib/tools/daily-plan.ts
packages/mcp-server/src/lib/tools/activity-logs.ts
packages/mcp-server/src/lib/common/auth-manager.ts
packages/mcp-server/src/lib/tools/time-off.ts
packages/mcp-server/src/lib/tools/employee-awards.ts
packages/mcp-server/src/lib/mcp-server.ts
packages/mcp-server/src/lib/tools/candidates.ts
packages/mcp-server/src/lib/mcp-server-manager.ts
packages/mcp-server/src/lib/tools/invoices.ts
packages/mcp-server/src/lib/tools/equipment.ts
packages/mcp-server/src/lib/tools/goals.ts
packages/mcp-server/src/lib/tools/merchants.ts
packages/mcp-server/src/lib/tools/expenses.ts
packages/mcp-server/src/lib/tools/reports.ts
packages/mcp-server/src/lib/tools/index.ts
📚 Learning: in the ever-co/ever-gauzy packages/mcp-server shared package, electron-log is successfully used acro...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9029
File: packages/mcp-server/src/lib/tools/employees.ts:78-600
Timestamp: 2025-07-25T05:08:34.515Z
Learning: In the ever-co/ever-gauzy packages/mcp-server shared package, electron-log is successfully used across multiple core files (api-client.ts, auth-manager.ts, mcp-server.ts, etc.) without any conditional logic or fallbacks. This proves electron-log works reliably in both Electron and standalone Node.js contexts within this codebase. The files using console.error (employees.ts, tasks.ts, daily-plan.ts) are inconsistent outliers that should use log.error for consistency.
Applied to files:
packages/mcp-server/package.json
packages/mcp-server/src/lib/tools/timer.ts
packages/mcp-server/src/lib/common/version.ts
packages/mcp-server/src/lib/tools/tasks.ts
packages/mcp-server/src/lib/tools/employees.ts
packages/mcp-server/src/lib/tools/organization-contact.ts
packages/mcp-server/src/lib/tools/projects.ts
packages/mcp-server/src/lib/tools/auth.ts
packages/mcp-server/src/lib/environments/environment.ts
packages/mcp-server/src/lib/tools/test-connection.ts
packages/mcp-server/src/lib/common/api-client.ts
packages/mcp-server/src/lib/tools/daily-plan.ts
packages/mcp-server/src/lib/tools/activity-logs.ts
packages/mcp-server/src/lib/common/auth-manager.ts
packages/mcp-server/src/lib/tools/time-off.ts
packages/mcp-server/src/lib/tools/employee-awards.ts
packages/mcp-server/src/lib/mcp-server.ts
packages/mcp-server/src/lib/tools/candidates.ts
packages/mcp-server/src/lib/mcp-server-manager.ts
packages/mcp-server/src/lib/tools/equipment.ts
packages/mcp-server/src/lib/tools/goals.ts
packages/mcp-server/src/lib/tools/expenses.ts
packages/mcp-server/src/lib/tools/reports.ts
packages/mcp-server/src/lib/tools/index.ts
📚 Learning: in the ever-co/ever-gauzy packages/mcp-server, when importing from the external sdk @modelcontextpro...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9072
File: packages/mcp-server/src/lib/tools/daily-plan.ts:4-6
Timestamp: 2025-07-30T15:25:57.253Z
Learning: In the ever-co/ever-gauzy packages/mcp-server, when importing from the external SDK @modelcontextprotocol/sdk, the .js extension should be kept in import paths (e.g., '@modelcontextprotocol/sdk/server/mcp.js') to ensure the MCP server app builds successfully. This applies to all files using the @modelcontextprotocol/sdk package, while internal/relative imports should not use the .js extension.
Applied to files:
packages/mcp-server/package.json
.cspell.json
packages/mcp-server/src/lib/common/version.ts
packages/mcp-server/src/lib/tools/tasks.ts
packages/mcp-server/src/lib/tools/employees.ts
packages/mcp-server/src/lib/tools/projects.ts
packages/mcp-server/src/lib/tools/auth.ts
packages/mcp-server/src/lib/environments/environment.ts
packages/mcp-server/src/lib/tools/test-connection.ts
packages/mcp-server/src/lib/common/api-client.ts
packages/mcp-server/src/lib/tools/time-off.ts
packages/mcp-server/src/lib/mcp-server.ts
packages/mcp-server/src/lib/tools/candidates.ts
packages/mcp-server/src/lib/mcp-server-manager.ts
packages/mcp-server/src/lib/tools/pipelines.ts
packages/mcp-server/src/lib/tools/equipment.ts
packages/mcp-server/src/lib/tools/payments.ts
packages/mcp-server/src/lib/tools/goals.ts
packages/mcp-server/src/lib/tools/skills.ts
packages/mcp-server/src/lib/tools/deals.ts
packages/mcp-server/src/lib/tools/merchants.ts
packages/mcp-server/src/lib/tools/warehouses.ts
packages/mcp-server/src/lib/tools/product-categories.ts
packages/mcp-server/src/lib/tools/expenses.ts
packages/mcp-server/src/lib/tools/products.ts
packages/mcp-server/src/lib/tools/reports.ts
packages/mcp-server/src/lib/schema.ts
packages/mcp-server/src/lib/tools/index.ts
📚 Learning: in packages/mcp-server/src/lib/config/server-info.ts, the user rolandm99 confirmed that the server n...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9029
File: packages/mcp-server/src/lib/config/server-info.ts:2-2
Timestamp: 2025-07-25T04:53:31.370Z
Learning: In packages/mcp-server/src/lib/config/server-info.ts, the user RolandM99 confirmed that the server name "Gauzy MCP Server" should remain hardcoded because it will stay the same across all environments (development, staging, production). The user prefers this approach over using environment variables for the server name.
Applied to files:
packages/mcp-server/package.json
packages/mcp-server/src/lib/tools/timer.ts
packages/mcp-server/src/lib/common/version.ts
packages/mcp-server/src/lib/tools/tasks.ts
packages/mcp-server/src/lib/tools/employees.ts
packages/mcp-server/src/lib/tools/organization-contact.ts
packages/mcp-server/src/lib/tools/projects.ts
packages/mcp-server/src/lib/tools/auth.ts
packages/mcp-server/src/lib/environments/environment.ts
packages/mcp-server/src/lib/tools/test-connection.ts
packages/mcp-server/src/lib/common/api-client.ts
packages/mcp-server/src/lib/tools/daily-plan.ts
packages/mcp-server/src/lib/common/auth-manager.ts
packages/mcp-server/src/lib/mcp-server.ts
packages/mcp-server/src/lib/tools/candidates.ts
packages/mcp-server/src/lib/mcp-server-manager.ts
packages/mcp-server/src/lib/tools/equipment.ts
packages/mcp-server/src/lib/tools/comments.ts
packages/mcp-server/src/lib/tools/merchants.ts
packages/mcp-server/src/lib/tools/products.ts
packages/mcp-server/src/lib/tools/reports.ts
📚 Learning: @sentry/electron package version 6.8.0 is the latest version available on npm and is fully compatibl...
Learnt from: samuelmbabhazi
PR: ever-co/ever-gauzy#9076
File: apps/server/package.json:54-54
Timestamp: 2025-07-31T11:17:31.456Z
Learning: @sentry/electron package version 6.8.0 is the latest version available on npm and is fully compatible with Sentry core v9. This corrects previous information suggesting 6.5.0 was the latest version.
Applied to files:
packages/mcp-server/package.json
📚 Learning: uuid version 11+ includes its own typescript definitions, making the separate @types/uuid package un...
Learnt from: rahul-rocket
PR: ever-co/ever-gauzy#8922
File: packages/plugins/integration-upwork/package.json:57-57
Timestamp: 2025-04-28T14:17:18.486Z
Learning: UUID version 11+ includes its own TypeScript definitions, making the separate @types/uuid package unnecessary. When using UUID v11 or newer, remove the @types/uuid dependency to avoid potential type conflicts.
Applied to files:
packages/mcp-server/package.json
packages/mcp-server/src/lib/common/version.ts
📚 Learning: @sentry/electron package version 6.8.0 is the current latest version available on npm as confirmed b...
Learnt from: samuelmbabhazi
PR: ever-co/ever-gauzy#9076
File: apps/server/package.json:54-54
Timestamp: 2025-07-31T11:17:31.456Z
Learning: @sentry/electron package version 6.8.0 is the current latest version available on npm as confirmed by direct npm registry API query. This package version is fully compatible with Sentry core v9.
Applied to files:
packages/mcp-server/package.json
📚 Learning: @sentry/electron package v6.x is fully compatible with sentry core v9 because it internally uses the...
Learnt from: samuelmbabhazi
PR: ever-co/ever-gauzy#9076
File: apps/desktop-timer/package.json:56-59
Timestamp: 2025-07-31T11:10:53.946Z
Learning: @sentry/electron package v6.x is fully compatible with Sentry core v9 because it internally uses the Sentry JavaScript SDK v9. The @sentry/electron package follows its own versioning scheme (v6.x) while maintaining compatibility with Sentry JavaScript SDK v9, so version numbers don't need to match across all Sentry packages.
Applied to files:
packages/mcp-server/package.json
packages/mcp-server/src/lib/common/version.ts
📚 Learning: when importing node.js built-in modules in typescript/javascript files, use the node: protocol prefi...
Learnt from: syns2191
PR: ever-co/ever-gauzy#8909
File: packages/desktop-activity/src/lib/kb-mouse.ts:1-2
Timestamp: 2025-04-20T09:30:18.913Z
Learning: When importing Node.js built-in modules in TypeScript/JavaScript files, use the node: protocol prefix (e.g., `import { EventEmitter } from 'node:events';` instead of `import { EventEmitter } from 'events';`) as it's more explicit and signals that the imported module belongs to Node.js.
Applied to files:
packages/mcp-server/package.json
packages/mcp-server/src/lib/tools/timer.ts
packages/mcp-server/src/lib/common/version.ts
packages/mcp-server/src/lib/tools/auth.ts
packages/mcp-server/src/lib/mcp-server.ts
packages/mcp-server/src/lib/tools/index.ts
📚 Learning: when verifying package versions, check both the npm registry and github repositories, as versions ma...
Learnt from: rahul-rocket
PR: ever-co/ever-gauzy#8470
File: package.json:342-342
Timestamp: 2024-10-21T13:58:20.055Z
Learning: When verifying package versions, check both the npm registry and GitHub repositories, as versions may be published to npm even if not present in the GitHub repository.
Applied to files:
packages/mcp-server/package.json
packages/mcp-server/src/lib/common/version.ts
📚 Learning: in the ever-gauzy codebase, particularly in packages/plugins/integration-zapier/src/lib/zapier.contr...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9000
File: packages/plugins/integration-zapier/src/lib/zapier.controller.ts:63-65
Timestamp: 2025-06-18T14:38:29.691Z
Learning: In the ever-gauzy codebase, particularly in packages/plugins/integration-zapier/src/lib/zapier.controller.ts, prefer explicit Buffer.from() wrapping even when the source already returns a Buffer, for defensive programming and type safety clarity.
Applied to files:
packages/mcp-server/package.json
packages/mcp-server/src/lib/tools/timer.ts
packages/mcp-server/src/lib/common/version.ts
packages/mcp-server/src/lib/common/api-client.ts
packages/mcp-server/src/lib/mcp-server.ts
📚 Learning: the pullactivities class in apps/agent/src/main/workers/pull-activities.ts already has built-in erro...
Learnt from: syns2191
PR: ever-co/ever-gauzy#8884
File: apps/agent/src/main/init/ipcMain.ts:41-44
Timestamp: 2025-04-12T14:42:07.626Z
Learning: The PullActivities class in apps/agent/src/main/workers/pull-activities.ts already has built-in error handling in its startTracking() method, making additional error handling in calling functions unnecessary.
Applied to files:
packages/mcp-server/src/lib/tools/timer.ts
📚 Learning: in the agent app of the ever-gauzy project, errors from the `checkuserauthentication` function and s...
Learnt from: syns2191
PR: ever-co/ever-gauzy#8874
File: apps/agent/src/main/init/app.ts:106-106
Timestamp: 2025-03-28T14:49:10.529Z
Learning: In the Agent app of the ever-gauzy project, errors from the `checkUserAuthentication` function and similar async operations are handled at the application level rather than with local try/catch blocks. The application uses a global uncaught exception handler.
Applied to files:
packages/mcp-server/src/lib/tools/timer.ts
packages/mcp-server/src/lib/tools/employees.ts
packages/mcp-server/src/lib/environments/environment.ts
packages/mcp-server/src/lib/common/api-client.ts
📚 Learning: in apps/agent/src/main/init/app.ts, the eventhandler initialization during application startup shoul...
Learnt from: syns2191
PR: ever-co/ever-gauzy#8993
File: apps/agent/src/main/init/app.ts:31-32
Timestamp: 2025-06-09T00:20:59.777Z
Learning: In apps/agent/src/main/init/app.ts, the EventHandler initialization during application startup should not have error handling. The user prefers that any failure during EventHandler.getInstance() or eventHandler.mainListener() should cause the application to fail immediately rather than continue with graceful error handling, as this is considered a critical component that must initialize successfully.
Applied to files:
packages/mcp-server/src/lib/tools/timer.ts
packages/mcp-server/src/lib/environments/environment.ts
packages/mcp-server/src/lib/common/api-client.ts
packages/mcp-server/src/lib/mcp-server.ts
packages/mcp-server/src/lib/mcp-server-manager.ts
📚 Learning: the pullactivities class in apps/agent/src/main/workers/pull-activities.ts already includes error ha...
Learnt from: syns2191
PR: ever-co/ever-gauzy#8884
File: apps/agent/src/main/init/ipcMain.ts:41-44
Timestamp: 2025-04-12T14:42:07.626Z
Learning: The PullActivities class in apps/agent/src/main/workers/pull-activities.ts already includes error handling with try-catch blocks in its methods (getListenerModule, startTracking, stopTracking), making additional error handling in calling functions like listenIO() unnecessary.
Applied to files:
packages/mcp-server/src/lib/tools/timer.ts
packages/mcp-server/src/lib/common/api-client.ts
📚 Learning: in the ever-gauzy codebase, the build system compiles all static import statements to require statem...
Learnt from: syns2191
PR: ever-co/ever-gauzy#9033
File: packages/desktop-activity/src/lib/activity-window.ts:113-120
Timestamp: 2025-07-11T01:30:50.701Z
Learning: In the ever-gauzy codebase, the build system compiles all static import statements to require statements. When working with ESM-only modules like 'get-windows', the Function constructor approach with dynamic import is used to bypass build-time transformations, as seen in packages/desktop-activity/src/lib/activity-window.ts.
Applied to files:
packages/mcp-server/src/lib/common/version.ts
packages/mcp-server/src/lib/tools/index.ts
📚 Learning: in apps/agent/src/main/screenshot.ts, the user syns2191 intentionally chose to use synchronous file ...
Learnt from: syns2191
PR: ever-co/ever-gauzy#8969
File: apps/agent/src/main/screenshot.ts:27-36
Timestamp: 2025-05-25T14:51:30.954Z
Learning: In apps/agent/src/main/screenshot.ts, the user syns2191 intentionally chose to use synchronous file writing (fs.writeFileSync) instead of asynchronous operations because they experienced issues with async file writing. This was a deliberate decision to switch from async to sync to resolve problems they encountered.
Applied to files:
packages/mcp-server/src/lib/common/version.ts
📚 Learning: applies to src/main.ts : bootstrap your application in a file named 'main.ts' directly inside 'src'...
Learnt from: CR
PR: ever-co/ever-gauzy#0
File: .cursor/rules/angular.mdc:0-0
Timestamp: 2025-07-21T15:50:57.938Z
Learning: Applies to src/main.ts : Bootstrap your application in a file named 'main.ts' directly inside 'src'
Applied to files:
packages/mcp-server/src/lib/common/version.ts
packages/mcp-server/src/lib/tools/index.ts
📚 Learning: the zapierauthcodeservice in the zapier integration plugin is designed to be initialized only once a...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#8901
File: packages/plugins/integration-zapier/src/lib/zapier-auth-code.service.ts:27-29
Timestamp: 2025-04-15T18:29:09.314Z
Learning: The ZapierAuthCodeService in the Zapier integration plugin is designed to be initialized only once as a singleton service in the NestJS application.
Applied to files:
packages/mcp-server/src/lib/tools/tasks.ts
packages/mcp-server/src/lib/common/api-client.ts
📚 Learning: in packages/contracts/src/lib/employee.model.ts, the agent settings flags (allowagentappexit, allowl...
Learnt from: samuelmbabhazi
PR: ever-co/ever-gauzy#9042
File: packages/contracts/src/lib/employee.model.ts:124-127
Timestamp: 2025-07-13T02:33:55.890Z
Learning: In packages/contracts/src/lib/employee.model.ts, the agent settings flags (allowAgentAppExit, allowLogoutFromAgentApp) and tracking settings flags (trackKeyboardMouseActivity, trackAllDisplays) are intentionally omitted from IEmployeeCreateInput interface. These flags should always take default values when creating employees and can only be modified later through update operations, not during initial creation.
Applied to files:
packages/mcp-server/src/lib/tools/employees.ts
packages/mcp-server/src/lib/tools/employee-awards.ts
📚 Learning: mysql migrations involving user-employee mappings should include logging and error handling for case...
Learnt from: rahul-rocket
PR: ever-co/ever-gauzy#8771
File: packages/core/src/lib/database/migrations/1739602849367-AlterActivityLogEntityTable.ts:600-642
Timestamp: 2025-02-17T07:36:46.838Z
Learning: MySQL migrations involving user-employee mappings should include logging and error handling for cases where employee records don't exist or multiple records exist for a user. Use a logging table to track problematic records and generate migration summaries.
Applied to files:
packages/mcp-server/src/lib/tools/employees.ts
packages/mcp-server/src/lib/tools/daily-plan.ts
📚 Learning: in the ever-co/ever-gauzy codebase, the backend api uses camelcase naming conventions for field name...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9029
File: packages/mcp-server/src/lib/tools/organization-contact.ts:12-25
Timestamp: 2025-07-23T10:56:18.549Z
Learning: In the ever-co/ever-gauzy codebase, the backend API uses camelCase naming conventions for field names (e.g., organizationId, tenantId, employeeId, primaryEmail). When implementing MCP tools and schema validation, field names should use camelCase to match the backend entity structure, not snake_case.
Applied to files:
packages/mcp-server/src/lib/tools/employees.ts
📚 Learning: in this project, `@isdatestring()` is preferred for dto validation of `date` properties like `assign...
Learnt from: rahul-rocket
PR: ever-co/ever-gauzy#8558
File: packages/core/src/organization-project-module/organization-project-module-employee.entity.ts:25-27
Timestamp: 2024-12-04T04:54:37.067Z
Learning: In this project, `@IsDateString()` is preferred for DTO validation of `Date` properties like `assignedAt` in `organization-project-module-employee.entity.ts`.
Applied to files:
packages/mcp-server/src/lib/tools/projects.ts
📚 Learning: when developing zapier integrations that will be deployed to the zapier platform, use `process.env` ...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#8863
File: packages/plugins/integration-zapier/zapier/src/authentication.ts:29-29
Timestamp: 2025-04-02T09:39:39.648Z
Learning: When developing Zapier integrations that will be deployed to the Zapier platform, use `process.env` directly to access environment variables instead of importing from `@gauzy/config`, as Zapier's platform cannot recognize or import this package.
Applied to files:
packages/mcp-server/src/lib/environments/environment.ts
📚 Learning: in .scripts/env.ts, app_id environment variable defaults use lowercase format (e.g., 'com.ever.gauzy...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9063
File: .scripts/env.ts:354-356
Timestamp: 2025-07-29T08:07:12.448Z
Learning: In .scripts/env.ts, APP_ID environment variable defaults use lowercase format (e.g., 'com.ever.gauzydesktoptimer', 'com.ever.gauzydesktop', 'com.ever.gauzyserver') rather than camelCase. New APP_ID values should maintain this lowercase consistency.
Applied to files:
packages/mcp-server/src/lib/environments/environment.ts
📚 Learning: in the ever-co/ever-gauzy project, empty "files" and "include" arrays in typescript configuration fi...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9029
File: apps/mcp/tsconfig.json:13-14
Timestamp: 2025-07-23T16:00:29.020Z
Learning: In the ever-co/ever-gauzy project, empty "files" and "include" arrays in TypeScript configuration files (like apps/mcp/tsconfig.json) are written deliberately and should not be flagged as issues. The project intentionally uses this pattern where configurations rely solely on referenced configs via the "references" array.
Applied to files:
packages/mcp-server/src/lib/environments/environment.ts
📚 Learning: in packages/mcp-server/src/lib/common/security-utils.ts, the user rolandm99 specifically wants to ke...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9029
File: packages/mcp-server/src/lib/common/security-utils.ts:9-53
Timestamp: 2025-07-23T02:22:13.652Z
Learning: In packages/mcp-server/src/lib/common/security-utils.ts, the user RolandM99 specifically wants to keep the existing regex patterns for sanitizing error messages, including the API key pattern `/[a-zA-Z0-9]{32,}/g` and email regex `/[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}/g`, as they are intentionally designed this way for their use case.
Applied to files:
packages/mcp-server/src/lib/common/api-client.ts
📚 Learning: in this codebase, using `logger.debug` and colorization in migration files is acceptable, as coloriz...
Learnt from: rahul-rocket
PR: ever-co/ever-gauzy#8484
File: packages/core/src/database/migration-executor.ts:283-283
Timestamp: 2024-10-25T14:20:13.852Z
Learning: In this codebase, using `Logger.debug` and colorization in migration files is acceptable, as colorization during migrations is needed.
Applied to files:
packages/mcp-server/src/lib/common/api-client.ts
📚 Learning: when using in-memory storage for auth codes or tokens in node.js, consider adding concurrency safegu...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#8901
File: packages/plugins/integration-zapier/src/lib/zapier-auth-code.service.ts:21-57
Timestamp: 2025-04-11T08:39:18.375Z
Learning: When using in-memory storage for auth codes or tokens in Node.js, consider adding concurrency safeguards with mutex locks for critical sections. Libraries like 'async-mutex' can help prevent race conditions, even in Node's single-threaded environment, especially for clean-up operations or size-limit checks.
Applied to files:
packages/mcp-server/src/lib/common/auth-manager.ts
📚 Learning: in zapier integration triggers like tasklist.ts, explicit verification of bundle.authdata['access_to...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#8901
File: packages/plugins/integration-zapier/zapier/src/triggers/taskList.ts:17-26
Timestamp: 2025-04-11T14:04:20.522Z
Learning: In Zapier integration triggers like taskList.ts, explicit verification of bundle.authData['access_token'] is not necessary as the access token will always exist when the code is executed due to how the Zapier platform handles authentication.
Applied to files:
packages/mcp-server/src/lib/common/auth-manager.ts
📚 Learning: in `packages/core/src/employee/employee.entity.ts`, the `modules` property in the `employee` entity ...
Learnt from: samuelmbabhazi
PR: ever-co/ever-gauzy#8558
File: packages/core/src/employee/employee.entity.ts:538-542
Timestamp: 2024-12-03T07:45:30.195Z
Learning: In `packages/core/src/employee/employee.entity.ts`, the `modules` property in the `Employee` entity represents the relationship between `Employee` and `OrganizationProjectModule`, and it should be typed as `IOrganizationProjectModule[]`.
Applied to files:
packages/mcp-server/src/lib/schema.ts
🧬 Code Graph Analysis (7)
packages/mcp-server/src/lib/tools/timer.ts (1)
packages/desktop-core/src/lib/logger/logger.ts (2)
logger
(34-34)Logger
(5-32)
packages/mcp-server/src/lib/common/version.ts (1)
packages/desktop-core/src/lib/logger/logger.ts (2)
logger
(34-34)Logger
(5-32)
packages/mcp-server/src/lib/tools/employees.ts (1)
packages/desktop-core/src/lib/logger/logger.ts (2)
logger
(34-34)Logger
(5-32)
packages/mcp-server/src/lib/tools/projects.ts (1)
packages/desktop-core/src/lib/logger/logger.ts (2)
logger
(34-34)Logger
(5-32)
packages/mcp-server/src/lib/tools/employee-awards.ts (3)
packages/desktop-core/src/lib/logger/logger.ts (2)
logger
(34-34)Logger
(5-32)packages/mcp-server/src/lib/common/auth-manager.ts (1)
authManager
(426-426)packages/mcp-server/src/lib/common/api-client.ts (1)
apiClient
(356-356)
packages/mcp-server/src/lib/mcp-server-manager.ts (1)
packages/desktop-core/src/lib/logger/logger.ts (2)
logger
(34-34)Logger
(5-32)
packages/mcp-server/src/lib/tools/warehouses.ts (5)
packages/desktop-core/src/lib/logger/logger.ts (2)
logger
(34-34)Logger
(5-32)packages/mcp-server/src/lib/common/auth-manager.ts (1)
authManager
(426-426)packages/mcp-server/src/lib/common/api-client.ts (1)
apiClient
(356-356)packages/core/src/lib/core/context/request-context.ts (1)
id
(39-41)packages/mcp-server/src/lib/schema.ts (1)
WarehouseSchemaFull
(1467-1467)
🪛 GitHub Check: Cspell
packages/mcp-server/src/lib/tools/comments.ts
[warning] 296-296:
Unknown word (Commentable)
[warning] 249-249:
Unknown word (Commentable)
[warning] 78-78:
Unknown word (Commentable)
[warning] 33-33:
Unknown word (Commentable)
[warning] 6-6:
Unknown word (Commentable)
packages/mcp-server/src/lib/schema.ts
[warning] 1229-1229:
Unknown word (Commentable)
[warning] 804-804:
Unknown word (Commentable)
[warning] 1415-1415:
Unknown word (Commentable)
🪛 GitHub Actions: Check Spelling and Typos with cspell
packages/mcp-server/src/lib/tools/comments.ts
[warning] 6-6: Unknown word (Commentable) reported by cspell.
[warning] 33-33: Unknown word (Commentable) reported by cspell.
[warning] 78-78: Unknown word (Commentable) reported by cspell.
[warning] 249-249: Unknown word (Commentable) reported by cspell.
[warning] 296-296: Unknown word (Commentable) reported by cspell.
packages/mcp-server/src/lib/schema.ts
[warning] 804-804: Unknown word (Commentable) reported by cspell.
[warning] 1229-1229: Unknown word (Commentable) reported by cspell.
[warning] 1415-1415: Unknown word (Commentable) reported by cspell.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: test
- GitHub Check: build
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (44)
packages/mcp-server/src/lib/tools/projects.ts (2)
2-2
: LGTM! Logging refactor aligns with architectural standardizationThe change from
electron-log
to NestJSLogger
with context'ProjectTools'
is consistent with the broader logging standardization effort across the MCP server package. This improves consistency and integration with NestJS infrastructure.Also applies to: 8-8
94-94
: LGTM! Consistent error logging pattern throughoutAll error logging calls have been properly updated to use the new NestJS
Logger
instance, maintaining consistent error handling patterns across all tool functions.Also applies to: 137-137, 183-183, 228-228, 272-272, 317-317, 361-361, 396-396, 450-450, 499-499, 536-536, 583-583, 623-623, 665-665
packages/mcp-server/src/lib/common/version.ts (1)
2-3
: LGTM! Logging refactor follows consistent patternThe transition from
electron-log
to NestJSLogger
with context'Version'
aligns with the package-wide logging standardization. Good use of thenode:
prefix for Node.js built-in modules.Also applies to: 5-5
packages/mcp-server/src/lib/tools/employees.ts (2)
2-2
: LGTM! Addresses previously identified logging inconsistencyBased on retrieved learnings, this file was previously identified as having inconsistent logging (using
console.error
instead ofelectron-log
). The update to NestJSLogger
with context'EmployeeTools'
resolves this inconsistency and aligns with the package-wide standardization effort.Also applies to: 8-8
81-81
: LGTM! Comprehensive error logging standardizationAll error logging calls have been systematically updated to use the new NestJS
Logger
instance, ensuring consistent error handling across all employee tool functions.Also applies to: 121-121, 169-169, 213-213, 257-257, 297-297, 331-331, 369-369, 402-402, 440-440, 469-469, 497-497, 527-527, 557-557, 602-602
packages/mcp-server/src/lib/tools/organization-contact.ts (2)
2-2
: LGTM! Consistent logging refactor implementationThe change from
electron-log
to NestJSLogger
with context'OrganizationContactTools'
follows the established pattern across the MCP server package, contributing to the overall logging standardization effort.Also applies to: 7-7
66-66
: LGTM! Thorough error logging updatesAll error logging calls have been properly migrated to use the new NestJS
Logger
instance, maintaining consistent error handling patterns throughout all organization contact tool functions.Also applies to: 102-102, 161-161, 196-196, 230-230, 261-261, 290-290, 327-327, 357-357, 390-390, 425-425, 459-459, 499-499, 532-532, 567-567, 604-604, 639-639
packages/mcp-server/src/lib/tools/daily-plan.ts (1)
2-2
: LGTM! Logging standardization completed successfully.The migration from
electron-log
to NestJSLogger
is consistent and well-implemented. The context name 'DailyPlanTools' is descriptive and all error logging calls have been properly updated.Also applies to: 8-8, 62-62, 114-114, 163-163, 211-211, 259-259, 302-302, 351-351, 390-390, 427-427, 468-468, 509-509, 548-548, 594-594, 640-640, 687-687, 734-734, 775-775
packages/mcp-server/src/lib/tools/tasks.ts (1)
2-2
: LGTM! Consistent logging implementation.The NestJS Logger integration is properly implemented with an appropriate context name 'TaskTools'. This resolves the logging inconsistency mentioned in the retrieved learnings where this file was using
console.error
instead of the standardized logging approach.Also applies to: 14-14, 96-96, 142-142, 194-194, 243-243, 291-291, 338-338, 384-384, 419-419, 449-449, 476-476, 527-527, 567-567, 598-598, 646-646, 687-687, 730-730
packages/mcp-server/src/lib/tools/auth.ts (1)
2-2
: LGTM! Authentication logging properly standardized.The NestJS Logger integration is correctly implemented with proper context 'AuthTools'. Good use of security utilities (
sanitizeForLogging
,sanitizeErrorMessage
) for authentication-related logging, which is crucial for this sensitive module.Also applies to: 8-8, 52-52, 78-78, 119-119, 160-160, 202-202, 214-214
packages/mcp-server/src/lib/tools/test-connection.ts (1)
2-2
: LGTM! Test connection logging standardized effectively.The Logger implementation is consistent with proper context naming 'TestConnectionTools'. Security utilities are appropriately used for sanitizing logged data, which is important for connection testing operations.
Also applies to: 10-10, 52-52, 98-98, 156-156, 161-161
packages/mcp-server/src/lib/tools/timer.ts (1)
2-2
: LGTM! Logging standardization properly implemented.The NestJS Logger integration is consistent with appropriate context naming 'TimerTools'.
Also applies to: 7-7
packages/mcp-server/src/lib/mcp-server-manager.ts (2)
2-6
: LGTM - Logging migration to NestJS Logger!The replacement of
electron-log
with@nestjs/common
'sLogger
is consistent with the broader logging standardization across the MCP server package. The logger initialization with the 'McpServerManager' context is appropriate.
43-43
: LGTM - Standard logging calls updated correctly!The
logger.log
andlogger.warn
calls have been properly updated from the previous electron-log system. The message formatting and parameter usage are appropriate.Also applies to: 66-66, 89-89, 95-95, 111-111, 128-128, 145-145, 146-146, 180-180, 186-186, 194-194, 198-198
packages/mcp-server/src/lib/common/api-client.ts (2)
2-7
: LGTM - Consistent logging migration pattern!The replacement of
electron-log
with@nestjs/common
'sLogger
follows the established pattern across the MCP server package. The logger initialization with 'ApiClient' context is appropriate.
72-72
: LGTM - Standard logging calls updated correctly!The
logger.log
andlogger.warn
calls have been properly migrated from electron-log. The message formatting and parameter usage are appropriate for these standard logging operations.Also applies to: 97-101, 112-112, 172-172, 178-178, 299-299
packages/mcp-server/src/lib/environments/environment.ts (2)
2-6
: LGTM - Consistent logging migration!The replacement of
electron-log
with@nestjs/common
'sLogger
maintains consistency with the broader logging standardization effort. The logger initialization with 'Environment' context is appropriate.
27-27
: LGTM - Environment logging properly migrated!The logging calls have been correctly updated from
electron-log
to NestJSLogger
. The environment loading, validation error reporting, and timeout warnings are all properly formatted.Also applies to: 78-85, 103-103
packages/mcp-server/src/lib/common/auth-manager.ts (2)
3-5
: LGTM - Logging migration follows established pattern!The replacement of
electron-log
with@nestjs/common
'sLogger
is consistent with the package-wide logging standardization. The logger initialization with 'AuthManager' context is appropriate.
126-126
: LGTM - Authentication logging properly implemented!All logging calls have been correctly migrated from
electron-log
to NestJSLogger
. The authentication flow logging is comprehensive and includes proper error sanitization usingsanitizeForLogging
. The error handling maintains security best practices while providing useful diagnostic information.Also applies to: 141-141, 147-147, 184-186, 202-205, 212-212, 217-217, 232-232, 242-242, 248-248, 262-262, 269-269, 274-274, 292-292, 351-351, 357-357, 397-397
packages/mcp-server/src/lib/mcp-server.ts (3)
3-3
: LGTM - Logging migration consistent with package standards!The replacement of
electron-log
with@nestjs/common
'sLogger
follows the established pattern across the MCP server package. The logger initialization with 'McpServer' context is appropriate.Also applies to: 34-34
13-32
: LGTM - Comprehensive MCP server expansion!The addition of numerous new domain-specific tools (products, invoices, expenses, goals, deals, candidates, payments, equipment, etc.) significantly expands the MCP server's capabilities. The tool imports and registrations follow a consistent pattern and align with the broader package enhancement described in the PR.
Also applies to: 59-79
81-81
: LGTM - Standard logging calls updated correctly!The
logger.log
calls have been properly migrated from electron-log. The message formatting and context are appropriate for server initialization and lifecycle events.Also applies to: 96-96, 117-117, 125-126, 135-135, 140-140
packages/mcp-server/src/lib/tools/merchants.ts (3)
1-9
: LGTM! Imports follow the established patterns.The imports correctly use the
.js
extension for the MCP SDK and NestJS Logger for standardized logging.
10-22
: Helper function correctly validates organization context.The function appropriately checks for organization ID and provides a clear error message.
444-483
: Ignore the “redundant flags” suggestionAcross the codebase,
isActive
andisArchived
are treated as independent flags (see user-organization, employee, report, invitation, etc.), and active-merchant queries consistently filter on both. No change is needed in get_active_merchants.Likely an incorrect or invalid review comment.
packages/mcp-server/src/lib/tools/activity-logs.ts (2)
355-401
: Good implementation of time-based filtering.The date calculation for recent logs is well-implemented using proper millisecond conversion.
448-492
: Excellent safety mechanism for bulk deletion.The confirmation flag requirement prevents accidental deletions, which is a best practice for destructive bulk operations.
packages/mcp-server/src/lib/tools/pipelines.ts (1)
191-221
: Well-structured stage management with proper validation.The probability percentage validation (0-100) and RESTful nested endpoints are implemented correctly.
packages/mcp-server/src/lib/tools/incomes.ts (2)
23-32
: Good practice for date field conversion.The helper properly handles date string to Date object conversion with appropriate null/undefined checks.
446-487
: Proper handling of bulk income creation with date conversion.The bulk create tool correctly applies date conversion to each income record before sending to the API.
packages/mcp-server/src/lib/tools/products.ts (2)
1-9
: LGTM! Proper imports and logger setup.The imports are correctly structured with the required
.js
extension for the MCP SDK import, and the use of@nestjs/common
Logger aligns with the codebase's standardized logging approach.
34-82
: Well-implemented product listing tool.The tool properly validates organization context, constructs query parameters efficiently using conditional spreading, and includes comprehensive error handling with logging.
packages/mcp-server/src/lib/tools/skills.ts (1)
1-366
: Excellent implementation of skill management tools.The skill tools module is well-structured and follows the established patterns consistently:
- Proper imports with required
.js
extension for MCP SDK- Consistent organization context validation
- Comprehensive CRUD operations with employee skill assignments
- Proper error handling and logging throughout
- Clean parameter construction with conditional spreading
packages/mcp-server/src/lib/tools/equipment.ts (1)
34-645
: Comprehensive equipment management implementation.The equipment tools provide extensive functionality including:
- Full CRUD operations with proper validation
- Equipment assignment and sharing capabilities
- Statistics and search functionality
- Consistent error handling and logging
All tools follow established patterns and best practices.
packages/mcp-server/src/lib/tools/payments.ts (1)
33-578
: Well-designed payment management tools.The payment tools provide comprehensive financial operations with:
- Secure handling of payment data through API calls
- Proper status management for payment lifecycle
- Support for refunds with audit trail
- Overdue payment tracking
- Consistent validation and error handling
The implementation properly delegates financial logic to the backend API.
packages/mcp-server/src/lib/tools/key-results.ts (1)
33-485
: Excellent OKR key results implementation.The key results tools provide comprehensive OKR management with:
- Progress tracking with proper 0-100 validation
- Update history through dedicated endpoints
- Statistics and reporting capabilities
- Proper relationship handling with goals
- Consistent error handling and validation
The implementation aligns well with OKR best practices.
packages/mcp-server/src/lib/tools/goals.ts (1)
26-31
: Review Suggestion: Extend Date Conversion to All Goal Date Fields
The helperconvertGoalDateFields
inpackages/mcp-server/src/lib/tools/goals.ts
only convertsdeadline
. Please confirm whether the Goal schema includes other date properties—such ascreatedAt
,updatedAt
, orstartDate
—and update this function to convert them as well for consistency.• Location: lines 26–31 in tools/goals.ts
• Action: Inspect the Goal schema for any additional date fields and add conversions likecreatedAt: goalData.createdAt ? new Date(goalData.createdAt) : undefined, updatedAt: goalData.updatedAt ? new Date(goalData.updatedAt) : undefined, startDate: goalData.startDate ? new Date(goalData.startDate) : undefined,…alongside
deadline
conversion.packages/mcp-server/src/lib/tools/deals.ts (1)
348-387
: No date conversion needed for deal statisticsThe
get_deal_statistics
tool’sstartDate
andendDate
parameters are defined as ISO-format strings and passed directly to the API, matching the existing pattern inget_goal_statistics
(and other statistics tools) which also use string parameters without converting them toDate
objects. Since the Zod schemas and backend endpoints expect ISO strings, no additional date-to-Date
conversion helper is required here.Likely an incorrect or invalid review comment.
packages/mcp-server/src/lib/tools/candidates.ts (2)
1-9
: LGTM! Imports follow established patterns.The imports correctly use the
.js
extension for the MCP SDK and use the standardized NestJS Logger, consistent with the project's conventions.
13-34
: Well-structured helper functions.The helper functions properly validate organization context and handle date conversions with appropriate null safety.
packages/mcp-server/src/lib/tools/employee-awards.ts (1)
1-9
: LGTM! Consistent with project conventions.Imports correctly follow the established patterns with proper
.js
extension for MCP SDK and NestJS Logger usage.packages/mcp-server/src/lib/tools/product-categories.ts (1)
1-22
: LGTM! Clean setup with proper conventions.The file setup follows all established patterns correctly.
packages/mcp-server/src/lib/schema.ts (1)
755-1382
: Well-structured schema additions with comprehensive coverage.The new schemas provide excellent coverage for the expanded MCP server functionality. Each schema is well-designed with appropriate:
- Type safety using Zod validation
- Consistent patterns following the existing codebase conventions
- Proper use of relations and collections
- Appropriate optional fields and defaults
Once the duplicate schema issues are resolved, these additions will provide a solid foundation for the new MCP tools.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
♻️ Duplicate comments (2)
.cspell.json (2)
112-112
: Lowercase variant of “Distributables” still missing (previously noted)
See earlier review; the word appears only in capitalised form.
436-436
: Hyphenated / camel-case forms of “servermcp” still absent (previously noted)
Prior feedback suggested adding “server-mcp” and “serverMCP” to cover all usages.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
.cspell.json
(3 hunks)
🧰 Additional context used
🧠 Learnings (8)
📓 Common learnings
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9029
File: packages/mcp-server/src/lib/tools/employees.ts:78-600
Timestamp: 2025-07-25T05:08:34.515Z
Learning: In the ever-co/ever-gauzy packages/mcp-server shared package, electron-log is used consistently across most tool files for logging, but some files (employees.ts, tasks.ts, daily-plan.ts) still use console.error creating an inconsistency. The electron-log library works in both Electron and Node.js contexts, so it's safe to use throughout the shared package for consistent logging behavior.
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9029
File: packages/mcp-server/src/lib/tools/employees.ts:78-600
Timestamp: 2025-07-25T05:08:34.515Z
Learning: In the ever-co/ever-gauzy packages/mcp-server shared package, electron-log is successfully used across multiple core files (api-client.ts, auth-manager.ts, mcp-server.ts, etc.) without any conditional logic or fallbacks. This proves electron-log works reliably in both Electron and standalone Node.js contexts within this codebase. The files using console.error (employees.ts, tasks.ts, daily-plan.ts) are inconsistent outliers that should use log.error for consistency.
📚 Learning: in the ever-co/ever-gauzy packages/mcp-server, when importing from the external sdk @modelcontextpro...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9072
File: packages/mcp-server/src/lib/tools/daily-plan.ts:4-6
Timestamp: 2025-07-30T15:25:57.253Z
Learning: In the ever-co/ever-gauzy packages/mcp-server, when importing from the external SDK @modelcontextprotocol/sdk, the .js extension should be kept in import paths (e.g., '@modelcontextprotocol/sdk/server/mcp.js') to ensure the MCP server app builds successfully. This applies to all files using the @modelcontextprotocol/sdk package, while internal/relative imports should not use the .js extension.
Applied to files:
.cspell.json
📚 Learning: in packages/mcp-server/src/lib/config/server-info.ts, the user rolandm99 confirmed that the server n...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9029
File: packages/mcp-server/src/lib/config/server-info.ts:2-2
Timestamp: 2025-07-25T04:53:31.370Z
Learning: In packages/mcp-server/src/lib/config/server-info.ts, the user RolandM99 confirmed that the server name "Gauzy MCP Server" should remain hardcoded because it will stay the same across all environments (development, staging, production). The user prefers this approach over using environment variables for the server name.
Applied to files:
.cspell.json
📚 Learning: in the ever-co/ever-gauzy project's apps/server-mcp/tsconfig.electron.json, the "electron" type shou...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9068
File: apps/server-mcp/tsconfig.electron.json:17-18
Timestamp: 2025-07-29T21:00:16.321Z
Learning: In the ever-co/ever-gauzy project's apps/server-mcp/tsconfig.electron.json, the "electron" type should be removed from the types array because the project no longer uses Electron APIs and has moved to a Node.js-only architecture. Adding "electron" types causes build errors in their current setup, so only "node" types should be included.
Applied to files:
.cspell.json
📚 Learning: in the ever-co/ever-gauzy codebase, the backend api uses camelcase naming conventions for field name...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9029
File: packages/mcp-server/src/lib/tools/organization-contact.ts:12-25
Timestamp: 2025-07-23T10:56:18.549Z
Learning: In the ever-co/ever-gauzy codebase, the backend API uses camelCase naming conventions for field names (e.g., organizationId, tenantId, employeeId, primaryEmail). When implementing MCP tools and schema validation, field names should use camelCase to match the backend entity structure, not snake_case.
Applied to files:
.cspell.json
📚 Learning: in packages/mcp-server/src/lib/common/security-utils.ts, the user rolandm99 specifically wants to ke...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9029
File: packages/mcp-server/src/lib/common/security-utils.ts:9-53
Timestamp: 2025-07-23T02:22:13.652Z
Learning: In packages/mcp-server/src/lib/common/security-utils.ts, the user RolandM99 specifically wants to keep the existing regex patterns for sanitizing error messages, including the API key pattern `/[a-zA-Z0-9]{32,}/g` and email regex `/[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}/g`, as they are intentionally designed this way for their use case.
Applied to files:
.cspell.json
📚 Learning: in the ever-co/ever-gauzy packages/mcp-server shared package, electron-log is used consistently acro...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9029
File: packages/mcp-server/src/lib/tools/employees.ts:78-600
Timestamp: 2025-07-25T05:08:34.515Z
Learning: In the ever-co/ever-gauzy packages/mcp-server shared package, electron-log is used consistently across most tool files for logging, but some files (employees.ts, tasks.ts, daily-plan.ts) still use console.error creating an inconsistency. The electron-log library works in both Electron and Node.js contexts, so it's safe to use throughout the shared package for consistent logging behavior.
Applied to files:
.cspell.json
📚 Learning: in the ever-co/ever-gauzy packages/mcp-server shared package, electron-log is successfully used acro...
Learnt from: RolandM99
PR: ever-co/ever-gauzy#9029
File: packages/mcp-server/src/lib/tools/employees.ts:78-600
Timestamp: 2025-07-25T05:08:34.515Z
Learning: In the ever-co/ever-gauzy packages/mcp-server shared package, electron-log is successfully used across multiple core files (api-client.ts, auth-manager.ts, mcp-server.ts, etc.) without any conditional logic or fallbacks. This proves electron-log works reliably in both Electron and standalone Node.js contexts within this codebase. The files using console.error (employees.ts, tasks.ts, daily-plan.ts) are inconsistent outliers that should use log.error for consistency.
Applied to files:
.cspell.json
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Codacy Static Code Analysis
- GitHub Check: test
- GitHub Check: build
PR
Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.