feat(mcp): add script to dump mcp tool list

[burmudar]

Add a script which curls s2 mcp endpoint and dumps the list-tools json

Test plan

executed script locally and committed the json

[burmudar]

This change is part of the following stack:

• feat(mcp): add script to dump mcp tool list #1211 ◀
  • feat(mcp): parse mcp tool json #1212
    • feat(mcp): add mcp list-tools to list available tool calls #1213
      • refactor(mcp): change name to RawName and have method for Name() that is normalized #1214
        • feat(mcp): build flagset from mcp input schema to parse args #1215
          • feat(mcp): do mcp tool call from cli args #1216

_{Change managed by git-spice.}

[burmudar]

Note that in subsequent PRs this file is moved to internal/mcp

[eseliger]

Just a random question: should the src-cli surface depend on the MCP specification, or should it just have similar tools such as src repo file <path> or so, and leave us the freedom to tailor it more towards the humans and angets use-case, unlike MCP?

(I genuinely don't know, just a conversation starter!)

[burmudar]

Just a random question: should the src-cli surface depend on the MCP specification, or should it just have similar tools such as src repo file <path> or so, and leave us the freedom to tailor it more towards the humans and angets use-case, unlike MCP?

(I genuinely don't know, just a conversation starter!)

The later sounds more sustainable and allows more tools that can just be organically discovered. From the latest release of Claude and it's advanced skills I think it's moving a lot more towards selective disclosure of tools that the agent can see on the fly.

I think MCP spec wise, you're stuck in a place where you either create loads of tools (+descriptions) or create "big" tools that does a lot of heavy lifting.

[eseliger]

yeah and since when you got src access you also got access to -h so I think claude should be able to find it's way without an up-front tool description, plus if necessary some AGENTS.md to say "src" can be used to access all of our codebase" or so.

So wondering if - inspired by what tools we saw useful in MCP - it would be interesting to design a slightly more human-friendly version of that for src-cli independently of MCP tool names/descriptions/params which would change the CLI surface if we decide to change the MCP(?)

[burmudar]

yeah and since when you got src access you also got access to -h so I think claude should be able to find it's way without an up-front tool description, plus if necessary some AGENTS.md to say "src" can be used to access all of our codebase" or so.

So wondering if - inspired by what tools we saw useful in MCP - it would be interesting to design a slightly more human-friendly version of that for src-cli independently of MCP tool names/descriptions/params which would change the CLI surface if we decide to change the MCP(?)

It will definitely be interesting since I wonder once you make the src-cli interface more appealing, surely the LLM would prefer to use it more over the MCP? I haven't used the GitHub MCP much but I wonder how often the LLM picks to use the MCP over gh?

[eseliger]

good question, I think it's also a distribution question. Some people have src already and can save the work to get MCP to work. In other scenarios, MCP might be something devX configures for all of us, and that makes it easier to use because not everyone has to install a cli tool (or 100 if you want to replace a lot of CLIs with MCPs :D)

[burmudar]

good question, I think it's also a distribution question. Some people have src already and can save the work to get MCP to work. In other scenarios, MCP might be something devX configures for all of us, and that makes it easier to use because not everyone has to install a cli tool (or 100 if you want to replace a lot of CLIs with MCPs :D)

Ah yeah that is valid. Even though I just interfaced with the SG MCP that is HTTP based, I seemingly forgot about it in my comment 🤦🏼