Summary

The search_code tool requires project to be an array of strings (["MyProjectName"]), while virtually every other tool in the MCP server accepts project as a plain string ("MyProjectName"). This inconsistency causes validation errors when the model naturally passes a string.

Reproduction

// Fails
{ "searchText": "test", "project": "MyProjectName", "top": 1 }

Error:

{
  "code": "invalid_type",
  "expected": "array",
  "received": "string",
  "path": ["project"],
  "message": "Expected array, received string"
}

// Works
{ "searchText": "test", "project": ["MyProjectName"], "top": 1 }

Why this matters

Every other tool that takes a project parameter accepts it as a string:

• repo_get_pull_request_by_id -- project: string
• wit_get_work_item -- project: string
• pipelines_get_builds -- project: string
• repo_list_repos_by_project -- project: string
• etc.

MCP clients learn the project: string pattern from all the other tools and then apply it to search_code. The same applies to the repository, branch, and path parameters, which are also arrays.

Suggested fix

Accept both a single string and an array for project (and the other filter parameters). When a string is received, wrap it in an array internally before passing it to the Azure DevOps Search API. For example:

// Instead of:
project: z.array(z.string()).optional()

// Use:
project: z.union([z.string().transform(s => [s]), z.array(z.string())]).optional()

This preserves the multi-project search capability while eliminating the most common source of errors.