Summary
The codeql_bqrs_decode MCP tool rejects a singular file argument with a validation error and instead requires files (an array). This is confusing and inconsistent: the server's internal tool registry / parameter handling references a singular file parameter for the BQRS tools, but the exposed MCP input schema requires the plural files. Callers (including LLM clients) naturally try file first and hit a hard error.
Steps to reproduce
-
Invoke codeql_bqrs_decode with a singular file argument, e.g.:
{ "file": "/path/to/results.bqrs", "format": "csv" }
-
Observe the validation error:
Input validation error: Invalid arguments for tool codeql_bqrs_decode: must have required property 'files'
-
Re-invoke with the plural array form, which succeeds:
{ "files": ["/path/to/results.bqrs"], "format": "csv" }
Expected
A consistent, discoverable input contract. Either:
- accept a singular
file (a single BQRS path is the common case), or
- treat
files as canonical but accept file as an alias / normalize file → files, or
- at minimum, produce an error that names the correct parameter and shows the expected shape.
Likely area
There is a mismatch between the internal handling of BQRS tools (which references a singular file) and the input schema actually advertised over MCP (which requires files). The parameter-name normalization that already maps camelCase/snake_case variants for other tools does not bridge file ↔ files here.
Suggested direction
- Align the advertised input schema with the registry's handling, and/or add
file ↔ files normalization so both forms work for the codeql_bqrs_* tools.
- Add a unit test asserting that both a singular
file and a files array are accepted (or that the rejection message clearly points at the correct parameter).
Impact
Low functional impact (a workaround exists), but it is a recurring usability papercut and a likely source of failed first attempts by automated/LLM clients.
Summary
The
codeql_bqrs_decodeMCP tool rejects a singularfileargument with a validation error and instead requiresfiles(an array). This is confusing and inconsistent: the server's internal tool registry / parameter handling references a singularfileparameter for the BQRS tools, but the exposed MCP input schema requires the pluralfiles. Callers (including LLM clients) naturally tryfilefirst and hit a hard error.Steps to reproduce
Invoke
codeql_bqrs_decodewith a singular file argument, e.g.:{ "file": "/path/to/results.bqrs", "format": "csv" }Observe the validation error:
Re-invoke with the plural array form, which succeeds:
{ "files": ["/path/to/results.bqrs"], "format": "csv" }Expected
A consistent, discoverable input contract. Either:
file(a single BQRS path is the common case), orfilesas canonical but acceptfileas an alias / normalizefile→files, orLikely area
There is a mismatch between the internal handling of BQRS tools (which references a singular
file) and the input schema actually advertised over MCP (which requiresfiles). The parameter-name normalization that already maps camelCase/snake_case variants for other tools does not bridgefile↔fileshere.Suggested direction
file↔filesnormalization so both forms work for thecodeql_bqrs_*tools.fileand afilesarray are accepted (or that the rejection message clearly points at the correct parameter).Impact
Low functional impact (a workaround exists), but it is a recurring usability papercut and a likely source of failed first attempts by automated/LLM clients.