MCP tool responses too verbose - breaks context window for users with many work items

[johnib]

Issue:

Claude users who rely on Jira for daily planning cannot effectively use the MCP connector when they have dozens of assigned work items. Tool responses return excessive metadata that rapidly fills the context window, forcing conversation restarts and breaking workflows.

Impact:

• Users with 20-50+ work items hit context limits after 2-3 queries
• Daily planning workflows become impossible
• Context resets lose accumulated understanding of priorities and blockers

Request:

Implement token-efficient response formatting:

• Return only essential fields by default (ID, key, summary, status, assignee)
• Add optional fields parameter to request additional data when needed
• Compress repeated metadata across multiple issues

Environment:

• Claude.ai web interface
• Atlassian Cloud MCP connector
• Typical query: “Show me my open items” returns 30-50 issues

This affects enterprise users who need AI-assisted planning most - those with complex workloads.

[johnib]

What we still got for each field:

"status": {
  "self": "https://...",  // ❌ Don't need
  "id": "1",              // ❌ Don't need
  "description": "...",   // ❌ Don't need
  "iconUrl": "https://...", // ❌ Don't need
  "name": "Open",         // ✅ This is all we need
  "statusCategory": {     // ❌ Entire nested object we don't need
    "self": "...",
    "id": 2,
    "key": "new",
    "colorName": "blue-gray",
    "name": "To Do"
  }
}

The real problem:

The Jira REST API doesn’t support shallow/flat field projection. Every field comes with its full nested metadata whether you want it or not.

Solution required:

The Atlassian MCP server needs to implement a post-processing step that strips out:

• All self, iconUrl, avatarId, description properties
• All nested statusCategory, hierarchyLevel, subtask objects
• All numeric id fields (keep only name fields)

This would be a ~10 line transform function that could save 75% of tokens on every Jira query.

Bottom line: This is an MCP connector architecture problem, not something we can fix at the query level.​​​​​​​​​​​​​​​​