-
Notifications
You must be signed in to change notification settings - Fork 28
refactor: modularize tools into individual modules with build-time definitions #356
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
…finitions - Split monolithic tools.ts into 19 individual tool modules - Each tool module uses defineTool helper for consistency - Create build-time generation of toolDefinitions.json - Update mcp-cloudflare to use generated definitions - Remove toolDefinitions.ts in favor of build-time generation - Add comprehensive refactoring documentation This refactoring improves maintainability by: - Limiting tool files to ~200 lines for better AI agent context - Using type-safe defineTool helper pattern - Generating client-safe definitions without server dependencies - Following one-tool-per-file architecture 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
Codecov ReportAttention: Patch coverage is
✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## main #356 +/- ##
==========================================
- Coverage 59.70% 58.79% -0.91%
==========================================
Files 51 77 +26
Lines 6159 6414 +255
Branches 477 481 +4
==========================================
+ Hits 3677 3771 +94
- Misses 2482 2643 +161
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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.
Bug: JSON Schema Conversion Breaks Description Access
The client code attempts to access value.description
for properties within tool.inputSchema
. This inputSchema
is now a JSON Schema generated from a Zod schema using zod-to-json-schema
. The conversion process alters the schema structure such that the description
property is no longer directly accessible via value.description
, leading to runtime errors when rendering tool documentation. An explicit [string, any]
type annotation was added to suppress TypeScript errors, masking this type incompatibility.
packages/mcp-cloudflare/src/client/pages/home.tsx#L166-L175
sentry-mcp/packages/mcp-cloudflare/src/client/pages/home.tsx
Lines 166 to 175 in 8319871
<dl className="space-y-3 mt-6"> | |
{Object.entries(tool.inputSchema).map( | |
([key, value]: [string, any]) => { | |
return ( | |
<div className="p-3 bg-black/30" key={key}> | |
<dt className="text-sm font-medium text-violet-300"> | |
{key} | |
</dt> | |
<dd className="text-sm text-slate-300 mt-1"> | |
{value.description} |
Was this report helpful? Give feedback by reacting with 👍 or 👎
@sentry review |
On it! We are reviewing the PR and will provide feedback shortly. |
PR DescriptionThis pull request refactors the MCP server's tool implementation from a monolithic structure to a modular one, improving code organization, maintainability, and scalability. It also introduces automated tool definition generation for client consumption. Click to see moreKey Technical ChangesThe core changes involve migrating tool definitions and handlers from centralized Architecture DecisionsThe primary architectural decision is to adopt a modular, file-based structure for tools. This promotes separation of concerns, improves code discoverability, and simplifies testing. The introduction of the Dependencies and InteractionsThis change impacts the MCP server's core components, including the server configuration ( Risk ConsiderationsPotential risks include: 1) Errors during tool definition generation due to malformed tool modules. 2) Inconsistencies between the generated tool definitions and the actual tool implementations. 3) Compatibility issues with existing MCP clients that rely on the old tool definition format. 4) Increased complexity in managing and deploying individual tool modules. 5) The type assertions used in Notable Implementation DetailsThe |
// Import tools from the source directory | ||
const tools = await import("../src/tools/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.
The script lacks proper error handling for malformed tool modules. If a tool module exports an invalid structure or throws during import, the entire generation process will fail without clear error messages. Consider adding try-catch blocks around individual tool imports and validation to provide better error reporting.
Did we get this right? 👍 / 👎 to inform future reviews.
function convertInputSchemaToJsonSchema(inputSchema: Record<string, any>) { | ||
if (!inputSchema || Object.keys(inputSchema).length === 0) { | ||
return {}; | ||
} | ||
|
||
const properties: Record<string, any> = {}; | ||
|
||
// Convert each individual Zod schema to JSON Schema | ||
for (const [key, zodSchema] of Object.entries(inputSchema)) { | ||
const jsonSchema = zodToJsonSchema(zodSchema, { | ||
$refStrategy: "none", // Don't use $ref for cleaner output | ||
}); | ||
properties[key] = jsonSchema; | ||
} | ||
|
||
return properties; | ||
} |
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.
The Zod schema conversion could fail silently or produce unexpected results for complex schemas. Consider adding validation to ensure the converted JSON schemas are valid and contain the expected properties before writing to disk.
Did we get this right? 👍 / 👎 to inform future reviews.
This refactoring improves maintainability by:
🤖 Generated with Claude Code