Skip to main content
Glama
Sign In
eventbrite-mcp

eventbrite-mcp

by prmichaelsen
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_current_user

Retrieve the authenticated Eventbrite user's profile to verify token access and get their ID, name, and email for API calls.

Instructions

Get Current User

Endpoint: GET /users/me/

Returns information about the currently authenticated user (the user whose API token is being used).

Authentication: Requires a valid Eventbrite API token.

Use Cases:

  • Verify authentication and token validity

  • Get current user's ID for other API calls

  • Display user information in applications

  • Check user's name and email

  • Verify user permissions and access

Response Fields:

  • id: User ID

  • name: User's full name

  • first_name: User's first name

  • last_name: User's last name

  • email: User's email address

  • emails: Array of email objects with verification status

  • image_id: User's profile image ID

Error Codes:

  • 401: Authentication required or invalid token

  • 403: Token lacks required permissions

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_current_user"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.6

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and mostly succeeds: it discloses the required Eventbrite API token, the REST endpoint, and the 401/403 failure modes. It omits any rate-limit or scoping caveats, but for a read-only identity call the auth and error disclosure is solid.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Content is front-loaded with purpose before endpoint/auth/use-case/response detail, and every block is scannable. The repeated 'Get Current User' heading plus a Use Cases list with some near-duplicate bullets (check email, check permissions) adds mild padding that keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so listing response fields (id, name, email, emails, image_id) in the description is exactly the right compensation, and error codes round it out. An agent has everything needed to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is no parameter semantics to explain; per the rubric this is the baseline 4. The description correctly implies no inputs are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — returns information about the currently authenticated user, explicitly qualified as 'the user whose API token is being used.' This distinguishes it from the sibling get_user, which takes an identifier rather than resolving the caller.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit Use Cases list (verify token validity, fetch own ID for other calls, check permissions), which tells the agent when this tool is appropriate. It does not, however, name the alternative (get_user) or state when NOT to use this tool, so it stops short of the 5 benchmark.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools