feat(server): add get_console_logs tool to MCP Server Tools #33
Conversation
- Added getConsoleLogsTool.ts to provide console logs access through tools interface - Reused existing Unity-side implementation to minimize code changes - Maintained the same functionality as unity://logs resource
|
Your cubic subscription is currently inactive. Please reactivate your subscription to receive AI reviews and use cubic. |
📝 Walkthrough""" WalkthroughA new tool, Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant MCPServer
participant McpUnity
participant Unity
Client->>MCPServer: Call get_console_logs tool (optional logType)
MCPServer->>McpUnity: Request get_console_logs (logType)
McpUnity->>Unity: Fetch console logs (logType)
Unity-->>McpUnity: Return logs
McpUnity-->>MCPServer: Respond with logs
MCPServer-->>Client: Return logs as JSON text
Poem
Note ⚡️ AI Code Reviews for VS Code, Cursor, WindsurfCodeRabbit now has a plugin for VS Code, Cursor and Windsurf. This brings AI code reviews directly in the code editor. Each commit is reviewed immediately, finding bugs before the PR is raised. Seamless context handoff to your AI code agent ensures that you can easily incorporate review feedback. Note ⚡️ Faster reviews with cachingCodeRabbit now supports caching for code and dependencies, helping speed up reviews. This means quicker feedback, reduced wait times, and a smoother review experience overall. Cached data is encrypted and stored securely. This feature will be automatically enabled for all accounts on May 16th. To opt out, configure 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (3)
✨ 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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (4)
Server~/build/tools/getConsoleLogsTool.js (2)
6-8: Consider constraininglogTypeparameter values.The parameter schema allows any string for
logType, but the description mentions specific values (info, warning, error). Consider using an enum or explicitly validate these values to prevent unexpected inputs.const paramsSchema = z.object({ - logType: z.string().optional().describe('The type of logs to retrieve (info, warning, error) - defaults to all logs if not specified') + logType: z.enum(['info', 'warning', 'error']).optional().describe('The type of logs to retrieve (info, warning, error) - defaults to all logs if not specified') });
54-59: Consider returning structured data instead of stringified JSON.The current implementation returns the entire response as a JSON string. For better usability, consider extracting and returning only the relevant log data in a structured format, making it easier for consumers to process.
return { content: [{ type: 'text', - text: JSON.stringify(response, null, 2) + text: JSON.stringify(response.data, null, 2) }] };Server~/src/tools/getConsoleLogsTool.ts (2)
31-41: Error handling looks good, but consider typed parametersThe error handling is well-implemented with proper logging. However, consider using a typed parameter object instead of
anyfor better type safety.- async (params: any) => { + async (params: z.infer<typeof paramsSchema>) => {
53-54: Add type safety to toolHandler parametersSimilar to the previous comment, use a typed parameter instead of
anyfor better type safety.- async function toolHandler(mcpUnity: McpUnity, params: any): Promise<CallToolResult> { + async function toolHandler(mcpUnity: McpUnity, params: z.infer<typeof paramsSchema>): Promise<CallToolResult> {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
Server~/build/index.js(2 hunks)Server~/build/tools/getConsoleLogsTool.d.ts(1 hunks)Server~/build/tools/getConsoleLogsTool.js(1 hunks)Server~/src/index.ts(2 hunks)Server~/src/tools/getConsoleLogsTool.ts(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (2)
Server~/build/index.js (1)
Server~/build/tools/getConsoleLogsTool.js (1)
registerGetConsoleLogsTool(17-32)
Server~/build/tools/getConsoleLogsTool.d.ts (3)
Server~/build/tools/getConsoleLogsTool.js (1)
registerGetConsoleLogsTool(17-32)Server~/src/tools/getConsoleLogsTool.ts (1)
registerGetConsoleLogsTool(23-43)Server~/build/index.js (2)
server(29-38)mcpUnity(40-40)
🔇 Additional comments (9)
Server~/build/index.js (2)
11-11: Proper module import for the new tool.The import is correctly placed alongside other tool imports, maintaining consistent code organization.
47-47: Tool registration follows existing pattern.The registration of the new console logs tool is properly implemented and placed in the same section as other tool registrations, following the established pattern.
Server~/src/index.ts (2)
11-11: Clean import of the new console logs tool.The import statement is properly positioned among other tool imports, maintaining code organization consistency.
54-54: Appropriate tool registration.The new tool registration follows the same pattern as other tools and is correctly integrated into the server setup.
Server~/build/tools/getConsoleLogsTool.d.ts (1)
1-12: Well-documented TypeScript declaration.The declaration file properly defines the function signature with appropriate JSDoc comments explaining the purpose and parameters. This enhances code maintainability and developer experience.
Server~/build/tools/getConsoleLogsTool.js (2)
17-32: Clean tool registration with proper logging.The registration function follows the established pattern in the codebase with appropriate logging at each step. Error handling is robust, capturing and logging any failures during tool execution.
41-53: Effective implementation of Unity communication.Good reuse of existing Unity-side implementation by using the same method name as the resource. The error handling is also robust, throwing a specific
McpUnityErrorwith a clear error message.Server~/src/tools/getConsoleLogsTool.ts (2)
57-63: Good approach to reuse existing Unity-side implementationThe implementation correctly reuses the existing Unity-side code by using the same method name, which minimizes changes and maintains consistency.
1-7: Import structure looks goodThe imports are well-organized and include all necessary dependencies for the tool implementation.
|
|
Very good PR thank you for your contribution |
Description
This pull request adds a new tool called
get_console_logsto the MCP Server Tools. The main purpose of this tool is to retrieve logs from the Unity console, providing a way to access console logs through the tools interface.Key changes include:
getConsoleLogsTool.tsin theServer~/src/tools/directory.index.tsfile.unity://logsresource.The tool allows for optional filtering of log types (info, warning, error) and uses the McpUnity instance to communicate with Unity. It handles potential errors and returns the logs in a structured JSON format.
Test
N/A
Changes that Break Backward Compatibility
N/A
Documentation
While no explicit documentation changes are mentioned, the new tool's implementation includes inline comments and type definitions that serve as documentation for its usage and functionality.
Created with Palmier
Summary by CodeRabbit