-
-
Notifications
You must be signed in to change notification settings - Fork 193
feat: add MCP resources for list_devices, diagnostic, and swift_package_list #81
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
Conversation
…ge_list Add three new MCP resources to complement existing tools: - mcp://xcodebuild/devices - Connected physical Apple devices - mcp://xcodebuild/environment - Development environment diagnostics - mcp://xcodebuild/swift-packages - Running Swift Package processes Key features: - Reuse existing tool logic for consistency - Comprehensive test coverage following no-vitest-mocking guidelines - Proper error handling and logging - Maintain backward compatibility with existing tools - Auto-discovered by build system (4 total resources now available) 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Cameron Cooke <cameroncooke@users.noreply.github.com>
WalkthroughThree new resource plugins ( Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant ResourcePlugin
participant Executor
participant LogicModule
Client->>ResourcePlugin: Request resource (devices/environment/swift-packages)
ResourcePlugin->>Executor: (optional) Execute command
Executor->>LogicModule: Invoke logic (list_devicesLogic/diagnosticLogic/swift_package_listLogic)
LogicModule-->>Executor: Return result or error
Executor-->>ResourcePlugin: Return execution result
ResourcePlugin-->>Client: Return { contents: [ { text: ... } ] }
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~15–20 minutes Possibly related PRs
Poem
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ 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). (2)
✨ 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. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
Claude finished @cameroncooke's task —— View job Code Review Complete ✅I've thoroughly reviewed the PR that adds 3 new MCP resources (devices, environment, swift-packages) with comprehensive test coverage. Overall AssessmentThis is a high-quality PR that follows established project patterns and guidelines well. The resources correctly reuse existing tool logic for consistency and maintain backward compatibility. ✅ StrengthsArchitecture & Design
Testing Quality
Error Handling
|
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.
Bugbot free trial expires on August 7, 2025
Learn more in the Cursor dashboard.
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: 2
🧹 Nitpick comments (2)
src/mcp/resources/devices.ts (1)
23-30: Consider improving error handling consistency.The error checking logic extracts the error text and throws a new Error, but this could be simplified for better consistency with the other resources in this PR.
Consider this approach for consistency:
- if (result.isError) { - const errorText = result.content[0]?.text; - throw new Error( - typeof errorText === 'string' ? errorText : 'Failed to retrieve device data', - ); - } + if (result.isError) { + throw new Error( + typeof result.content[0]?.text === 'string' + ? result.content[0].text + : 'Failed to retrieve device data' + ); + }src/mcp/resources/environment.ts (1)
18-18: Unused parameter should be prefixed with underscore.The
uriparameter is not used in the handler function. According to the coding guidelines, unused variables should be prefixed with an underscore.Apply this diff:
async handler( - uri: URL, + _uri: URL, executor: CommandExecutor = getDefaultCommandExecutor(), ): Promise<{ contents: Array<{ text: string }> }> {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
src/mcp/resources/__tests__/devices.test.ts(1 hunks)src/mcp/resources/__tests__/environment.test.ts(1 hunks)src/mcp/resources/__tests__/swift-packages.test.ts(1 hunks)src/mcp/resources/devices.ts(1 hunks)src/mcp/resources/environment.ts(1 hunks)src/mcp/resources/swift-packages.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.cursorrules)
**/*.{ts,tsx}: Explicit function return types are required in TypeScript files
Do not use console.log; use console.error for MCP logging
Prefix unused variables with an underscore in TypeScript files
Use ES Modules syntax (import/export) in all TypeScript files
Prefer explicit imports over wildcard imports in TypeScript files
Group imports in the following order: Node.js modules, third-party modules, then local modules
Name variables and functions in camelCase
Name classes in PascalCase
Prefer async/await over Promises in asynchronous code
Error handling should use typed errors from utils/errors.ts
Use ESLint for linting vianpm run lintandnpm run lint:fix
Use Prettier for formatting vianpm run formatandnpm run format:check
Log errors appropriately and integrate with Sentry for production error tracking
Handle both synchronous and asynchronous errors
Use appropriate log levels and structured logging in all TypeScript files
Include JSDoc comments for public APIs
Sanitize error messages before reporting to Sentry
Files:
src/mcp/resources/__tests__/devices.test.tssrc/mcp/resources/__tests__/environment.test.tssrc/mcp/resources/environment.tssrc/mcp/resources/__tests__/swift-packages.test.tssrc/mcp/resources/devices.tssrc/mcp/resources/swift-packages.ts
src/**/*.ts
📄 CodeRabbit Inference Engine (.cursorrules)
Name files in kebab-case
Files:
src/mcp/resources/__tests__/devices.test.tssrc/mcp/resources/__tests__/environment.test.tssrc/mcp/resources/environment.tssrc/mcp/resources/__tests__/swift-packages.test.tssrc/mcp/resources/devices.tssrc/mcp/resources/swift-packages.ts
**/*.ts
📄 CodeRabbit Inference Engine (CLAUDE.md)
**/*.ts: Use TypeScript strictly - noanytypes.
Add proper error handling and logging.
Files:
src/mcp/resources/__tests__/devices.test.tssrc/mcp/resources/__tests__/environment.test.tssrc/mcp/resources/environment.tssrc/mcp/resources/__tests__/swift-packages.test.tssrc/mcp/resources/devices.tssrc/mcp/resources/swift-packages.ts
🧠 Learnings (4)
src/mcp/resources/__tests__/devices.test.ts (5)
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Tools must follow the MCP tool schema with proper parameter validation using Zod
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/tools/* : Platform-specific tools should be organized in src/tools/, grouped by functionality (e.g., build tools as build_*.ts, simulator management as simulator.ts, etc.).
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Implement proper error handling with descriptive messages in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/tools/axe.ts : Simulator UI automation should use the bundled AXe tool (bundled/axe), with coordinate extraction from the UI hierarchy, implemented in src/tools/axe.ts.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : All xcodebuild operations must be asynchronous and use async/await
src/mcp/resources/__tests__/environment.test.ts (6)
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/utils/tool-groups.ts : Environment variables should control which tools are exposed, as managed in src/utils/tool-groups.ts.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Properly clean up spawned processes in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Tools must follow the MCP tool schema with proper parameter validation using Zod
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Manage temporary files and directories appropriately in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Handle process spawning and cleanup correctly in async operations
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Implement proper error handling with descriptive messages in tool modules
src/mcp/resources/environment.ts (2)
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/utils/xcodemake.ts : Experimental incremental builds should use xcodemake instead of xcodebuild, enabled via the INCREMENTAL_BUILDS_ENABLED environment variable, and implemented in src/utils/xcodemake.ts.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/utils/tool-groups.ts : Environment variables should control which tools are exposed, as managed in src/utils/tool-groups.ts.
src/mcp/resources/__tests__/swift-packages.test.ts (1)
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : All xcodebuild operations must be asynchronous and use async/await
🧬 Code Graph Analysis (1)
src/mcp/resources/__tests__/devices.test.ts (1)
src/utils/command.ts (1)
createMockExecutor(230-268)
⏰ 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). (2)
- GitHub Check: Cursor Bugbot
- GitHub Check: claude-review
🔇 Additional comments (36)
src/mcp/resources/devices.ts (4)
16-19: LGTM - Proper TypeScript function signature with explicit return type.The handler function correctly specifies explicit return types and uses proper parameter typing as required by the coding guidelines.
8-9: LGTM - Proper import organization and explicit imports.The imports follow the coding guidelines with explicit imports (not wildcards) and proper grouping with local modules after utility imports.
21-21: LGTM - Appropriate logging usage.Uses the
log()function instead ofconsole.logas required by the coding guidelines, with proper log level.
42-53: LGTM - Proper error handling and logging.The catch block correctly handles errors with appropriate logging and returns a structured error response. The error message extraction follows TypeScript best practices.
src/mcp/resources/__tests__/devices.test.ts (7)
1-4: LGTM - Proper test imports and setup.The imports follow coding guidelines with explicit imports and proper test framework usage.
7-25: LGTM - Comprehensive export field validation.The export field validation tests properly verify all required metadata fields (uri, description, mimeType, handler) which ensures the resource is properly configured.
28-45: LGTM - Well-structured success scenario test.The test properly mocks successful device data retrieval and verifies the expected content structure and specific device information.
47-62: LGTM - Proper error handling test.Tests command execution failure scenario and verifies appropriate error messages are returned in the response structure.
64-75: LGTM - Spawn error handling test.Properly tests spawn error scenarios using createMockExecutor with Error object, ensuring robust error handling.
77-91: LGTM - Empty data fallback test.Tests the fallback behavior when no device data is available and verifies the expected messaging about Xcode 15 requirements.
93-107: LGTM - Next steps guidance test.Tests that device data includes proper guidance information, ensuring users get helpful context with the device listing.
src/mcp/resources/__tests__/environment.test.ts (7)
1-4: LGTM - Proper test setup and imports.Clean import structure following coding guidelines with explicit imports from appropriate modules.
7-25: LGTM - Complete export field validation.Thorough validation of all exported resource metadata ensures proper MCP resource configuration.
28-46: LGTM - Comprehensive diagnostic report validation.The test properly verifies that all required diagnostic sections are present in the environment resource output, ensuring users get complete diagnostic information.
48-59: LGTM - Robust spawn error handling test.Properly tests spawn error scenarios and verifies that diagnostic information is still provided even when errors occur.
61-76: LGTM - Detailed diagnostic section verification.Tests verify specific diagnostic content including troubleshooting tips and environment variable configuration, ensuring users get actionable information.
78-93: LGTM - Feature status information validation.Properly validates that feature status sections are included, providing users with information about UI automation, incremental builds, and other capabilities.
95-109: LGTM - Graceful error condition handling.Tests ensure that even under error conditions, the diagnostic report structure is maintained, providing consistent user experience.
src/mcp/resources/__tests__/swift-packages.test.ts (7)
1-4: LGTM - Clean test imports and setup.Proper import organization following coding guidelines with explicit imports from appropriate test utilities.
7-26: LGTM - Thorough export field validation.Complete validation of resource metadata including proper handler function verification using both
toBeDefined()and type checking.
29-43: LGTM - Proper no-processes scenario test.Tests the common scenario where no Swift Package processes are running and verifies appropriate user guidance is provided.
45-56: LGTM - Robust spawn error handling.Properly tests spawn error scenarios and verifies graceful degradation with standard messaging.
58-73: LGTM - Consistent messaging validation.Duplicates the no-processes test scenario which provides good coverage assurance for this common case.
75-91: LGTM - Error response handling test.Tests command failure scenarios and verifies the resource handles errors gracefully with standard messaging.
93-106: LGTM - Content combination verification.Tests that multiple content parts are properly combined into a single string response, ensuring consistent output format.
src/mcp/resources/swift-packages.ts (4)
16-19: LGTM - Proper TypeScript function signature.The handler function has explicit return types and proper parameter typing as required by coding guidelines.
8-9: LGTM - Proper import organization.Imports follow coding guidelines with explicit imports and appropriate module organization.
32-36: LGTM - Proper content combination logic.The implementation correctly combines multiple content parts into a single response with appropriate fallback handling.
44-55: LGTM - Consistent error handling and logging.Error handling follows the same pattern as other resources with proper logging and structured error responses.
src/mcp/resources/environment.ts (7)
1-6: JSDoc comment looks good.The comment provides clear context about the resource's purpose and mentions reusing existing diagnostic logic for consistency.
8-9: Import organization follows guidelines.The imports are properly structured with Node.js/utility modules first, then local modules. ES modules syntax is correctly used.
11-16: Resource metadata is well-defined.The URI scheme, name, description, and MIME type are appropriately configured for an environment diagnostic resource.
17-20: Handler function signature is correct.The explicit return type is properly declared and follows TypeScript guidelines. The parameter types are correctly specified.
33-42: Success path implementation is solid.The success response construction properly handles the diagnostic result and includes appropriate fallback text. The type checking for the text content is thorough.
43-54: Catch block follows proper error handling guidelines.The error handling correctly extracts the error message, logs appropriately using the specified logging function, and returns a structured error response instead of throwing.
17-20: Missing explicit return type annotation.The coding guidelines require explicit function return types in TypeScript files. The return type should be explicitly declared.
Apply this diff to add the explicit return type:
async handler( uri: URL, executor: CommandExecutor = getDefaultCommandExecutor(), - ): Promise<{ contents: Array<{ text: string }> }> { + ): Promise<{ contents: Array<{ text: string }> }> {Wait, I see the return type is already present. Let me re-examine this more carefully.
⛔ Skipped due to learnings
Learnt from: CR PR: cameroncooke/XcodeBuildMCP#0 File: .cursorrules:0-0 Timestamp: 2025-07-22T19:53:45.001Z Learning: Applies to **/*.{ts,tsx} : Explicit function return types are required in TypeScript filesLearnt from: CR PR: cameroncooke/XcodeBuildMCP#0 File: .cursorrules:0-0 Timestamp: 2025-07-22T19:53:45.001Z Learning: Applies to **/*.{ts,tsx} : Prefer async/await over Promises in asynchronous codeLearnt from: CR PR: cameroncooke/XcodeBuildMCP#0 File: .cursorrules:0-0 Timestamp: 2025-07-22T19:53:45.001Z Learning: Applies to **/*.{ts,tsx} : Handle both synchronous and asynchronous errorsLearnt from: CR PR: cameroncooke/XcodeBuildMCP#0 File: CLAUDE.md:0-0 Timestamp: 2025-07-22T19:54:09.554Z Learning: Applies to {src/tools/*,src/utils/command.ts} : External command execution should use the standardized pattern provided by `src/utils/command.ts`.Learnt from: CR PR: cameroncooke/XcodeBuildMCP#0 File: .cursorrules:0-0 Timestamp: 2025-07-22T19:53:45.001Z Learning: Applies to src/tools/*.ts : Handle process spawning and cleanup correctly in async operations
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
|
Claude finished @cameroncooke's task —— View job Code Review Complete ✅I've thoroughly reviewed the PR that adds 3 new MCP resources (devices, environment, swift-packages) with comprehensive test coverage. Overall AssessmentThis is a high-quality PR that follows established project patterns and guidelines well. The resources correctly reuse existing tool logic for consistency and maintain backward compatibility. ✅ StrengthsArchitecture & Design
Testing Quality
Error Handling
|
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
|
Claude finished @cameroncooke's task —— View job Code Review Complete ✅I've thoroughly reviewed the PR that adds 3 new MCP resources (devices, environment, swift-packages) with comprehensive test coverage. Overall AssessmentThis is a high-quality PR that follows established project patterns and guidelines well. The resources correctly reuse existing tool logic for consistency and maintain backward compatibility. ✅ StrengthsArchitecture & Design
Testing Quality
Error Handling
|
- Extracted resource logic into separate functions for better testability in `example.ts`, `devices.ts`, `environment.ts`, `simulators.ts`, `swift-packages.ts`. - Updated handler signatures to comply with MCP SDK requirements, ensuring they only accept necessary parameters. - Enhanced error logging and response formatting in resource logic functions. - Updated tests to directly call the new resource logic functions instead of the handlers. - Added validation for exported fields in resource modules. - Implemented checks for handler signature violations in the testing script. - Adjusted tool handlers to ensure they follow the new signature requirements.
|
Claude finished @cameroncooke's task —— View job I'll analyze this and get back to you. |
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: 0
🧹 Nitpick comments (1)
docs/PLUGIN_DEVELOPMENT.md (1)
345-347: Consider explicitly passing the default executor for consistency.While the current implementation works due to the default parameter in
exampleResourceLogic, it would be more consistent with the tool pattern to explicitly pass the executor:- return exampleResourceLogic(); + return exampleResourceLogic(getDefaultCommandExecutor());This makes the dependency injection more explicit and aligns with the pattern shown in
TESTING.md.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (14)
docs/ARCHITECTURE.md(1 hunks)docs/PLUGIN_DEVELOPMENT.md(3 hunks)docs/TESTING.md(3 hunks)scripts/check-test-patterns.js(9 hunks)src/mcp/resources/__tests__/devices.test.ts(1 hunks)src/mcp/resources/__tests__/environment.test.ts(1 hunks)src/mcp/resources/__tests__/simulators.test.ts(9 hunks)src/mcp/resources/__tests__/swift-packages.test.ts(1 hunks)src/mcp/resources/devices.ts(1 hunks)src/mcp/resources/environment.ts(1 hunks)src/mcp/resources/simulators.ts(1 hunks)src/mcp/resources/swift-packages.ts(1 hunks)src/mcp/tools/device-shared/list_devices.ts(1 hunks)src/mcp/tools/swift-package/swift_package_list.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (6)
- src/mcp/resources/tests/environment.test.ts
- src/mcp/resources/tests/swift-packages.test.ts
- src/mcp/resources/tests/devices.test.ts
- src/mcp/resources/swift-packages.ts
- src/mcp/resources/devices.ts
- src/mcp/resources/environment.ts
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.cursorrules)
**/*.{ts,tsx}: Explicit function return types are required in TypeScript files
Do not use console.log; use console.error for MCP logging
Prefix unused variables with an underscore in TypeScript files
Use ES Modules syntax (import/export) in all TypeScript files
Prefer explicit imports over wildcard imports in TypeScript files
Group imports in the following order: Node.js modules, third-party modules, then local modules
Name variables and functions in camelCase
Name classes in PascalCase
Prefer async/await over Promises in asynchronous code
Error handling should use typed errors from utils/errors.ts
Use ESLint for linting vianpm run lintandnpm run lint:fix
Use Prettier for formatting vianpm run formatandnpm run format:check
Log errors appropriately and integrate with Sentry for production error tracking
Handle both synchronous and asynchronous errors
Use appropriate log levels and structured logging in all TypeScript files
Include JSDoc comments for public APIs
Sanitize error messages before reporting to Sentry
Files:
src/mcp/tools/device-shared/list_devices.tssrc/mcp/tools/swift-package/swift_package_list.tssrc/mcp/resources/__tests__/simulators.test.tssrc/mcp/resources/simulators.ts
src/**/*.ts
📄 CodeRabbit Inference Engine (.cursorrules)
Name files in kebab-case
Files:
src/mcp/tools/device-shared/list_devices.tssrc/mcp/tools/swift-package/swift_package_list.tssrc/mcp/resources/__tests__/simulators.test.tssrc/mcp/resources/simulators.ts
**/*.ts
📄 CodeRabbit Inference Engine (CLAUDE.md)
**/*.ts: Use TypeScript strictly - noanytypes.
Add proper error handling and logging.
Files:
src/mcp/tools/device-shared/list_devices.tssrc/mcp/tools/swift-package/swift_package_list.tssrc/mcp/resources/__tests__/simulators.test.tssrc/mcp/resources/simulators.ts
🧠 Learnings (8)
src/mcp/tools/device-shared/list_devices.ts (7)
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Tools must follow the MCP tool schema with proper parameter validation using Zod
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Implement proper error handling with descriptive messages in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Provide clear, actionable error messages in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to {src/tools/*,src/utils/command.ts} : External command execution should use the standardized pattern provided by src/utils/command.ts.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Handle process spawning and cleanup correctly in async operations
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Always validate tool parameters with Zod in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : All xcodebuild operations must be asynchronous and use async/await
src/mcp/tools/swift-package/swift_package_list.ts (2)
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : All xcodebuild operations must be asynchronous and use async/await
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Handle process spawning and cleanup correctly in async operations
src/mcp/resources/__tests__/simulators.test.ts (3)
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/tools/axe.ts : Simulator UI automation should use the bundled AXe tool (bundled/axe), with coordinate extraction from the UI hierarchy, implemented in src/tools/axe.ts.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : All xcodebuild operations must be asynchronous and use async/await
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Handle process spawning and cleanup correctly in async operations
src/mcp/resources/simulators.ts (6)
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to {src/tools/*,src/utils/command.ts} : External command execution should use the standardized pattern provided by src/utils/command.ts.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Handle process spawning and cleanup correctly in async operations
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/tools/axe.ts : Simulator UI automation should use the bundled AXe tool (bundled/axe), with coordinate extraction from the UI hierarchy, implemented in src/tools/axe.ts.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/tools/* : Platform-specific tools should be organized in src/tools/, grouped by functionality (e.g., build tools as build_*.ts, simulator management as simulator.ts, etc.).
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/server/server.ts : Server configuration and MCP server setup should be implemented in src/server/server.ts.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : All xcodebuild operations must be asynchronous and use async/await
docs/TESTING.md (19)
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to {src/tools/*,src/utils/command.ts} : External command execution should use the standardized pattern provided by src/utils/command.ts.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Handle process spawning and cleanup correctly in async operations
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to CHANGELOG.md : Update CHANGELOG.md when adding or updating tools or dependencies
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Implement proper error handling with descriptive messages in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Properly clean up spawned processes in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/utils/register-tools.ts : Tools must be registered in src/utils/register-tools.ts using the registerTool helper from src/tools/common.ts
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Tools must follow the MCP tool schema with proper parameter validation using Zod
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/utils/register-tools.ts : Tools must be registered in src/utils/register-tools.ts using a centralized system with workflow-based grouping.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : All xcodebuild operations must be asynchronous and use async/await
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Each tool must be a separate module in src/tools/
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Always validate tool parameters with Zod in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/utils/tool-groups.ts : Tool registration is managed by ToolsetManager in src/utils/tool-groups.ts
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to {src/tools/*,src/utils/register-tools.ts,src/utils/tool-groups.ts,TOOLS.md} : When adding a new tool, create the tool implementation in src/tools/, define a Zod schema for parameters, register the tool in src/utils/register-tools.ts, add it to the appropriate tool group in src/utils/tool-groups.ts, and update TOOLS.md with the new tool's name, MCP tool name, and description.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/tools/* : Platform-specific tools should be organized in src/tools/, grouped by functionality (e.g., build tools as build_*.ts, simulator management as simulator.ts, etc.).
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Provide clear, actionable error messages in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to **/*.{ts,tsx} : Prefer async/await over Promises in asynchronous code
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Manage temporary files and directories appropriately in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to **/*.{ts,tsx} : Handle both synchronous and asynchronous errors
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Implement timeouts for long-running operations in tool modules
docs/ARCHITECTURE.md (10)
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/server/server.ts : Server configuration and MCP server setup should be implemented in src/server/server.ts.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to {src/tools/*,src/utils/command.ts} : External command execution should use the standardized pattern provided by src/utils/command.ts.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Tools must follow the MCP tool schema with proper parameter validation using Zod
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/utils/* : Shared utilities such as command execution, validation, logging, and error handling should be placed in src/utils/.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : All xcodebuild operations must be asynchronous and use async/await
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Handle process spawning and cleanup correctly in async operations
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to **/*.{ts,tsx} : Do not use console.log; use console.error for MCP logging
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/utils/register-tools.ts : Tools must be registered in src/utils/register-tools.ts using a centralized system with workflow-based grouping.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/tools/* : Platform-specific tools should be organized in src/tools/, grouped by functionality (e.g., build tools as build_*.ts, simulator management as simulator.ts, etc.).
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to {src/tools/*,src/utils/register-tools.ts,src/utils/tool-groups.ts,TOOLS.md} : When adding a new tool, create the tool implementation in src/tools/, define a Zod schema for parameters, register the tool in src/utils/register-tools.ts, add it to the appropriate tool group in src/utils/tool-groups.ts, and update TOOLS.md with the new tool's name, MCP tool name, and description.
docs/PLUGIN_DEVELOPMENT.md (17)
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Tools must follow the MCP tool schema with proper parameter validation using Zod
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to {src/tools/*,src/utils/register-tools.ts,src/utils/tool-groups.ts,TOOLS.md} : When adding a new tool, create the tool implementation in src/tools/, define a Zod schema for parameters, register the tool in src/utils/register-tools.ts, add it to the appropriate tool group in src/utils/tool-groups.ts, and update TOOLS.md with the new tool's name, MCP tool name, and description.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/server/server.ts : Server configuration and MCP server setup should be implemented in src/server/server.ts.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to {src/tools/*,src/utils/command.ts} : External command execution should use the standardized pattern provided by src/utils/command.ts.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Update documentation for new features.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/utils/* : Shared utilities such as command execution, validation, logging, and error handling should be placed in src/utils/.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : All xcodebuild operations must be asynchronous and use async/await
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Handle process spawning and cleanup correctly in async operations
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to **/*.{ts,tsx} : Do not use console.log; use console.error for MCP logging
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/tools/* : Platform-specific tools should be organized in src/tools/, grouped by functionality (e.g., build tools as build_*.ts, simulator management as simulator.ts, etc.).
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/tools/axe.ts : Simulator UI automation should use the bundled AXe tool (bundled/axe), with coordinate extraction from the UI hierarchy, implemented in src/tools/axe.ts.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/utils/register-tools.ts : Tools must be registered in src/utils/register-tools.ts using a centralized system with workflow-based grouping.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Each tool must be a separate module in src/tools/
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/utils/register-tools.ts : Tools must be registered in src/utils/register-tools.ts using the registerTool helper from src/tools/common.ts
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Test with example projects before submitting.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Validate all external inputs in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Implement proper error handling with descriptive messages in tool modules
scripts/check-test-patterns.js (20)
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Tools must follow the MCP tool schema with proper parameter validation using Zod
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Implement proper error handling with descriptive messages in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Provide clear, actionable error messages in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to {src/tools/*,src/utils/command.ts} : External command execution should use the standardized pattern provided by src/utils/command.ts.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Validate all external inputs in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to **/*.ts : Add proper error handling and logging.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Manage temporary files and directories appropriately in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Handle process spawning and cleanup correctly in async operations
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Always validate tool parameters with Zod in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Each tool must be a separate module in src/tools/
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to **/*.{ts,tsx} : Do not use console.log; use console.error for MCP logging
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : All xcodebuild operations must be asynchronous and use async/await
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to **/*.{ts,tsx} : Prefer async/await over Promises in asynchronous code
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to **/*.{ts,tsx} : Handle both synchronous and asynchronous errors
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/tools/* : Platform-specific tools should be organized in src/tools/, grouped by functionality (e.g., build tools as build_*.ts, simulator management as simulator.ts, etc.).
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/tools/*.ts : Properly clean up spawned processes in tool modules
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to src/utils/register-tools.ts : Tools must be registered in src/utils/register-tools.ts using the registerTool helper from src/tools/common.ts
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T19:54:09.554Z
Learning: Applies to src/utils/register-tools.ts : Tools must be registered in src/utils/register-tools.ts using a centralized system with workflow-based grouping.
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to **/*.{ts,tsx} : Use appropriate log levels and structured logging in all TypeScript files
Learnt from: CR
PR: cameroncooke/XcodeBuildMCP#0
File: .cursorrules:0-0
Timestamp: 2025-07-22T19:53:45.001Z
Learning: Applies to **/*.{ts,tsx} : Use Prettier for formatting via npm run format and npm run format:check
⏰ 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). (1)
- GitHub Check: Cursor Bugbot
🔇 Additional comments (14)
src/mcp/tools/swift-package/swift_package_list.ts (1)
69-71: LGTM: Handler signature standardizationThe handler signature has been correctly standardized to accept only the required
argsparameter, following the consistent pattern applied across MCP tools and resources in this PR. The separation of concerns between the handler (thin wrapper) and the logic function (contains dependencies) improves testability and maintainability.src/mcp/tools/device-shared/list_devices.ts (1)
279-281: LGTM: Handler signature consistency improvementThe
argsparameter is now correctly required instead of optional, aligning with the standardized handler signature pattern applied across the MCP ecosystem. This ensures consistent parameter handling while maintaining the existing functionality.src/mcp/resources/__tests__/simulators.test.ts (2)
4-4: LGTM: Import updated for logic function testingThe import correctly includes the new
simulatorsResourceLogicfunction, enabling direct testing of the resource logic with injected dependencies.
46-46: LGTM: Test refactoring improves testabilityAll test cases have been correctly updated to call
simulatorsResourceLogicdirectly instead of the handler. This approach provides better test isolation by allowing direct dependency injection with mock executors, following the established testing patterns in this codebase.Also applies to: 61-61, 74-74, 83-83, 96-96, 119-119, 147-147, 170-170
docs/ARCHITECTURE.md (1)
204-256: Excellent documentation of the new resource patternThis comprehensive example clearly demonstrates the architectural pattern for MCP resources introduced in this PR:
- Separation of concerns: Logic function separated from handler
- Dependency injection: Executor parameter with default for testability
- Proper error handling: Structured error responses with logging
- Type safety: Explicit return types and error message handling
- Consistent interface: Handler as thin wrapper calling logic function
The example provides developers with a clear template for implementing new resources following the established patterns.
src/mcp/resources/simulators.ts (2)
11-48: Excellent implementation of the resource logic patternThe extracted
simulatorsResourceLogicfunction perfectly implements the architectural pattern:
- Proper separation: Logic extracted from handler for reusability and testability
- Dependency injection: Optional executor parameter with sensible default
- Error handling: Comprehensive error catching with structured responses
- Logging: Appropriate info and error logging
- Type safety: Explicit return types and proper error message handling
The implementation reuses existing
list_simsLogicfor consistency while providing the structured response format required by MCP resources.
55-57: LGTM: Handler simplified as thin wrapperThe handler correctly follows the new pattern as a thin wrapper that ignores the URI parameter (appropriate for this resource) and delegates to the logic function without parameters. This maintains the separation of concerns established by the architectural pattern.
docs/TESTING.md (2)
92-115: Excellent dependency injection pattern!The separation of handler logic into a dedicated
tool_nameLogicfunction with injected executors is a clean design that promotes testability. This pattern effectively decouples the business logic from the MCP handler interface.
510-520: Clear and actionable fix instructions.The handler signature fix example correctly demonstrates the required pattern where handlers accept only the args parameter and delegate to the logic function with default executors.
docs/PLUGIN_DEVELOPMENT.md (2)
355-372: Good example of reusing tool logic in resources.The implementation correctly demonstrates how to reuse existing tool logic in MCP resources, with proper executor instantiation and error handling.
376-430: Comprehensive and well-structured test pattern.The test structure effectively separates concerns between metadata validation and logic testing. Testing the logic function directly with mock executors provides excellent isolation and follows the established dependency injection pattern.
scripts/check-test-patterns.js (3)
102-114: Comprehensive handler signature violation detection.The regex patterns effectively capture all the common handler signature violations, including multiple parameters, optional parameters, and injected dependencies. The use of multiline flags ensures proper matching across formatted code.
153-176: Well-implemented file discovery logic.The function correctly identifies tool and resource files while excluding test files, index files, and build artifacts. The recursive traversal and file filtering logic is sound.
442-451: Clear and actionable handler fix instructions.The instructions provide exact handler signatures for both tools and resources, making it easy for developers to fix violations. The guidance to inject dependencies inside the handler body is particularly helpful.
|
Claude finished @cameroncooke's task —— View job PR Review: MCP Resources Implementation ✅I've conducted a comprehensive review of this PR that adds 3 new MCP resources. Here's my analysis: Overall AssessmentThis is a high-quality PR that follows established project patterns and guidelines well. The resources correctly reuse existing tool logic for consistency and maintain backward compatibility. ✅ StrengthsArchitecture & Design
Testing Quality
Error Handling
|
Add three new MCP resources to complement existing tools:
Key features:
Closes #78
🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Tests
Chores
Documentation