Number parameters fail validation - need z.coerce.number() instead of z.number()

[EngelenH]

Description

Tools with numeric parameters fail with "Expected number, received string" because Zod schemas use z.number() instead of z.coerce.number(). MCP protocol
serializes all values as strings.

Root Cause

In src/tools/pipelines.ts, numeric parameters use strict validation:
buildId: z.number() // ❌ fails on string input

But date parameters correctly use coercion:
minMetricsTime: z.coerce.date() // ✅ handles string input

Fix

Replace z.number() with z.coerce.number() for all numeric parameters.

Affected Tools

All pipeline tools with buildId, logId, pipelineId, runId, etc.

[EngelenH]

Actually now that I dig deeper it looks like this affects other areas in the code too?

[danhellem]

We can take a look, but we have not had anyone else report an issue. Can you post the toolname and the json of the request that LLM is making so we can try and reproduce?

[EngelenH]

Reproduction - tool name + JSON request:

Tool: pipelines_get_build_log

Request JSON sent by LLM:

{
  "project": "MyProject",
  "buildId": "12345"
}

Error:

Expected number, received string

The issue is that MCP transports frequently serialize parameter values as strings. When the LLM calls a tool with "buildId": "12345", Zod's z.number() rejects it because it receives a string, not a number. The same request works fine if you manually pass "buildId": 12345 (unquoted), but that's not how MCP clients send values.

Comparison - dates already handle this correctly:
In pipelines.ts, date parameters use z.coerce.date() which accepts string input. The fix for numbers is the same pattern: z.coerce.number().

Full list of affected parameters across the codebase:

File	Parameters using z.number()
pipelines.ts	buildId, logId, startLine, endLine, pipelineId, runId, definitionId, pipelineVersion, top, reasonFilter, statusFilter, resultFilter, maxBuildsPerDefinition, deletedFilter, processType
work-items.ts	id, ids[], top, skip, parentId, pullRequestId, workItemId, buildId, linkToId
repositories.ts	pullRequestId, threadId, top, skip, iteration, baseIteration, rightFileStartLine, rightFileStartOffset, rightFileEndLine, rightFileEndOffset
work.ts	depth, capacityPerDay

All of these should be z.coerce.number() to match how MCP transports deliver parameters.

Sources describing this:

• https://mastra.ai/blog/mcp-tool-compatibility-layer — documents that different models serialize parameters differently, causing tool call failures
• https://gofastmcp.com/servers/tools — FastMCP defaults to flexible validation specifically because "LLM clients may send string representations of values (like '10' for an integer parameter)"
• [BUG] Claude Code incorrectly serializes JSON objects as strings when calling MCP tools anthropics/claude-code#5504 — Claude Code serializing JSON objects as strings
• https://forum.cursor.com/t/cursor-auto-selected-model-stringifies-mcp-tool-parameters/145807 — same issue in Cursor
• [MCP stdio] Client serializes complex tool arguments as JSON strings instead of native types QwenLM/qwen-code#379 — same issue in Qwen

[danhellem]

We will keep an eye on this. So far, we have not had anyone else report this as an issue. So, we are hesitant on just making a change. If we get others reporting the same problem, we can take a deeper look. I will keep the Issue open for a while.

[EngelenH]

Understandable, running a local modified version for now anyways. Thanks for your consideration.

[AlexandraDorey]

Bah. Now it's back. I do see this, I somewhat corrected it with these rules I can't figure out why it needs to spell it out 🤷

Azure devops Server MCP (ado)

1. A project name is required in order to reference a Git repository by name.
2. Id fields of all kinds is always is a number do not send as a string ( The MCP server requires proper JSON types.) ie. 1234 NOT "1234"
3. A List of Ids fields is always an array of numbers do not send as a string ( The MCP server requires proper JSON types.) i.e [1234,3245] not ["1234", "3245"] or "1234,3245"

Note despite rule 1, claude still gets confused by the requirement

and I still see stuff like this mixed, I don't know that it's really your problem claude seems to be SUPER dumb in this way, but it'd be nice if it accepted the string version

ado - wit_link_work_item_to_pull_request (MCP)(project: "", workItemId: "1522", pullRequestId: "79898",
repositoryId: "************************") ⎿  Error: MCP error -32602: Input validation error: Invalid arguments for tool wit_link_work_item_to_pull_request: [
{
"code": "invalid_type",
"expected": "string", "received": "undefined",
"path": [
"projectId"
],
"message": "Required"
},

[AlexandraDorey]

Example of claude failing, thinking and then getting it right:

● ado - wit_update_work_item (MCP)(id: "1557", project: "Sandbox", title: "[AI-CO45] - Thing3: [COG-2092-NetworkMap] epic:[COG-2092] - Create Network Map")
⎿  Error: MCP error -32602: Input validation error: Invalid arguments for tool wit_update_work_item: [
{
"code": "invalid_type",
"expected": "number", "received": "string",
"path": [
"id"
],
"message": "Expected number, received string"
},
… +10 lines (ctrl+o to see all)

● ado - wit_update_work_item (MCP)(id: 1557, updates: [{"path":"/fields/System.Title","value":"[AI-CO45] - Thing3:
[COG-2092-NetworkMap] epic:[COG-2092] - Create Network Map"}])

[AlexandraDorey]

4.6 is better at this, but still has the odd issue 🤷

[antonysmith-mandogroup]

I had this issue with Claude Code. All tool invocations failed with the error re: a number being expected but a string being passed. I repeatedly asked Claude to pass the parameter as a number rather than a string but it told me that it was passing a number and there was a problem in the MCP layer converting it to a string.

The above feedback indicates this can't be true if it sometimes works. Regardless, Claude proposed making a fix to the MCP package locally - the one described in the original issue - which it did and I've had no issues since that's been done.

It added this note to my prompt, so the change can be re-applied if a new version of the package is retrieved:

- The Azure DevOps MCP server numeric parameter fix (z.coerce.number) is applied at:
  C:\Users\antony.smith\AppData\Local\npm-cache\_npx\38bc830389a22c8c\
  node_modules\@azure-devops\mcp\dist\tools\
  If npx updates the package, re-run the patch script at 
  C:\Users\antony.smith\AppData\Local\Temp\patch-mcp.ps1