At Sentry, we recently launched a new command-line interface (CLI) tool, which has been met with some enthusiastic reactions from users who are eager to ditch the Managed Control Protocol (MCP). While it's understandable why folks might prefer a CLI for certain tasks, the debate over whether to use MCP or CLI often misses a crucial point: both tools have their unique strengths and use cases. Let’s dive into how context management works with LLMs and why the MCP vs. CLI discussion is more nuanced than it seems.

The Role of Context in LLMs

Context management is essential when working with Large Language Models (LLMs). It involves providing the model with relevant information to generate accurate and useful responses. Whether you're using a CLI or an MCP server, the goal is to ensure that the context is clear and actionable. However, the way these tools achieve this can differ significantly.

Sentry’s MCP Server: More Than Just a Protocol

Sentry's MCP server is designed to expose tools through standardized authentication mechanisms, such as OAuth. This is where much of its value lies. Here are some key points:

• Exposing Tools: The primary use case for MCP is exposing various tools and services, often behind secure authentication.
• Standardization: By using standardized protocols like OAuth, MCP ensures that access to these tools is consistent and secure.
• Flexibility: MCP can be used to expose a wide range of functionalities, from fetching specific resources to performing complex operations.

Steering the Agent with Sentry’s Tools

One of the most powerful features of Sentry's MCP server is its ability to steer the agent. This means guiding the LLM to perform specific tasks based on user input. Let’s look at an example using one of the tools exposed by Sentry:

# Unified entry point for fetching Sentry resources
def get_sentry_resource(url=None, resourceType=None, organizationSlug=None, issueId=None):
    """
    Auto-detects resource type from URL or accepts explicit type and identifiers.

    USE THIS TOOL WHEN:
    - User provides a Sentry URL (any type: issue, event, trace, profile, replay, monitor, release)
    - User wants to fetch a specific resource by type and ID

    FULLY SUPPORTED:
    - **issue**: Fetch issue details by ID
    - **event**: Fetch specific event within an issue
    - **trace**: Fetch trace details (supports span focus from URL)
    - **profile**: Fetch and analyze CPU profiling data

URL RECOGNIZED (returns helpful guidance):
- **replay**: Session replay URLs
- **monitor**: Cron monitor URLs
- **release**: Release URLs
"""

# Example usage: URL mode (auto-detect type)
if url:
    resourceType, *identifiers = parse_url(url)
    return fetch_resource(resourceType, *identifiers)

# Example usage: Explicit mode - Issue
elif resourceType and organizationSlug and issueId:
    return fetch_resource(resourceType, organizationSlug, issueId)

Helper function to parse URL

def parse_url(url): # Simplified parsing logic for demonstration if 'issues' in url: return 'issue', *extract_identifiers(url) elif 'explore/traces' in url: return 'trace', *extract_identifiers(url) elif 'replays' in url: return 'replay', *extract_identifiers(url) # Add more cases as needed

Helper function to extract identifiers from URL

def extract_identifiers(url): # Simplified extraction logic for demonstration parts = url.split('/') return parts[-2], parts[-1]

Example usage

print(get_sentry_resource(url='https://my-org.sentry.io/issues/PROJECT-123')) print(get_sentry_resource(resourceType='issue', organizationSlug='my-org', issueId='PROJECT-123'))

### Why MCP vs. CLI Doesn’t Make Sense

The debate over whether to use MCP or a CLI often overlooks the fact that these tools serve different purposes:

- **MCP**: Best for exposing complex, authenticated services and steering LLMs to perform specific tasks.
- **CLI**: Ideal for quick, command-line interactions and scripting.

### Making an Informed Decision

Understanding the problem space