Skip to main content
Glama

secure-flows

by io.github.michal-lefler

Session login callback (redirect)

auth_session_callback

Browser redirect endpoint used after hosted /app/sessions/login. No Authorization header.

  1. Verifies firebaseToken (Firebase ID token).

  2. Ensures client_redirect_uri is allowlisted for app_id (same rules as validate-redirect).

  3. Create vs renew: If session_token is absent, reuses the newest active session for (workspace_name, Firebase UID, app_id) or creates one (get-or-create). Optional payload (URL-encoded JSON object, default {}) is stored only on create — ignored when reusing an existing session. If session_token is present (previous session JWT, may be expired), renews that session; payload must not be sent on the same request. Optional ttl_seconds applies to both paths (default 0 = unlimited; otherwise 60–604800). When the Firebase token includes email, the server best-effort persists or backfills it on the workspace end-user row (audit display only).

  4. Responds with 302 Found to client_redirect_uri with query params sessionToken and, if provided, state.

If client_redirect_uri is not allowed for app_id, responds 400 and does not redirect (open-redirect mitigation). Other failures return an HTTP error status with a JSON {"status", "error"} body and do not redirect.

Source: GET /api/v1/auth/callback No Authorization header is required. Prefer connection.workspaceName and connection.appId as stable config instead of generating identity fields dynamically.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
authNo
bodyNo
queryYes
paramsNo
connectionYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations present, the description fully carries the burden of behavioral disclosure. It explains session creation vs renewal, payload persistence rules, TTL behavior, email backfill, redirect responses, 400 on disallowed redirect URIs, and error responses that do not redirect. This is exceptionally transparent.

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?

The description is long but well-structured with numbered steps and clear conditional paths. It front-loads the endpoint's role and auth requirement, then details behaviors. Minor redundancy exists around 'No Authorization header is required,' repeated at the end, but overall every major sentence adds necessary information.

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?

The description is complete for a complex redirect callback with no output schema and no annotations. It covers auth, redirect validation, create/renew semantics, parameter constraints, error behavior, and configuration guidance. An agent has enough information to call this tool correctly and predict its outcomes.

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

Parameters5/5

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

The description adds substantial meaning beyond the schema: firebaseToken is a Firebase ID token, client_redirect_uri must be allowlisted, session_token triggers renewal, payload is stored only on create, and ttl_seconds applies to both paths. Even with sparse schema coverage, the description compensates fully for every parameter's role.

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?

The description explicitly identifies the tool as a browser redirect endpoint used after hosted /app/sessions/login, names the source route GET /api/v1/auth/callback, and explains the create-vs-renew behavior. This clearly distinguishes it from sibling session management tools like post_sessions_get_or_create and post_sessions_renew_session_token.

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?

The description gives clear context for when the tool is used: after hosted login, with no Authorization header, and with an allowlisted redirect URI. It does not explicitly list sibling tools to exclude, but the callbacks and error behavior make the usage context unambiguous.

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

All secure-flows toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

Most tools target distinct session/auth operations, and the descriptions clearly separate browser redirects from API endpoints. The main ambiguity is between get_sessions and get_sessions_my (payload vs. list) and the two logout variants, though the docs disambiguate them.

Naming Consistency4/5

API tools consistently use snake_case `{method}_{resource}_{action}` names, but a few deviate: `auth_session_callback` lacks the method prefix, `get_sessions_get_key`/`delete_sessions_delete_key` are redundant, and the `secureflows_*` helpers use a different prefix. Still readable and predictable.

Tool Count4/5

18 tools is slightly above the sweet spot, but the count is justified by distinct session lifecycle operations, auth redirects, and integration helpers. Only `get_docs_search` feels peripheral to the core session domain.

Completeness5/5

The surface covers session create, get-or-create, read, key-level update/delete, renew, revoke, logout, identity, and self-service listing/revocation, plus login/logout URL builders and linting. No important dead ends for the stated auth/session purpose.

Resources