Pug

Get profile sessions

get_profile_sessions

Read-only

GetProfileSessions returns a paginated list of one user profile's sessions, newest first unless sort says otherwise. Requires that user's distinct_id (the pug profile id a profile lookup gives you). Sessions are aggregated server-side — one row per session with its start, end, event count and device context — so a profile with more events than any one page can hold still lists every session, with exact durations and counts. Resolves profile aliases so merged anonymous events are included. To page, send the previous response's next_page_token back as page_token; an empty next_page_token means there are no more pages. A token is only valid for the sort it was issued under — to change sort, start again with no page_token. sort defaults to PROFILE_SESSION_SORT_STARTED_AT and every sort is descending, so DURATION lists the longest sessions first and EVENT_COUNT the busiest. Traffic tagged as a bot at ingest is excluded unless include_bots is true, and the judgement is per session: a session with any tagged event is omitted whole rather than returned with only its untagged events.

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_profile_sessions"
  }
}

Input Schema

Name	Required	Description
`sort`	No
`page_size`	No
`page_token`	No
`project_id`	No	The id of the project, from list_projects.
`time_range`	No
`distinct_id`	No
`include_bots`	No

Output Schema

Name	Required	Description	Default
`sessions`	No
`next_page_token`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds real behavioral value beyond that (token invalid across sort changes, per-session whole-row bot omission, alias resolution pulling in merged anonymous events), but it stays silent on the practical implication of idempotentHint=false for retry/backoff behavior on repeated page_token calls. It is solid added context, not exhaustive.

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?

Front-loaded with purpose, then prerequisites, then paging, then sorting, then bot filtering — a logical order with almost no filler. The clause 'with exact durations and counts' partially restates the preceding sentence and could be trimmed.

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

Completeness4/5

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

An output schema exists, so return-shape explanation is unnecessary, and the description covers paging, sorting, alias merging, and the fact that distinct_id is effectively required despite the schema listing no required fields. The unaddressed time_range parameter is the main remaining hole for a tool of this complexity.

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

Parameters3/5

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

With schema coverage at only 14%, the description carries weight and does explain distinct_id's origin, sort's default and descending semantics, and the page_token/sort coupling. However, time_range (a nested object) and project_id receive no explanation at all, and the bot filter's default state is described only indirectly, leaving real gaps against seven parameters.

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?

Opens with a specific verb and resource: returns a paginated list of one user profile's sessions. The scoping detail ('one user profile's', 'aggregated server-side — one row per session') makes it distinguishable from get_profile and get_profile_stats without opening the schema.

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?

Gives concrete operating context: distinct_id comes from a profile lookup, and paging is described step by step via next_page_token/page_token. It does not explicitly say when to prefer get_profile_stats or get_activity_feed instead, so there are no stated exclusions — clear context without alternative routing.

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

All Pug tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.