Add MCP server #569
Add MCP server #569
Conversation
packages/mcp/src/cairo/schemas.ts
Outdated
| name: z.string().describe(commonDescriptions.name), | ||
| pausable: z.boolean().optional().describe(commonDescriptions.pausable), | ||
| ...commonSchema, | ||
| }; |
There was a problem hiding this comment.
Should we use types for these? or maybe some strategy to maintain them as we add new features
There was a problem hiding this comment.
These are schema objects rather than primitive types. Type checking is performed in two different places instead:
- When the schemas are consumed to pass input to the Wizard API (for example here), if any types are mismatched, there will be a compile error.
- The tests have strict type checking (for example here) to ensure that all fields from the Wizard API are also in the schema, otherwise there will be a compile error.
It could be possible to move the type checks into the same file as the schema, but that would result in extra runtime code that is not actually used at runtime.
There was a problem hiding this comment.
Do you think it could be possible (and beneficial) to have a light typescript type check of the schemas to provide early type feedback during development (before running tests) for team members adding new contracts kind/fields?
There was a problem hiding this comment.
Type checks in tests are at compile type so don't need to be run. But agree it's clearer to have types in the schemas for earlier feedback.
Added some light static type assertions for schemas in 8ac24af
MCarlomagno
left a comment
MCarlomagno
left a comment
There was a problem hiding this comment.
LGTM, just a few comments
|
Socket security issues are unrelated, see #540 (comment) |
| feeDenominator: "The denominator used to interpret a token's fee and to calculate the result fee fraction.", | ||
| }; | ||
|
|
||
| export const cairoERC20Descriptions = { |
There was a problem hiding this comment.
I am wondering if it would be a good idea to have those description inside a root object, and then be able to type validate that each Contract kind defined for each languages has it's corresponding definition
There was a problem hiding this comment.
Or probably this is enough https://github.com/OpenZeppelin/contracts-wizard/pull/569/files#r2157215215
There was a problem hiding this comment.
These are just string constants and need to be importable by both Node and Deno, so there isn't much need to add type checks here. Added type checks in the schemas which consume these, in the linked comment above.
packages/mcp/src/cairo/schemas.ts
Outdated
| name: z.string().describe(commonDescriptions.name), | ||
| pausable: z.boolean().optional().describe(commonDescriptions.pausable), | ||
| ...commonSchema, | ||
| }; |
There was a problem hiding this comment.
Do you think it could be possible (and beneficial) to have a light typescript type check of the schemas to provide early type feedback during development (before running tests) for team members adding new contracts kind/fields?
| import { registerCairoMultisig } from './tools/multisig.js'; | ||
| import { registerCairoVesting } from './tools/vesting.js'; | ||
|
|
||
| export function registerCairoTools(server: McpServer) { |
There was a problem hiding this comment.
Maybe this function could be typed to return a register for each contract kind defined in the packages
3 participants
Overview
Adds an MCP server containing tools to generate smart contract source code for for each language, contract, and option supported by Wizard.
Packages
This will be published to NPM as
@openzeppelin/wizard-mcp, with a dependency on a new package@openzeppelin/wizard-commonas described below.Changes
This PR does the following:
packages/commonto be published as@openzeppelin/wizard-common- Contains the prompt strings and options descriptions for each tool, to be used by both the MCP server (in a Node environment) and UI's AI assistant (in a Deno environment).packages/mcpto be published as@openzeppelin/wizard-mcp- Contains the MCP server.packages/ui/api/ai-assistant/function-definitionsto use common description strings frompackages/commonType Safety
Schemas for the MCP tools are intended to be type safe according to the Wizard APIs. Required fields for the Wizard API options (e.g. name and sometimes symbol) are also required in the MCP schemas, while other fields are optional.
Type checks in tests ensure that ALL supported Wizard API options are included in the schemas, except specifically omitted fields (example here where the
accessoption is exposed in the API but not yet supported by the core code generation logic for Stylus).This ensures that whenever new options are added in Wizard, a TypeScript compile error would be given until it is added to the MCP schema or intentionally omitted.
Error Handling
Any errors thrown by the Wizard API (for example, when incompatible options are enabled together) are wrapped as strings before returning the result to the MCP server. This allows AI agents to read the errors and self-correct by retrying with different input options.
Tests
In addition to the type safety tests mentioned above, this also adds unit tests for each MCP tool to verify that they return the exact results as the corresponding Wizard API.
For cases where an error is expected, the error messages are compared with the Wizard API, and snapshots are recorded for viewability.
Previews
PR dependencies