Reported via beta feedback (v0.5.1, macOS/arm64, deepseek). Tester hit this running RepeatMasker, then reproduced it on cat1 -- so it's not tool-specific.
The ambiguity
galaxy_run_tool's docs say to pass inputs as:
{"input_name": {"src": "hda", "id": "dataset_id"}}The literal word dataset_id is the problem. galaxy_get_history_contents returns two distinct id fields per item:
| field |
role |
id |
the HDA id -- the history/content association |
dataset_id |
the underlying dataset id |
Only the HDA id works in run_tool. A user reading the docs literally reaches for the field actually named dataset_id and it fails. The MCP gotchas file already says the right thing ("id = hex hash used in API calls"), so the run_tool docs contradict it.
Fix: say "the id field from galaxy_get_history_contents (the HDA id) -- not the dataset_id field" and use a placeholder like <hda_id> in the example instead of the word dataset_id.
The misleading error (the expensive half)
Passing the wrong id in {"src":"hda","id":"..."} form makes Galaxy return:
Required parameter(s) kwd not provided in request
That's simply wrong -- every parameter was provided; the id just didn't resolve. It sent the tester through six different input shapes (arrays, unflattened nested objects, boolean-as-string, array-wrapped booleans) before they realized the id was at fault. The structural examples in the error output show test-format arrays like "input1": ["1.bed"], which muddied it further.
Notably, passing a bad id in array form (["wrong_id"]) produces a much better error: invalid dataset id. The {"src":"hda","id":...} path should produce that same clear error.
Fix direction: validate/resolve the id in galaxy_run_tool before dispatch and surface "invalid dataset id" (ideally naming which input), rather than letting it surface as "kwd not provided."
Notes
(Beta tester feedback; ids/paths anonymized.)
Reported via beta feedback (v0.5.1, macOS/arm64, deepseek). Tester hit this running RepeatMasker, then reproduced it on
cat1-- so it's not tool-specific.The ambiguity
galaxy_run_tool's docs say to pass inputs as:{"input_name": {"src": "hda", "id": "dataset_id"}}The literal word
dataset_idis the problem.galaxy_get_history_contentsreturns two distinct id fields per item:iddataset_idOnly the HDA
idworks inrun_tool. A user reading the docs literally reaches for the field actually nameddataset_idand it fails. The MCP gotchas file already says the right thing ("id= hex hash used in API calls"), so therun_tooldocs contradict it.Fix: say "the
idfield fromgalaxy_get_history_contents(the HDA id) -- not thedataset_idfield" and use a placeholder like<hda_id>in the example instead of the worddataset_id.The misleading error (the expensive half)
Passing the wrong id in
{"src":"hda","id":"..."}form makes Galaxy return:That's simply wrong -- every parameter was provided; the id just didn't resolve. It sent the tester through six different input shapes (arrays, unflattened nested objects, boolean-as-string, array-wrapped booleans) before they realized the id was at fault. The structural examples in the error output show test-format arrays like
"input1": ["1.bed"], which muddied it further.Notably, passing a bad id in array form (
["wrong_id"]) produces a much better error:invalid dataset id. The{"src":"hda","id":...}path should produce that same clear error.Fix direction: validate/resolve the id in
galaxy_run_toolbefore dispatch and surface "invalid dataset id" (ideally naming which input), rather than letting it surface as "kwd not provided."Notes
galaxy_run_toolcollection-vs-single input).(Beta tester feedback; ids/paths anonymized.)