Pull Request: Add /metrics Endpoint with Request Tracking

[human-77]

Summary

This PR adds a Prometheus-compatible metrics endpoint to monitor server health and track HTTP requests by route and status code.

Changes

1. route.ts

Implements a /metrics endpoint that exposes server metrics in Prometheus format, including:

• Server uptime indicator (up)
• CPU usage (process_cpu_seconds_total)
• Memory metrics (RSS, heap total/used, external memory, array buffers)
• HTTP request counters grouped by route and status code (http_requests_by_status)

This endpoint can be scraped by Prometheus or other monitoring tools to track application performance and health.

2. requestCounter.ts

Provides a lightweight in-memory request counter utility with two main functions:

• incrementCounter(route, statusCode): Records each HTTP request with its route and status code
• getStatusCounters(): Retrieves the accumulated request statistics

Uses globalThis to persist counters across module hot-reloads in development, ensuring metrics aren't lost during the session.

3. metrics.test.ts

Adds a basic test suite for the metrics endpoint to ensure:

• The /metrics endpoint responds successfully
• The response returns valid string content in Prometheus format

Use Case

These changes enable observability for the MCP server, allowing developers and operators to:

• Monitor resource usage (CPU/memory)
• Track request patterns and error rates
• Set up alerts based on status code distributions
• Debug performance issues in production

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[human-77]

If it's not possible do the merge without signing the CLA I won't mind if you guys just clone my repo and add to the project. It's just three files.

Ignore this, the message didn't showed to me until I reload the page

[human-77]

I confirm that I have read and hereby agree to the OpenZeppelin Contributor License Agreement

[wwwmilan]

Any prediction on when will this be merged? My team needs observability.

[ericglau]

@human-77 Thanks for the PR! I have a few questions about the intention behind this change:

1. What's the intended audience for this endpoint? Is this meant for internal monitoring/alerting systems (internal to whoever is running this MCP server), or for external users of the hosted version?

2. Security: Any endpoint exposing process-level metrics (memory, CPU, request counts) will likely need to be internal-facing only and must not be publicly accessible. If the goal is external observability, that would need to take a different form (e.g. a minimal /health endpoint or a status page).

What's the use case you have in mind?

[ericglau]

@wwwmilan Could you share a bit more about what "observability" means for your team? For example, are you looking for uptime/health checks, usage metrics for your own calls, a status page, or something else?

Also, are you self-hosting or consuming the hosted version? This will help us figure out the right approach. Thanks!

[human-77]

Hello @ericglau !

1 - What's the intended audience for this endpoint? Is this meant for internal monitoring/alerting systems (internal to whoever is running this MCP server), or for external users of the hosted version?

This is intended for internal use. We're running a self-hosted deployment and added this for observability purposes.

2 - Security: Any endpoint exposing process-level metrics (memory, CPU, request counts) will likely need to be internal-facing only and must not be publicly accessible.

Agreed. It might make sense to gate this behind an environment variable so it can be enabled or disabled as needed.

What's the use case you have in mind?

The goal was to add observability to a self-hosted setup. We thought this could be useful for others running their own deployments as well.