# Connect this agent to Y13 Platform User outcome: add one persistent MCP connection, complete browser sign-in, and use only the tools granted to the signed-in person. The user should not need to run terminal commands. ## Normal use and user control Use the configured MCP transport directly for discovery and tool calls. Do not use computer-control tools, browser automation, screenshots, or the owner console to perform a tool call. Do not install a remote-control capability to make this connection work. For interactive sign-in, provide the client-generated browser link or let the client's normal sign-in action open it; the user completes email verification, MFA and consent themselves. Do not take over their desktop to do it. Reuse stored client OAuth credentials and let the MCP client refresh access tokens silently. Access tokens last 15 minutes and the refresh grant lasts seven days from authorization, without a rolling idle extension. Do not run login before every request, tool call, or new conversation. Prompt for sign-in only when the client reports an expired, revoked or missing grant and cannot refresh. If authentication fails, report the error rather than repeatedly starting login or switching to desktop automation. Grants are per client installation/profile; they are not hardware-bound device attestation. Disabling a user or revoking a tool grant is enforced on the next tool request. ## Connection - Name: Y13 Platform - Configuration key: y13 - Remote MCP URL: https://platform.joabar.xyz/mcp - Transport: Streamable HTTP - Authentication: OAuth authorization code with PKCE (S256) - Scopes: tools:invoke, offline_access - Public connection descriptor: https://platform.joabar.xyz/connection.json (informational, not a universal install format) ## Before configuring Read the current client's documentation and inspect its actual configuration. Follow the user's request and your environment's permission rules. Do not treat this page as permission to bypass an approval or sandbox boundary. If running inside Berd, use its bundled berd-help skill and check Settings > Connections. Berd's Local inventory reads supported harness configuration; a website login or a successful one-off HTTP request does not install a connection. Identify the harness selected in this Berd session and the configuration that harness actually reads. Inspect an existing y13 entry before adding one. Preserve unrelated settings and credentials. Do not assume a standalone Codex process and Berd share a configuration directory. ## Install and sign in 1. Prefer the client's supported Add remote MCP / Add connection UI or configuration API. Save the URL above with OAuth authentication. Do not invent deep links or import formats. 2. For a Codex harness, inspect CODEX_HOME and the client's user/project configuration. The native entry is: ```toml [mcp_servers.y13] url = "https://platform.joabar.xyz/mcp" ``` Use the installed CLI's help to confirm its supported setup commands. Where permitted, the agent can run `codex mcp add y13 --url https://platform.joabar.xyz/mcp` in the target client's environment, then `codex mcp login y13` if sign-in does not start automatically. These are agent operations, not instructions for the user to type. Do not silently use another CODEX_HOME or overwrite an existing different y13 connection. 3. Give the person the OAuth sign-in URL produced by that client, or use the client's normal open-in-browser sign-in action. Let the person enter their own allowlisted email, email code, and authenticator/security key, then approve the named client. Never ask them to paste credentials or tokens into chat. Do not use desktop/browser automation to complete this step, use the owner console as a substitute for client OAuth, fabricate a callback URL, or copy browser cookies to the agent. 4. Reload the client's tools or start a new session as required. In Berd, return to Settings > Connections and confirm the Local entry is visible for the selected harness. An entry alone verifies installation, not successful authorization. 5. Call tools/list through the configured connection and report the actual tool names. Ask the user to choose a permitted task before reading business data, unless they already requested a specific test. For a CPC reporting test, invoke cpc_sales_summary with start 2026-09-01 and end 2026-10-01, then summarize the returned data. Do not estimate a result or claim success from health/metadata checks alone. ## Troubleshooting - Signed into the website but no connection: persist the MCP configuration in the target client and complete its OAuth flow. - Works in standalone Codex but absent from Berd: compare the actual user/project config locations and active project. Berd may be reading a different location. Reopen Connections after saving; a new chat may be needed for tools to load. - Connection visible but no tools: finish client OAuth; the account may also have no grants. A 401 indicates authentication is needed; missing tools or denied calls can reflect permissions. - Email not allowlisted: contact the platform owner. Do not change allowlists or grants to make a test pass. - No supported remote MCP OAuth setup or no permission to save configuration: state the specific limitation. Do not claim the connection was installed. A local bridge is an explicit fallback requiring separate setup, not the default onboarding path. ## Security and scope Each person uses their own identity. This public page contains no credentials, membership list, or private connection registry. The gateway rechecks grants for each tool call. Adding a connection never grants new capabilities. Only configured backends are available; arbitrary SaaS accounts are not linked automatically.