--- name: connect-volrix description: Connect an AI client to Volrix MCP, complete user-authorized authentication, verify access, and discover the strategy research tools. Use when a user asks to set up Volrix or use Volrix backtesting and the connection may not yet exist. --- # Connect to Volrix Volrix provides remote tools for strategy research, historical backtesting, and report analysis. This skill is connection guidance; loading it does not grant tools or authorize account access. Respect the user's requested scope and the host client's configuration and authentication permissions. ## Connection details - Server name: `volrix` - MCP URL: `https://mcp.volrix.ai/mcp` - Transport: Streamable HTTP - Authentication: OAuth authorization code with PKCE (`S256`); scope `mcp`. - Protected resource metadata: `https://mcp.volrix.ai/.well-known/oauth-protected-resource` - Authorization server metadata: `https://api.volrix.ai/.well-known/oauth-authorization-server` - Human setup guide: `https://volrix.ai/docs` - Account and connection dashboard: `https://app.volrix.ai/mcp` Use the client's native OAuth implementation and the server's discovery metadata. The public metadata supports dynamic client registration and public clients (`token_endpoint_auth_method: none`). A client secret or client-credentials grant is not required for this flow. Do not substitute the obsolete `/sse` endpoint. ## Decide whether setup is necessary Discover any Volrix tools already exposed by the host. If they work, reuse the existing connection. Do not install a second server just because its configured name differs. If Volrix is absent, determine the actual client and whether it can add an MCP server. A terminal-capable agent may configure its own client within the user's authorized scope. A hosted chat agent usually cannot change its app/connector settings. In that case, give the user the MCP URL and the relevant manual steps below. Reading a web page or uploading this skill alone cannot add an MCP transport to a client that lacks one. Preserve unrelated servers and configuration. Inspect an existing `volrix` entry before changing it; do not replace an entry pointing somewhere else without resolving that difference with the user. Use the installed client's help if its syntax differs from these examples. ## Configure the client ### Codex Run in a terminal where Codex is installed: ```sh codex mcp add volrix --url https://mcp.volrix.ai/mcp codex mcp login volrix ``` Let the user complete Volrix sign-in and the requested account authorization in their browser. Never ask them to paste a password, browser cookie, OAuth authorization code, or token into chat. If this session does not acquire newly configured tools, reload the client or start a new session, then verify access. ### Claude Code Use the current project's local scope unless the user requests another scope: ```sh claude mcp add --transport http --scope local volrix https://mcp.volrix.ai/mcp ``` Open Claude Code, run `/mcp`, select Volrix, and follow its authentication action. The user completes browser sign-in. Reopen `/mcp` to inspect the connection and reload the session if necessary. ### Claude web or desktop In a client/account that supports custom remote connectors, open Settings → Connectors, add a custom connector named Volrix with the MCP URL above, and complete OAuth sign-in. Account and workspace policy may restrict this feature. Select/enable the connector for the conversation if the client requires it. ### ChatGPT Use a ChatGPT account/workspace that supports custom MCP apps. In Settings → Apps, use the available custom-app/developer-mode setup, enter the MCP URL and choose OAuth. The user or workspace administrator must enable the feature and approve the app where required. Add the connected app to the conversation. Do not claim that a custom app is available on every plan or that Volrix is already listed in the app directory. ### Other editors, agents, and custom applications Use the host's documented remote MCP settings or an MCP client SDK with Streamable HTTP and OAuth support. Configuration file formats differ; do not assume that a generic JSON block works in every client. For a host using the common `mcpServers` HTTP shape, adapt its documented schema rather than overwriting a whole config file. If the host supports neither remote MCP nor a configurable MCP client, explain that limitation and offer a supported client. Do not claim a connection was made or install an unrequested proxy, daemon, or package to bypass it. ## Verify the connection A saved configuration is not proof of authenticated access. 1. Discover the tools using the host's MCP tool discovery. If tool names are namespaced, use the discovered names. 2. Call `user_plan_info` with no arguments as the initial read-only check. It returns the actual account's plan, quota period, rate limits, and parallel-run capacity. This check does not submit a backtest. Do not expose account identifiers unnecessarily. 3. Report connected only after a successful tool response. If sign-in or session reload is still needed, state that exact next step. An unauthenticated request to `/mcp` can return HTTP 401 with `WWW-Authenticate` pointing to resource metadata. That indicates authentication is required, not a successful tool connection. A normal web-browser GET is not a substitute for the MCP initialization/tool-discovery flow. ## Begin research when requested Keep setup separate from running a strategy. Once the user requests research: - Discover `list_skills` and read the relevant framework guide using `get_skill(topic=...)`. These server-provided strategy guides are distinct from this connection skill. - Confirm the market, test period, execution rules, position sizing, and material missing assumptions. Check availability with `available_duration` before submitting. The appropriate tool family depends on the market/engine. - Follow the discovered framework and tool schemas to validate and run a backtest. Do not invent argument names or treat a sample prompt as a fully specified strategy. - Inspect status, metrics, trades, and execution costs using the actual returned tools/results. Preserve report assumptions and historical dates. Include the returned report links; never manufacture a report URL or performance number. - A backtest can consume quota. Do not run one just to prove that setup works, change the user's plan, place a trade, or publish their research as part of connection setup. ## Recover from a setup problem - No tools after setup: check that the connector is enabled, authentication completed, and the host session reloaded. - HTTP 401: use the client's reauthentication action. Keep credentials in its credential store. - HTTP 403: report the actual permission/entitlement response; do not silently purchase a plan or alter access. - HTTP 429: respect the returned retry guidance and the limits reported by `user_plan_info`; do not retry in a tight loop. - Unsupported client or blocked connector policy: give the manual setup route or explain the missing capability. Stop retrying the same unsupported action. For current client behavior, consult [Claude Code MCP](https://code.claude.com/docs/en/mcp) and [ChatGPT custom MCP apps](https://help.openai.com/en/articles/12584461-developer-mode-apps-and-full-mcp-connectors-in-chatgpt-beta). The server's discovery metadata and the installed client's help take precedence over stale setup examples.