Add tiger mcp get command

[nathanjcochran]

This PR adds a new tiger mcp get <type> <name> command that allows users to inspect detailed information about specific MCP capabilities (tools, prompts, resources, and resource templates).

New Command

The tiger mcp get command provides detailed, human-readable information about MCP capabilities:

# Get details about a tool
tiger mcp get tool service_create

# Get details about a prompt
tiger mcp get prompt setup-timescaledb-hypertables

# Output as JSON or YAML
tiger mcp get tool service_create -o json
tiger mcp get tool service_create -o yaml

It is also aliased as tiger mcp show and tiger mcp describe (to match the tiger service get aliases).

Note that I first tried outputting the information in a table (when not requesting JSON/YAML formatted output), but I found it too difficult to read due to the amount of text in the tool descriptions and input/output schemas. I therefore decided use a raw text format roughly similar to how Claude Code displays tools when you inspect one via /mcp (though there are some differences, such as the fact that I show the output schema as well as the input schema). I'm open to other thoughts and feedback on this though.

Additional Changes

• Explicit tool annotations: Made annotation hints explicit (ReadOnlyHint, IdempotentHint, OpenWorldHint) instead of relying on default values, improving code clarity and ensuring that they're displayed correctly in the tiger mcp get output.
• Shell completion helper: Added filterCompletionsByPrefix helper function to consolidate completion filtering logic
• Tests: Added tests for the new tiger mcp get command.

Closes AGE-287

[Askir]

Generally looks good :D Just left a few questions/suggestions.

[Askir]

Is it strictly necessary that we include as an argument? Do we have collisions in names otherwise? I think it would be more intuitive otherwise to have tiger mcp describe create_service explain to the user that this mcp primitive is of type tool.

[nathanjcochran]

Do we have collisions in names otherwise?

We don't currently have any collisions in names, but we theoretically could in the future (especially because pg-aiguide is developed separately from the CLI), since there's nothing that prevents a tool from having the same name as a prompt, for instance. I was really just trying to make it safe and future-proof.

If we make it tiger mcp get <name>, we would run into issues if we ever end up with duplicate names. Perhaps that's so unlikely that we just shouldn't worry about it? Idk, open to other thoughts on this. I just tend to err on the side of making things explicit and future-proof when there's potential ambiguity. And users can already figure out which things are tools vs prompts by running tiger mcp list, so it didn't feel like a major issue to me to require tool/prompt in the command. I agree that tiger mcp get <name> would be better in theory, though.

[nathanjcochran]

I decided to go ahead with your suggestion and remove the <type> argument, so now it's just tiger mcp get <name>: 545dd4c

If we run into naming collisions in the future, we can revisit 🤷‍♂️.