[Feature Request] Add MCP Server and Tool Definition Metrics to Statusline JSON

Summary

Request to include MCP server and tool definition token counts in the statusline JSON input to enable accurate context tracking for users with extensive MCP setups.

Problem Statement

Currently, the statusline script receives JSON input with basic session information but no MCP-related data:

{
  "session_id": "...",
  "transcript_path": "...", 
  "cwd": "...",
  "model": {...},
  "workspace": {...},
  "version": "..."
}

This creates a significant blind spot for context tracking. Users with multiple MCP servers (Supabase, Gmail, Google Calendar, Linear, Slack, etc.) can have 10-50k tokens in tool definitions alone, representing 25-30% of total context usage that is completely invisible to statusline scripts.

Current Impact on Context Tracking

Without MCP metrics, users cannot:

• Accurately track context window utilization
• Receive proper warnings when approaching context limits
• Make informed decisions about session management
• Optimize their MCP server configurations

For example, a typical enterprise setup might have:

• 11 MCP servers (Supabase, Playwright, Gmail, Calendar, Docs, Sheets, Linear, Slack, Mem0, Context7, Task Master AI)
• 127 individual tools across these servers
• 47,382 tokens in tool definitions (schemas, descriptions, parameters)

This massive context overhead is currently invisible to all statusline implementations.

Proposed Solution

Add MCP metrics to the statusline JSON input:

{
  // ... existing fields
  "mcp_stats": {
    "server_count": 11,
    "tool_count": 127,
    "tool_definitions_tokens": 47382,
    "connected_servers": [
      {"name": "supabase", "tool_count": 23, "tokens": 8500},
      {"name": "gmail", "tool_count": 15, "tokens": 6200},
      // ... etc
    ]
  }
}

Technical Implementation Details

Token Calculation

The token count should be calculated when MCP servers connect, using the same tokenizer that Claude Code uses for context tracking. This would include:

• Tool names and descriptions
• Parameter schemas (JSON Schema definitions)
• Examples and documentation strings
• Error response schemas

Session Lifecycle

• Calculate on MCP server connection/disconnection
• Cache values per session (tools don't change during session)
• Include in every statusline update

Backward Compatibility

• New mcp_stats field would be optional
• Existing statusline scripts continue to work unchanged
• New scripts can leverage the additional data

Alternative Approaches Considered

1. File-based workaround: Have Claude Code write MCP stats to a file

   • ❌ Timing/sync issues, stale data risks

2. Direct MCP queries from statusline: Connect to MCP servers from script

   • ❌ Complex, requires duplicating auth, configuration

3. Estimation heuristics: Guess tool counts based on config files

   • ❌ Inaccurate, doesn't reflect runtime state

Use Cases

Accurate Context Monitoring

Users can build statuslines showing precise context utilization:

Claude Sonnet-4 in chief-of-staff | 🟡 145k/200k (72%) [Base: 15k, Tools: 47k, Session: 83k]

MCP Configuration Optimization

Users can see which servers contribute most to context overhead:

Top context consumers:
- Supabase: 8.5k tokens (database schemas)
- Gmail: 6.2k tokens (complex parameters)  
- Google Calendar: 4.1k tokens

Session Management

Proactive warnings when tool definitions consume excessive context:

⚠️  MCP tools using 47k tokens (24% of context limit)

Related Issues

This addresses the fundamental limitation described in the documentation where statusline context tracking is noted as "approximate" due to missing tool overhead information.

Implementation Priority

This would significantly improve the user experience for power users with extensive MCP setups, which represents a growing segment as the MCP ecosystem expands.

Additional Notes

• This feature would be particularly valuable for enterprise users running multiple MCP servers
• Could be extended to include resource usage metrics (memory, connection counts) in future iterations
• Aligns with Claude Code's goal of providing transparent, actionable development insights