Optimize MCP Tool Metadata

Drive runVariantExperiment from @gleanwork/mcp-server-tester to find tool-metadata changes — tool descriptions, input-schema documentation, parameter descriptions — that measurably improve LLM tool triggering. You (the agent) supply the judgment — which rewrite to try next — and the library supplies the mechanism: baseline runs, variant injection, comparison, ranking, regression guarding, and a structured proposal.

Scope: what variants can and cannot change

Overrides change what the host sees, not what the server accepts. The LLM forms tool calls against the overridden metadata, but those calls execute against the real server. Variants must stay wire-compatible:

• Safe to vary: the tool description; descriptive text inside inputSchema — property descriptions, enum documentation, examples, format hints.
• Never vary: parameter names, types, required arrays, or schema structure. The server still validates real calls — structural changes measure server rejections, not discoverability.
• Out of scope entirely: tool behavior, response shapes, auth, transport, server builds. Those need project-based A/B testing (different server configs via Playwright projects, or runServerComparison), which is a different workflow.

Operating Rules

1. Never mutate the eval dataset. It is the behavioral contract. Variants are runtime data passed via toolOverrides.
2. Never edit the MCP server source unless the user explicitly asks for source remediation. Your deliverable is the experiment result's proposal.
3. Respect the regression guard. A variant that fixes two cases but breaks one is not a win. Leave allowRegressions at its default (false) unless the user accepts trade-offs.
4. Mind cost. Every candidate is a full eval run (cases × iterations × LLM calls). Prefer few, well-reasoned variants per round over shotgun spreads.