The Connect MCP server
Connect runs one remote MCP server at POST https://connectbyjbrh.com/mcp using Streamable HTTP and protocol revision 2026-07-28. Public documentation tools are anonymous; private business tools require OAuth and are bound to the authorized workspace and selected business.
Endpoint#
| Property | Value |
|---|---|
| Endpoint | https://connectbyjbrh.com/mcp |
| Transport | Streamable HTTP, POST |
| Protocol | 2026-07-28 |
| Public tools | Documentation only, no credential |
| Private tools | OAuth 2.1 authorization code + PKCE S256 |
| Protected-resource metadata | /.well-known/oauth-protected-resource/mcp |
| Authorization-server metadata | /.well-known/oauth-authorization-server |
| Client registration | /oauth/register for compatible public clients |
| Discovery | /.well-known/mcp.json |
Business isolation#
- The caller cannot supply a workspace or business id to widen its grant.
- Business data reads use the same Data Workspace business-reach rules as the application.
- Configuration writes call existing business services instead of arbitrary SQL or arbitrary route proxies.
- Owner diagnostic tools are not present in the production marketplace registry.
Tool safety#
Production tools declare MCP annotations for read-only, destructive, idempotent and open-world behavior. An internal provider capability is not automatically exported as an MCP action; external sends and calls need an independently reviewed action contract.
How a protected call is challenged#
Tool discovery is intentionally possible before account linking, so a marketplace can show what Connect offers. Calling a protected tool without suitable authorization does not silently return an empty business and does not execute partially. The tool result carries an MCP authentication challenge pointing at the protected-resource metadata. A compatible host follows that document to the authorization server, completes authorization code plus PKCE, then retries with the resulting bearer token.
The protected tool itself names the scope it needs in its security scheme. Business record searches and ordinary readiness reads ask for mcp:business:read; configuration and customer-operation writes ask for mcp:business:write. This distinction matters to a reviewer because merely listing the server must not pressure a user into granting write authority, and a read-only connection remains useful without it.
Failure behavior worth testing#
- A protected call without OAuth returns an authorization challenge rather than workspace data.
- A token without the named scope is refused; a business binding alone is not permission.
- A business id included as an invented tool argument is rejected where the schema does not allow it.
- A record id from another business is treated as outside the current business reach rather than as a shortcut around list filtering.
- A production process does not advertise Owner diagnostic tools. Their development opt-in is ignored in production.
- A customer-operation write that reaches an approval boundary reports the held/refused outcome instead of converting the model invocation into a person's approval.
Questions#
Can I use Connect MCP without signing in?
Yes for public product documentation. Private business data requires OAuth.
Can one business grant read another business?
No. Protected tools derive the business from authorization and enforce the application's business reach.
Does the plugin ZIP contain a secret?
No. OAuth discovery and credential storage are client-managed.