Skip to main content
Glama

CorroborateMe

This connector has been deprecated

Replaced by CorroborateMe.

Change of Domain

create_login_link

Mint a one-time human login URL and session id so you can prove an end user. Call webhook_allowlist_add first when using webhook, redirect, form_post or post_message. Requires a company API key (aa_...) or an MCP OAuth access token and an active plan. A missing subscription returns an error result with code subscription_required (meter status 402). Exhausted quota returns code quota_exceeded (meter status 429). Too many creates can return code rate_limited. Returns ok, sessionId, loginUrl, expiresAt, methods, alwaysOn, and forceReauth. poll and sse are always included. Optional methods are webhook, redirect, post_message, and form_post. SMS is not offered. The default reuses the company cookie (Continue-as). Set force_reauth true, or reuse_session false, for a fresh login. When ttl_seconds is omitted, the link lasts 900 seconds. Poll with get_login_status using sessionId. If a webhook notify fails, use retry_login_webhook.

Input Schema

NameRequiredDescriptionDefault
stateNoOptional opaque string echoed back on status and notify payloads so you can correlate the session.
methodsNoOptional notify channels to add. poll and sse stay available even when this is omitted. If this is omitted, a provided webhook_url, redirect_uri, post_message_origin, or form_post_uri turns that channel on. There is no SMS method.
ttl_secondsNoOptional lifetime of the login link, in seconds. When omitted, the server uses 900 seconds. There is no maximum clamp.
webhook_urlNoURL that receives the signed webhook after login. It must match a prefix from webhook_allowlist_add. Use https (http only for localhost when the environment is local). Required when webhook is enabled.
force_reauthNoWhen true, require a fresh login. When false or omitted, the company cookie can be reused (Continue-as), unless reuse_session is false.
redirect_uriNoBrowser redirect after login, such as an https URL or a cursor:// deep link. It must match an allowlisted prefix. Required when redirect is enabled.
form_post_uriNohttp(s) URL that receives an unsigned browser form POST with session_id, status, user_id, email, and state. It must match an allowlisted prefix. Required when form_post is enabled. Production requires https except localhost. Custom schemes are rejected.
reuse_sessionNoWhen false, require a fresh login (same effect as force_reauth true). When true or omitted, it does not override force_reauth true. The tool result reports forceReauth, not this field.
post_message_originNohttp(s) origin (scheme://host[:port]) that should receive the agent_auth.login_completed postMessage. Required when post_message is enabled. Its origin must match an allowlisted prefix (the path is ignored). Production requires https except localhost.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / post_message_origin / description
      Previous value: -"http(s) origin that should receive the agent_auth.login_completed postMessage. Required when post_message is enabled. It is not allowlisted. Production requires https except localhost."New value: +"http(s) origin (scheme://host[:port]) that should receive the agent_auth.login_completed postMessage. Required when post_message is enabled. Its origin must match an allowlisted prefix (the path is ignored). Production requires https except localhost."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare it is a non-idempotent write with no destructive/open-world behavior; the description goes far beyond by disclosing auth requirements (aa_ key or MCP OAuth token, active plan), specific failure codes with HTTP statuses (subscription_required 402, quota_exceeded 429, rate_limited), default cookie reuse semantics, the 900s default lifetime, and the returned fields.

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-loads the core action and keeps each sentence load-bearing (auth, error codes, defaults, routing), but it is dense and repeats a few schema facts ('poll and sse are always included', the 900s default) that are already documented in the parameter descriptions.

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?

For a 9-parameter, zero-required, mutation-style tool with no output schema, the description enumerates every return field (ok, sessionId, loginUrl, expiresAt, methods, alwaysOn, forceReauth) and covers auth, quota, and default behaviors, leaving nothing an agent needs to call it 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?

Schema coverage is 100%, so the baseline is 3, but the description adds synthesis the schema does not: the force_reauth/reuse_session interaction ('Set force_reauth true, or reuse_session false, for a fresh login') and the fact that forceReauth is what the result reports. It also confirms poll and sse are always present and SMS is unavailable.

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 concrete verb+resource ('Mint a one-time human login URL and session id') plus the intent ('so you can prove an end user'), which cleanly separates it from get_login_status and retry_login_webhook. An agent knows exactly what this tool produces 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 Guidelines5/5

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

Gives explicit prerequisites and routing: call webhook_allowlist_add first for the four channel types, poll with get_login_status using sessionId, and use retry_login_webhook if a notify fails. It also names the alternative paths for a fresh login (force_reauth vs reuse_session false).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.