The Bridge

Set Up SSO

setup_sso

Idempotent

Enable a social/enterprise SSO login provider on the Bridge app in one step: saves the provider credentials, turns the provider on, and returns the app's OAuth callback URL. Arguments: provider (google | azure | github | linkedin | facebook), clientId and clientSecret from the provider console, and tenantId (the Entra ID directory id, not a Bridge tenant) — required for azure only. Company SAML or OIDC sign-in and Sign in with Apple are not configured here: asking for them returns NOT_OFFERED_HERE naming where to do it (the Bridge dashboard). THE ACTIONABLE OUTPUT IS THE RETURNED callbackUrl: the user must register it in the provider's console (e.g. Google Cloud OAuth credentials, GitHub OAuth app settings) or logins will fail with a redirect mismatch — always surface the callbackUrl and that instruction to the user. Credentials are never echoed back. This is the ONLY way to CONFIGURE a social provider (credentials + callback URL); update_auth_methods can flip the enable flags but never saves credentials. Before writing app code that consumes this, call get_integration_guide with topic=auth and the framework the app uses.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "provider": "<provider>",
      "clientId": "<clientId>",
      "clientSecret": "<clientSecret>"
    },
    "name": "setup_sso"
  }
}

Input Schema

Name	Required	Description
`app`	No	Id of the Bridge app to act on for this call (see list_apps). Omit to use the current app.
`clientId`	Yes	OAuth client id from the provider's developer console. Ask the developer; never invent one.
`provider`	Yes	google, azure, github, linkedin or facebook. saml, oidc and apple are set up in the Bridge dashboard.
`tenantId`	No	Entra ID (Azure AD) directory id — not a Bridge tenant. Required when provider is azure.
`clientSecret`	Yes	OAuth client secret from the provider's developer console. Stored, never returned.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (idempotent/readOnly/destructive hints), disclosing that credentials are never echoed back, that the function performs three side effects in one call, that the actionable output is the callbackUrl which must be registered or logins fail with a redirect mismatch, and the NOT_OFFERED_HERE error behavior. This is exactly the behavioral context annotations cannot carry.

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 purpose and routes the critical callbackUrl instruction prominently via capitalization. It is dense and relies on caps emphasis, and the parameter recap partly duplicates the schema, but every sentence carries actionable content and there is little true waste.

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?

With no output schema, the description correctly compensates by naming the returned callbackUrl as the actionable output and explaining what the user must do with it. Combined with the enterprise-provider exclusions and the follow-up guide pointer, an agent has everything needed to invoke and act on the result.

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 value: it restates the provider enum, clarifies that tenantId is the Entra ID directory id required only for azure, and warns that clientId/clientSecret come from the provider console and must never be invented. Most of this is duplicated in the schema descriptions, keeping it below a 5.

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+resource+scope: 'Enable a social/enterprise SSO login provider on the Bridge app in one step,' and enumerates the concrete effects (saves credentials, enables provider, returns callback URL). It explicitly distinguishes itself from the closest sibling update_auth_methods ('can flip the enable flags but never saves credentials'). An agent can identify it without opening any 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?

States when to use it, when NOT to (SAML/OIDC/Apple return NOT_OFFERED_HERE pointing to the dashboard), the alternative for flag-flipping (update_auth_methods), and a follow-up routing hint (get_integration_guide with topic=auth). Explicit alternatives and exclusions leave nothing to inference.

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

All The Bridge 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.