Add an input URL query parameter to the basic-host harness so developers can pre-fill tool arguments and bookmark specific tool calls that auto-fire on page load.

Motivation and Context

The basic-host harness already supports ?server=name&tool=name&call=true to auto-select a server/tool and call it on load. However, the tool input always resets to the schema's default values, so developers have to manually paste arguments into the textarea every time they reload. This is especially tedious when iterating on MCP App cards that need specific arguments (e.g. start_analysis with a particular question). Adding ?input={"question":"..."} lets developers bookmark a fully configured tool call URL that fires on load with the exact arguments they want with no manual steps needed and minimal maintenance burden for the very kind developers that are maintaining this.

I know you don't appreciate new examples being added for the maintenance costs. Hopefully this one is a small enough change to an existing example that it can pass the sniff test that this is just making life a little easier.

How Has This Been Tested?

Tested locally against an MCP server running at localhost:3001. Verified:

• ?input={"question":"test"} pre-fills the textarea with the provided JSON on load
• Combined with &call=true, the tool fires immediately with the provided input
• Without &input, behavior is unchanged (textarea initializes from schema defaults)
• Manually switching tools via the dropdown still resets input to that tool's defaults
• After calling a tool, the URL is updated via history.replaceState to include the current input, so refreshing replays the same call
• TypeScript compiles cleanly (tsc --noEmit)
• Prettier passes
• No tests for this area

Breaking Changes

None. The input parameter is optional and defaults to null. When absent, all behavior is identical to before. The initialInput prop on CallToolPanel is optional with a null default.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context