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.

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 & Tools summary and the MCP Builder sections 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 & Tools for the correct handle and confirm the MCP connector endpoint matches the handle you plan to connect.
In MCP Builder, select Refresh builder and Refresh preview and confirm the visible counts for tools, resources, and prompts load successfully.
Review Capability Packs and confirm the enabled packs match the workflows you want to expose.
Review Binding Exposure and confirm only the intended authenticated function bindings are visible as MCP tools.
Review Custom Resource and Custom Prompt entries and confirm names, enablement state, and hints look correct.
Reconnect the MCP client or run tools/list against 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 Builder loads 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.