Verbose Logging in MCP Tool Responses Causes Excessive Token Usage

[mgoldsborough]

MCP tool execution responses include verbose debug/info logs that significantly increase token consumption when using LLM-based orchestration. We're seeing 3-5x token bloat per tool call due to internal logging being included in responses.

Environment

• Composio MCP Server (via backend.composio.dev/api/v3/mcp/servers)
• Google Calendar toolkit
• Tools: GOOGLECALENDAR_UPDATE_EVENT, GOOGLECALENDAR_PATCH_EVENT, GOOGLECALENDAR_FIND_EVENT

Problem

Tool execution responses include a logs array with internal debug information that provides no value to the caller but significantly increases response size:

Example response (truncated):

{
  "successfull": true,
  "error": null,
  "data": {
    "response_data": {
      "id": "event-123",
      "summary": "Meeting",
      "start": {"dateTime": "2026-01-27T12:00:00-10:00"}
    }
  },
  "logs": [
    {
      "level": "INFO",
      "message": "Key normalization flag check: enabled=True, model=UpdateEventRequest",
      "requestId": "00000000-0000-0000-0000-000000000000",
      "time": "2026-01-23T21:52:52.204406+00:00",
      "type": "system"
    },
    {
      "level": "DEBUG",
      "message": "Key normalization enabled for model: UpdateEventRequest",
      "requestId": "00000000-0000-0000-0000-000000000000",
      "time": "2026-01-23T21:52:52.204845+00:00",
      "type": "system"
    },
    {
      "level": "INFO",
      "message": "HTTP get https://www.googleapis.com/calendar/v3/calendars/primary/events/... (attempt 1/3)",
      "requestId": "...",
      "time": "...",
      "type": "network",
      "extras": {
        "attempt": 1,
        "json": null,
        "method": "get",
        "params": null,
        "timeout": null,
        "url": "https://www.googleapis.com/calendar/v3/calendars/primary/events/..."
      }
    },
    {
      "level": "DEBUG",
      "message": "GOT 200",
      "extras": {"attempt": 1, "duration": 151, "statusCode": 200}
    },
    {
      "level": "INFO",
      "message": "HTTP put https://www.googleapis.com/calendar/v3/... (attempt 1/3)",
      "extras": {
        "json": {"attendees": [], "conferenceData": {...}, "end": {...}, "start": {...}},
        "method": "put",
        "params": {"conferenceDataVersion": 1, "sendUpdates": "all"}
      }
    },
    {
      "level": "ERROR",
      "message": "Validation error (is_latest_version=True): Traceback (most recent call last):\n  File \"/var/task/mercury/tools/api/action.py\", line 101, in _validate_response\n    response_model.model_validate(response)\n  ... (full Python traceback)"
    }
  ],
  "version": "20260122_00",
  "auth_refresh_required": false,
  "mercury_last_http_status_code": 200,
  "is_latest_version": true,
  "log_id": "log_SLgFV67n0Seo"
}

Impact

Metric	Without Logs	With Logs	Bloat
Response size	~1,500 chars	~5,500 chars	3.7x

For an LLM orchestration flow with 3 tool calls, this adds ~3,000 extra tokens per conversation, directly impacting:

• API costs (we pay per token)
• Context window consumption
• Response latency

Additional Issues

1. Validation errors logged but operation succeeds: The ERROR level log shows a Pydantic validation error (response_data.summary Field required) even though the operation completed successfully. This is confusing and suggests the response schema is stricter than the actual Google Calendar API contract.
2. Internal metadata fields: Fields like version, log_id, mercury_last_http_status_code, is_latest_version are internal Composio metadata that callers don't need.

Request

Please provide a way to disable verbose logging in MCP responses. Suggested options:

1. Query parameter: ?verbose=false or ?include_logs=false on the MCP server URL
2. Request header: X-Composio-Verbose: false
3. MCP server config option: When creating the server via /v3/mcp/servers, allow { "verbose_logs": false }
4. Default to off: Make verbose logging opt-in rather than opt-out

Current Workaround

We're currently stripping the logs array and metadata fields client-side before passing responses to our LLM, but this is inefficient and error-prone.

Related

The Pydantic validation error for missing summary field should also be investigated - Google Calendar allows events without titles, so the UpdateEventResponse schema appears to be overly strict.

[Uday-sidagana]

Hey @mgoldsborough, Thanks for debugging the issue on your end. I’ve escalated it internally and the team will be working on finding the best possible resolution.

[Uday-sidagana]

Hey @mgoldsborough, we've updated the MCP tool response. Could you try and lmk if you are still getting logs in the response?

[mgoldsborough]

sure thing, i can run some tests. I'll follow up.