MCP Builder and Hosted Tools
Use this guide when you need to review or shape the hosted MCP surface for one handle before handing it to ChatGPT, OpenAI, or another MCP client.
This page focuses on the operator-facing browser workflow. It explains what you can confirm from the MCP & Tools and MCP Builder surfaces, how those surfaces relate to hosted MCP behavior, and when to use OAuth versus PAT.
If you need the broader end-user comparison across ChatGPT/OpenAI MCP, hosted browser workflows, and the Chrome extension, use Hosted Tools & Skills Invocation.
If you need to install a custom plugin inside the local OpenAnalyst runtime, use Custom OpenAnalyst Plugin Setup. MCP Builder shapes the hosted connector surface; it does not install local OpenAnalyst plugins.
If you need to author or update a handle-hosted skill record through the 10x control plane, use JWT Skill Management. That write path uses a signed-in 10x JWT and remains separate from MCP connector OAuth and local OpenAnalyst plugin setup.
Who this is for
- Operators or integrators configuring one handle's hosted MCP surface
- Teams validating what a connector will expose before onboarding an AI client
- Users who need to understand the difference between tools, read-only resources, and reusable prompts
Where to find it
- Open
https://app.10x.in. - Select the handle you want to manage.
- Navigate to
Integrations -> MCP & Tools. - Review the
MCP & Toolssummary and theMCP Buildersections on that page.
What the page shows
| Area | What to review | Why it matters |
|---|---|---|
MCP & Tools | Handle, public URL, MCP connector endpoint | Confirms the hosted endpoint you should register with an MCP client |
MCP Builder | Visible tools, visible resources, visible prompts | Shows the current hosted surface at a glance |
Capability Packs | Built-in packs such as system, knowledge, and commerce | Lets you enable grouped tool/resource/prompt families |
Binding Exposure | Authenticated function bindings exposed as MCP tools | Limits or broadens the dynamic tool set available to clients |
Custom Resource | Read-only tenx://... resources | Adds handle-specific context that clients can read without mutation |
Custom Prompt | Reusable prompts with resource/tool hints | Guides repeatable workflows such as onboarding, debugging, and triage |
How hosted MCP is structured
Hosted MCP can expose three capability shapes for a handle:
| Capability shape | What it does | Examples |
|---|---|---|
| Tools | Perform actions or fetch structured results | links_list, analytics_export, commerce_access_check |
| Resources | Provide read-only context via tenx://... URIs | tenx://commerce/overview, tenx://custom/faq |
| Prompts | Package reusable workflows with optional tool/resource hints | onboarding prompts, debug prompts, refund-triage prompts |
tools/list only returns tools. Resources and prompts appear in MCP clients that support those capability types.
Hosted MCP endpoint patterns
Use one of these endpoint patterns for connector setup and manual validation:
| Endpoint | When to use it |
|---|---|
https://{handle}.mcp.10x.in/mcp | Preferred hosted endpoint for one handle |
https://ai.10x.in/mcp/{handle}/mcp | Compatibility fallback during rollout or troubleshooting |
Use the hosted handle URL when possible. Use the compatibility path only when hosted routing is unavailable or support asks you to validate the fallback path.
OAuth-first setup and when PAT still matters
Use OAuth for connector setup
Use OAuth when connecting ChatGPT, OpenAI, or another MCP client to the hosted endpoint. The hosted connector expects a scoped OAuth flow and issues short-lived bridge credentials for the MCP session.
Use ChatGPT MCP Setup for the full OAuth walkthrough.
Use PAT for non-connector automation and scripted checks
PAT still matters for:
- non-MCP automation against documented public-handle APIs
- scripted discovery or invocation of authenticated MCP bindings
- smoke tests that validate the handle's public or MCP-facing automation surfaces
Do not use PAT as the primary auth model for ChatGPT/OpenAI connector registration.
Use API Tokens and Automations when you need a PAT-backed script or service credential.
Relationship to function bindings
Function bindings are one input into the hosted MCP surface, not the whole surface.
- Function bindings can become authenticated MCP tools when enabled for exposure.
- Capability packs can add built-in tools, resources, and prompts even if no custom binding exists.
- Custom resources and custom prompts add read-only context and reusable workflows without requiring a new action endpoint.
For the public binding contract, use Apps and MCP Tools.
Manual review checklist
- Open
Integrations -> MCP & Toolsfor the correct handle and confirm the MCP connector endpoint matches the handle you plan to connect. - In
MCP Builder, selectRefresh builderandRefresh previewand confirm the visible counts for tools, resources, and prompts load successfully. - Review
Capability Packsand confirm the enabled packs match the workflows you want to expose. - Review
Binding Exposureand confirm only the intended authenticated function bindings are visible as MCP tools. - Review
Custom ResourceandCustom Promptentries and confirm names, enablement state, and hints look correct. - Reconnect the MCP client or run
tools/listagainst the hosted endpoint to confirm the exposed surface matches what the builder preview shows.
What good looks like
- The connector endpoint is clearly visible and uses the expected hosted or compatibility URL.
MCP Builderloads with non-zero or intentionally zero counts for tools, resources, and prompts.- Enabled packs match the workflows you want the client to access.
- Binding exposure is explicit and understandable.
- Custom resources and prompts are readable, intentional, and safe for the target client.