SEAB-7740 Add slimmed TRS MCP tools

[denis-yuen]

Description

Implements TRS tools but removing all the convenience methods that are useful for humans but redundant for AI.
i.e. we had separate methods for getting container files, tests, and descriptors but they were already implemented as simple file retrieval in the web service
The hello method was redundant with TRS server info command (added a mode to just show that the MCP server was up without talking to the webservice) and also merged the process of getting tool versions with getting a tool controlled through arguments. We end up with 5 total implemented tools.

Generated comment follows:
Trims the MCP server from 17 tools to 9 so agents load less and have fewer overlapping choices. The tool definitions the model sees shrink from 18,267 B to 14,451 B (68,673 B → 50,133 B with output schemas, which Claude Code doesn't pass to the model). list_tool_classes and hello fold into get_trs_info, which also reports the Dockstore URL and server version and, with local_only=True, skips Dockstore as a smoke test. get_tool_descriptor, get_tool_tests and get_tool_containerfile fold into get_tool_descriptor_by_path, which fetches the primary descriptor when relative_path is omitted. get_tool_files folds into get_tool_version(files=…), search_tools into list_tools (a proper non-TRS search will come separately), and list_tool_versions into get_tool(summary=…).

Review Instructions
There's a generated comment below with the prompts that I tested the MCP with, try them and see if the MCP as deployed in QA gives useful/realistic results.

Issue

• https://ucsc-cgl.atlassian.net/browse/SEAB-7740 — this PR and SEAB-7740 Shrink TRS version lists #9, which kept monorepo workflows like broadinstitute/warp from overflowing an agent's context: summaries cap version names at 10 and add version_count (a ReblockGVCF search: 57 KB → 5 KB), and version lists gained a three-field summary (793 KB → 151 KB).
• https://ucsc-cgl.atlassian.net/browse/SEAB-7746 — SEAB-7746 Prototype the remaining GA4GH TRS V2 tools #6 prototyped the remaining TRS V2 tools from the ga4gh-mcp tutorials, plus listing totals, a 17× smaller summary, notebooks and services, and a dockstore-mcp/<git ref> User-Agent.
• Follow-ups: https://ucsc-cgl.atlassian.net/browse/SEAB-7733 (performant search; TRS filters are case-sensitive substrings) and https://ucsc-cgl.atlassian.net/browse/SEAB-7771 (paging).

Security and Privacy

None

• Security and Privacy assessed

e.g. Does this change...

• Any user data we collect, or data location?
• Access control, authentication or authorization?
• Encryption features?

Please make sure that you've checked the following before submitting your pull request. Thanks!

• Check that you pass the basic style checks and unit tests by running make check
• Ensure that the PR targets the correct branch. Check the milestone or fix version of the ticket.
• If you are changing dependencies, check the Snyk status check or the dashboard to ensure you are not introducing new high/critical vulnerabilities
• Assume that arguments passed to a tool can be malicious, and sanitize and/or check for Denial of Service type values, e.g., massive sizes
• Do not log or return secrets/credentials in a tool's response, error message, or debug output
• If this PR is for a user-facing feature, create and link a documentation ticket for this feature (usually in the same milestone as the linked issue). Style points if you create a documentation PR directly and link that instead.

🤖 Generated with Claude Code

[denis-yuen]

This comment was generated by Claude (Claude Code).

Prompts used to evaluate these tool changes

These are the prompts from today's sessions that used the Dockstore MCP (local_mcp_2_dockstore_prod), plus G from #6's sample run. RB = #workflow/github.com/broadinstitute/warp/ReblockGVCF.

The table is for the 9-tool head (e6ec87d). Each prompt's recorded calls, mapped to replacements for removed tools, were replayed 3 times against Dockstore production in-process. Times are medians, with calls sent together run in parallel, and include Dockstore but not MCP transport. Sizes are the tool result bytes the agent receives.

Prompt	MCP calls	Response time	Response size
A. "using Local_mcp_2_dockstore_prod can you find the reblockGVCF pipeline from the Broad, I want to work with the develop version of it"	search_entries, list_tools(toolname=ReblockGVCF, summary, limit 50), then get_tool_version(files=WDL) and get_tool_descriptor_by_path sent together (RB, develop, WDL)	2.06 s: list_tools 1.33 s, then the two together 0.72 s. search_entries fails at once as not yet implemented	9.3 KB: list_tools 4.8 KB, descriptor 3.0 KB, version and files 1.4 KB
B. "Can you tell me potential issues with the wdl?"	get_tool_descriptor_by_path × 2 (…/tasks/wdl/GermlineVariantDiscovery.wdl, Qc.wdl)	0.09 s	39.5 KB: 14.8 KB + 24.7 KB
C. "run the lint tools on ReblockGVCF, show me any MCP calls that you make"	get_tool_descriptor_by_path (…/tasks/wdl/Utilities.wdl)	0.05 s	10.0 KB
D. "Ok, let's try something different. Can you list all the versions for ReblockGVCF, sort them all in a couple of interesting ways. Show me the MCP calls that you make along with response sizes and timings"	get_tool(RB)	0.89 s	754.5 KB, all 1,434 versions in full
E. "before that, do you understand TRS ids? Can you use the MCP to find #workflow/github.com/iwc-workflows/sars-cov-2-variation-reporting/COVID-19-VARIATION-REPORTING for example? Show me the MCP calls made and their timings"	get_tool	0.05 s	7.0 KB
F. "Look at Local_mcp_2_dockstore_prod, can you summarize two pages of tools when listing them, display the mcp calls that you make"	list_tools(20, 0, summary), list_tools(20, 1, summary)	0.86 s: 0.42 s + 0.46 s	17.5 KB: 9.1 KB + 8.4 KB
G. "Get me a list of RNAseq workflows from Dockstore and group by language, but also find out how many versions of each workflow there are"	list_tools × 9 sent together (tool_class=Workflow, summary, limit 100), name and toolname each as rnaseq, RNAseq, rna-seq, RNASeq, plus toolname=RNA-seq	2.06 s, set by the slowest call (name=rnaseq); the others took 0.43–1.57 s	30.3 KB across the 9; 57 workflows after deduplicating by TRS id, 804 versions

Compared with the 17-tool version this PR started from (825c0f2, in alternating runs): the tool definitions the model loads each session shrink from 18,267 B to 14,451 B (−21%), or 68,673 B to 50,133 B (−27%) with output schemas, which Claude Code doesn't pass to the model. The prompts get the same answers from one call fewer. Only A and D change: in A, search_tools becomes list_tools and get_tool_version plus get_tool_files become one get_tool_version(files=WDL); in D, list_tool_versions becomes get_tool. Searches and descriptors are byte-identical, get_tool_version(files=WDL) adds only 28 B for its files and files_error keys, and D's get_tool returns the same 1,434 versions plus 2.6 KB of tool metadata. There is no performance loss: summed medians are 6.26 s for 17 tools and 6.06 s for 9, and no prompt differs by more than the spread between runs, since Dockstore's TRS API sets the response times.

[denis-yuen]

This is most useful for a breakdown of what the tools are and what they do

[denis-yuen]

This git ref business is to hook-up the user agent version to the mcp version which we will also expose in Slack deploy messages and the footer

[denis-yuen]

These models are basically just TRS models

[denis-yuen]

This summary business allows the agent to pick to get lists of versions or tools with fewer fields. The content is still transferred from the webservice to the MCP but not over the Internet to the end user

[svonworl]

As we discussed, I'm not convinced that TRS is the ideal AI interface for Dockstore. The TRS "tool" terminology isn't consistent with Dockstore's notion of a tool ("CommandLineTool"), and some important information about Dockstore entries isn't accessible via TRS. That said, this streamlined version is better than a literal conversion of the entire TRS API, and it'll give us a something to benchmark and compare against the other in-process implementation.

[denis-yuen]

The TRS "tool" terminology isn't consistent with Dockstore's notion of a tool ("CommandLineTool"), and some important information about Dockstore entries isn't accessible via TRS.

FWIW, we can/should be making more information accessible via TRS either as official proposals for extension or unofficial extensions.

For terminology, I'm not opposed to renaming/describing entities differently as they flow through MCP interface after being retrieved from the TRS API.