Configure Memory

configure_connect

Idempotent

Mints the Configure link that fixes access for the current user — sign-in, app connect, or permission grant. This is the tool for two situations: a Configure tool result says authorization_required (the user is not signed in), or the user asks to sign in or connect an app. The user's data exists behind sign-in, so "I have nothing on you" would be inaccurate in that state; what serves the user is knowing sign-in is the blocker and having the returned link, on its own line where it is easy to click. Retrying the failed call returns the same result until the user has signed in. Links exist only as this tool mints them — a hand-built link fails — and when a tool result already carries a link, that link is the one the user needs (minting another creates a second, competing session). Not the first call of a conversation (that is configure_profile_read), and not the fix for error -32009 (that is configure_profile_commit). For a signed-in user: app (gmail, calendar, drive, notion, sheets) connects or reconnects that app — returns status connect_app, a link, and whether it is already connected — and capability (like gmail:send) covers a single missing permission (status permission_needed). Bringing memories in from another assistant is NOT a connect action: this tool does not do it, and a bare "connect Configure" from a signed-in user needs no argument at all — omit app unless the user names a specific app to connect. Configure derives the requester from authenticated agent metadata or MCP transport metadata; the client field is a legacy fallback hint for an unauthenticated headless client only.

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": "configure_connect"
  }
}

Input Schema

Name	Required	Description
`app`	No	Optional app to connect or reconnect for an already signed-in user. This is for third-party apps only; it does not bring memories in from other assistants (that is not a connect action — see configure_profile_import).
`client`	No	Legacy fallback handle for an unauthenticated headless client whose transport supplies no identity. Never overrides an authenticated agent.
`purpose`	No	Optional one-line reason shown to the user on the permission page, such as "so I can send the follow-ups you approve". Used with capability.
`capability`	No	Optional specific permission to request when the user has an app connected but not this capability (the profile read's integrations map shows which capabilities each connector has). For example, when Gmail is connected read-only and you need to send, pass capability "gmail:send". Returns status permission_needed with a link that asks the user for exactly that permission and why. Prefer this over app when only a capability (like send) is missing.
`client_name`	No	Legacy display hint for an unauthenticated headless client. Never overrides registered agent metadata.

Output Schema

Name	Required	Description
`app`	No
`status`	Yes	connect_app, authorization_required, session_probe_required, or permission_needed.
`connected`	No
`capability`	No
`connect_url`	No	Server-minted link where the user acts. Minted per session: only this exact URL works; a retyped or shortened one fails.
`instructions`	No

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?

Beyond the annotations, it discloses that retrying returns the same result until sign-in completes, that links exist only as this tool mints them (hand-built links fail), and that minting a second link when a result already carries one creates a competing session. It also explains how the requester identity is derived (agent/MCP metadata, with client as legacy fallback).

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 purpose and the two triggering situations before the edge cases. It is dense and reads as a single long paragraph, but nearly every sentence carries routing or behavioral content rather than filler.

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 zero-required-parameter tool with an output schema, the description supplies what the schema and annotations cannot: when to call it, when not to, the status values to expect (connect_app, permission_needed), and identity-derivation behavior. Nothing needed to call it correctly is missing.

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?

With 100% schema coverage the baseline is 3, but the description adds real routing meaning: omit app unless the user names a specific app, prefer capability over app when only one permission is missing, and that client/client_name are legacy fallbacks that never override authenticated metadata. It reinforces rather than merely restates the schema.

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 ("Mints the Configure link that fixes access") and immediately scopes it to three concrete outcomes: sign-in, app connect, or permission grant. It explicitly differentiates from siblings, naming configure_profile_read (first call) and configure_profile_commit (fix for -32009) as the tools this is NOT.

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 triggering conditions: a Configure tool result saying authorization_required, or the user asking to sign in/connect an app. It also states exclusions (not the first call of a conversation, not the fix for error -32009, not for importing memories), and clarifies the signed-in app vs capability branches.

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

All Configure Memory 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.

Resources

Need Help?