Connect by JBRH Open Connect

Adding Connect to ChatGPT

Add https://connectbyjbrh.com/mcp as a remote Streamable HTTP MCP server. Public documentation tools work anonymously; protected tools use Connect OAuth and bind access to the selected Connect company.

Status
Available What this means
Audience
developer
Last verified
Product version
6.3.2

Connection facts#

RequirementConnect
Endpointhttps://connectbyjbrh.com/mcp
TransportStreamable HTTP
Protocol2026-07-28
Protected authenticationOAuth 2.1 authorization code + PKCE S256
Public docsNo OAuth required
Private dataOAuth-bound company
Embedded credentialsNone

Set it up#

  1. Add https://connectbyjbrh.com/mcp as the remote MCP endpoint.

    Result ChatGPT can enumerate the production tool registry.

  2. Use a protected private capability.

    Result Connect starts OAuth when authorization is required; sign in and select the intended company.

  3. Review the requested scope before consenting.

    Result The grant remains limited to that identity, workspace, selected company and scope set.

Portable package#

Connect's Agent Plugin package contains portable manifests and skills that call the same canonical remote MCP server. It contains no second backend and no secret.

A safe first private test#

  1. Ask ChatGPT to read the authorized Connect profile and operational readiness.

    Result A protected read triggers OAuth if needed, and the answer identifies the selected company before any mutation is considered.

  2. Ask for a customer by a specific name or address you know belongs to that company.

    Result search_people returns only records inside the authorized reach; no tenant selector is supplied by the model.

  3. Ask to create a follow-up with a reason and due interval.

    Result The write records a future obligation and returns its stored row. It does not send a customer communication.

  4. Ask for something intentionally outside the v1 surface, such as placing a call.

    Result The connector should say that direct call placement is not exposed rather than reporting an action it could not perform.

Changing or removing access#

A Connect authorization is not permission for every company in the workspace. If work needs to move to another company, use the client's connection/account flow to establish the correct authorization context instead of pasting a tenant identifier into a prompt. The server's protected schemas do not provide that escape hatch. Revoking the OAuth grant or removing the user's live workspace authority stops later protected calls; the package itself stores no secret that needs to be edited.

Write permission is separate from read permission. A user can connect for protected reads without granting configuration or customer-operation changes. When a write is needed, the host can request the additional scope through authorization. This is the preferred test for least privilege: verify that read-only work succeeds while a write call receives an authorization challenge or scope refusal until write access is deliberately granted.

Reviewing marketplace behavior#

A reviewer should distinguish installation from server behavior. Importing the Agent Plugin proves that the manifest is readable. Enumerating the remote endpoint proves the server is reachable. Completing OAuth proves delegated identity. A tenant-scoped read proves isolation. A bounded write plus a cross-company refusal proves that the client is not merely displaying tools but respecting Connect's authority model end to end.

Questions#

Does one consent expose every company in my workspace?

No. Protected tools remain bound to the selected company.

Does installing the package send customer messages?

No. Installation and read tools have no outbound customer side effect.

Does the ZIP contain a vendor API key?

No. Delegated credentials are managed by the MCP host and Connect OAuth.