[EPIC] Performance

## Problem statement

Azure MCP Server performance is not measured consistently across startup, tool discovery, command execution, concurrency, and resource consumption. Without representative baselines and explicit performance budgets, regressions can reach users unnoticed, downstream Azure latency can be mistaken for server overhead, and architectural decisions cannot be evaluated against repeatable evidence.

## Vision

Azure MCP Server remains responsive and resource-efficient as its tool surface and usage grow. Performance is measured through representative workloads in supported server modes, regressions are detected before release, and diagnostics identify whether latency originates in the server, transport, authentication, or downstream Azure services.

## Who this helps

- **Users** get responsive tool discovery and execution with predictable behavior under normal and concurrent workloads.
- **Agent and client developers** can integrate against stable latency and throughput characteristics.
- **Toolset owners** can distinguish service-specific latency from shared server overhead.
- **Maintainers** can make architecture and release decisions using reproducible performance data.
- **Operators** can size and monitor remote deployments using documented resource and scalability characteristics.

## Current work

- [ ] #3120, define representative workloads and controlled benchmark environments
- [ ] #3118, measure startup and tool discovery performance
- [ ] #3119, measure command dispatch and transport overhead
- [ ] #3122, validate concurrency, throughput, and scalability
- [ ] #3121, establish CPU, memory, and capacity baselines
- [ ] #3117, attribute latency across server, authentication, network, and Azure dependencies
- [ ] #3123, enforce performance regression budgets in CI

## Initial performance budget policy

Budgets begin relative to qualified controlled-run baselines. Absolute targets are ratcheted after at least 10 successful scheduled runs across 14 days.

- Changes above 5% produce a warning with comparison evidence.
- p50 or p95 latency regression above 10% blocks after qualification.
- p99 latency regression above 20% blocks after qualification.
- Throughput reduction above 10% blocks after qualification.
- Steady-state CPU or memory increase above 10% blocks after qualification.
- Peak memory or concurrency-scaling degradation above 15% blocks after qualification.
- Timeout or server-error increase above 0.5 percentage points blocks after qualification.
- Baselines do not update automatically after regressions.
- Replacing a baseline requires a linked issue, measured impact, and owner approval.

## Goals (in scope)

- Define representative performance workloads for startup, tool discovery, command dispatch, response handling, and sustained execution
- Establish baselines and explicit performance budgets for supported stdio and remote HTTP modes
- Measure latency distributions, throughput, concurrency, memory, and CPU rather than relying only on single-run averages
- Isolate shared server and transport overhead from authentication and downstream Azure service latency
- Detect material regressions in continuous integration or scheduled performance runs with actionable diagnostics
- Validate that growth in tools, namespaces, and concurrent users does not cause unbounded degradation
- Document expected performance characteristics and the process for investigating and accepting regressions

## Non-goals (out of scope)

- Optimizing Azure service response times or network conditions outside Azure MCP Server control
- Owning tool-selection quality or semantic evaluation, which is tracked by the experiment-driven evaluation epic
- Replacing correctness, reliability, recorded-test, or live-test validation with performance testing
- Prescribing low-level implementation changes before measurements identify a bottleneck
- Requiring identical performance characteristics across transports or deployment environments

## Success criteria

- [ ] Representative workload profiles and test environments are documented and reproducible
- [ ] Startup, discovery, execution overhead, throughput, concurrency, memory, and CPU have maintained baselines and explicit budgets
- [ ] Supported server modes meet their approved budgets at defined tool counts and concurrency levels
- [ ] Automated performance runs detect material regressions and identify the affected layer
- [ ] Server overhead can be separated from authentication, network, and downstream Azure service latency
- [ ] Absolute latency, throughput, and resource targets are ratcheted after baseline qualification
- [ ] Performance regressions are fixed or explicitly dispositioned with measured impact before release
- [ ] Operators have documented capacity and telemetry guidance for supported remote deployment scenarios

## Dependencies

- Stable benchmark and load-test infrastructure with representative datasets and workloads
- CI or scheduled-run capacity with retained results for trend analysis
- Server, transport, authentication, and downstream-call telemetry with consistent correlation
- Stable definitions of supported stdio and remote HTTP deployment modes
- Experiment-driven tool evaluation (#3035) for quality measurements considered alongside performance
- PR and release quality guardrails (#2494) for enforcing established performance budgets
- Remote load-testing work (#1570) for shared production-host scenarios