fix(mcp): convert custom tool parameters to Zod schemas for MCP SDK c…

[scaminom]

Fixes primefaces/primeng#19504

Problem

The @modelcontextprotocol/sdk v1.29.0 updated its McpServer.tool() API to require
Zod schemas instead of plain objects for tool parameters. This caused the MCP
server to fail on startup with:

Tool get_migration_guide expected a Zod schema or ToolAnnotations,
but received an unrecognized object

Solution

• Updated registerCustomTools to build Zod schemas from the parameters
  definition before registering each tool
• Restricted CustomToolDefinition.parameters.type to 'string' (the only
  type currently used across PrimeNG and PrimeVue). To add support for other
  types, extend the union in types.ts accordingly

Breaking change

None — consumers of runPrimeMcpServer do not need to change their custom tool definitions.

[Copilot]

Pull request overview

Updates the MCP core package to accommodate @modelcontextprotocol/sdk’s newer requirement for Zod-based tool parameter schemas so custom tools can be registered without startup failures.

Changes:

• Restricts CustomToolDefinition.parameters.type to 'string' (current usage scope).
• Updates registerCustomTools to convert custom tool parameter definitions into Zod-based parameter definitions before calling server.tool().

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
packages/mcp/src/types.ts	Narrows custom tool parameter type to 'string' and documents how to extend it.
packages/mcp/src/index.ts	Adds Zod and builds Zod parameter definitions for custom tool registration.

Comments suppressed due to low confidence (1)

packages/mcp/src/types.ts:125

• Now that parameters.type is restricted to 'string', keeping default?: unknown weakens type-safety for custom tool definitions (callers can provide non-string defaults). Consider narrowing default to string (or string | undefined) to align with the supported type, or expand type/default together when adding more parameter types.

            type: 'string';
            description: string;
            required?: boolean;
            default?: unknown;
        }

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

server.tool() expects a Zod schema (e.g. z.object(...)) in recent MCP SDK versions; passing the raw fields shape object may still be treated as an “unrecognized object” and fail registration. Wrap fields with z.object(fields) (and pass that schema as the third argument) to guarantee a real Zod schema is provided.

Suggested change

	server.tool(tool.name, tool.description, fields, async (args) => {
	const schema = z.object(fields);
	server.tool(tool.name, tool.description, schema, async (args) => {

[scaminom]

I actually tried this approach first, but server.tool() expects a ZodRawShapeCompat (i.e. Record<string, ZodTypeAny>) as
the third argument — not a ZodObject. Passing z.object(fields) causes a TypeScript error:

Type 'ZodObject<Record<string, ZodTypeAny>, "strip", ...>' is not assignable to type 'ZodRawShapeCompat'.
Index signature for type 'string' is missing in type 'ZodObject<...>'

The SDK wraps the raw shape into a ZodObject internally, so passing the shape directly is both correct and type-safe.

[Copilot]

The codebase consistently applies .describe(...) after .optional() (e.g., z.string().optional().describe(...)). Here, describe() is called before optional(), which can drop the description metadata for optional parameters. Consider building the optional/required schema first and then calling .describe(value.description) so optional parameters retain their descriptions.

Suggested change

	const baseType = z.string().describe(value.description);
	fields[key] = value.required ? baseType : baseType.optional();
	const baseType = z.string();
	fields[key] = (value.required ? baseType : baseType.optional()).describe(value.description);

[scaminom]

Any updates on this pr? I really want to use the mcp server on claude code!!

[almapab]

+1

[MatiasGrimm]

Any updates?

[Aston13]

LGTM, please merge — blocks all prime*/mcp packages

[hlopez94]

Will this be ever merged?

[Kermit]

@cagataycivici can you do something with it?

[masum-mollik-rocketml]

Why can't be a high priority and go for an urgent deployment?

[imaksp]

Hi @cagataycivici , sorry for tag, but with AI becoming common this should have higher priority.

[josem32]

please merge this

[Git-DN]

Would be great to have this merged.