This is not about the CLI itself, and I am filing it here because this repository is the public home for issue tracking on HubSpot's agent tooling and I could find no other published channel for it. Move or close it if it belongs elsewhere.
I measured HubSpot's public agent discovery surface on 28 August 2026 and found two things that look unintended. Every request below was an anonymous GET to a public address with my own user agent, three consecutive requests per address, and each of the three returned the same status and the same byte count.
1. No MCP Server Card at any origin root, including mcp.hubspot.com
mcp.hubspot.com does OAuth discovery correctly. An unauthenticated request answers 401 with WWW-Authenticate: Bearer resource_metadata="https://mcp.hubspot.com/.well-known/oauth-protected-resource", that document answers 200 with 174 bytes, and /.well-known/oauth-authorization-server answers 200 with 813 bytes carrying authorization_endpoint, token_endpoint, an introspection endpoint and code_challenge_methods_supported: ["S256"]. api.hubapi.com serves both at the same sizes and the same digests.
Two fields stop an agent there:
scopes_supported is [] in both documents, so a client learns that authorization exists and not one scope it may request.- Neither document carries a
registration_endpoint, so dynamic client registration is not advertised.
And /.well-known/mcp/server-card.json answers 404 on all eight hosts I asked: www.hubspot.com, hubspot.com, developers.hubspot.com, knowledge.hubspot.com, ecosystem.hubspot.com, mcp.hubspot.com, api.hubapi.com and app.hubspot.com.
One address on the domain does answer:
https://developers.hubspot.com/docs/.well-known/mcp/server-card.json -> 200, 336 bytes
https://developers.hubspot.com/docs/.well-known/oauth-protected-resource -> 200, 140 bytes
https://developers.hubspot.com/docs/.well-known/oauth-authorization-server -> 200, 615 bytes
Those three sit under /docs/ rather than at the origin root, and each of them names the host hubspot.mintlify-auth-docs.com, so they describe the documentation search server rather than the HubSpot MCP server. The authorization server document there does carry a registration_endpoint and scopes_supported: ["mcp:search"]. The same three addresses at the origin root of developers.hubspot.com answer 404.
An agent that follows the specification and asks at the origin root finds nothing about the HubSpot MCP server. It finds a working layer only if it happens to try a documentation prefix, and what it finds there is a different server.
2. /.well-known/api-catalog answers 406 with an empty body to a correct request
This one is simpler. On www.hubspot.com, the same address answers differently depending on the Accept header. Three requests per combination, same result each time:
Accept: text/html -> 404
Accept: */* -> 404
Accept: application/json -> 406, 0 bytes
Accept: application/linkset+json -> 406, 0 bytes
application/linkset+json is the media type RFC 9727 tells a client to send. I ran the same matrix with a browser user agent and got the same result, so the response follows the Accept header rather than the user agent. A client that asks correctly therefore receives less than a browser receives, and it receives a status meaning the format was refused rather than one meaning the document is absent.
Suggested changes
- Serve
/.well-known/mcp/server-card.json for the HubSpot MCP server at mcp.hubspot.com, so the card an agent finds on the domain describes that server.
- Populate
scopes_supported and state how a client registers, in the documents mcp.hubspot.com already serves.
- Return 404 rather than 406 with an empty body for
/.well-known/api-catalog, or serve the catalog.
One smaller note while I was there. www.hubspot.com/llms.txt answers 200 with 30 688 bytes and does not contain the string mcp once, while developers.hubspot.com/docs/llms.txt answers 200 with 28 966 bytes and names the developer MCP server on three lines. Neither file names the other, and neither host names either file in robots.txt.
I am not a HubSpot customer and I have no account. I did not log in, install an agent, connect a connector, issue an API key, register an OAuth application or start an MCP session, and I make no claim about anything behind authentication. The full reading, with every figure and the method, is at https://turva.dev/brief/hubspot-1yl4a9guzbg2i and needs no reply.
This is not about the CLI itself, and I am filing it here because this repository is the public home for issue tracking on HubSpot's agent tooling and I could find no other published channel for it. Move or close it if it belongs elsewhere.
I measured HubSpot's public agent discovery surface on 28 August 2026 and found two things that look unintended. Every request below was an anonymous GET to a public address with my own user agent, three consecutive requests per address, and each of the three returned the same status and the same byte count.
1. No MCP Server Card at any origin root, including mcp.hubspot.com
mcp.hubspot.comdoes OAuth discovery correctly. An unauthenticated request answers 401 withWWW-Authenticate: Bearer resource_metadata="https://mcp.hubspot.com/.well-known/oauth-protected-resource", that document answers 200 with 174 bytes, and/.well-known/oauth-authorization-serveranswers 200 with 813 bytes carryingauthorization_endpoint,token_endpoint, an introspection endpoint andcode_challenge_methods_supported: ["S256"].api.hubapi.comserves both at the same sizes and the same digests.Two fields stop an agent there:
scopes_supportedis[]in both documents, so a client learns that authorization exists and not one scope it may request.registration_endpoint, so dynamic client registration is not advertised.And
/.well-known/mcp/server-card.jsonanswers 404 on all eight hosts I asked:www.hubspot.com,hubspot.com,developers.hubspot.com,knowledge.hubspot.com,ecosystem.hubspot.com,mcp.hubspot.com,api.hubapi.comandapp.hubspot.com.One address on the domain does answer:
Those three sit under
/docs/rather than at the origin root, and each of them names the hosthubspot.mintlify-auth-docs.com, so they describe the documentation search server rather than the HubSpot MCP server. The authorization server document there does carry aregistration_endpointandscopes_supported: ["mcp:search"]. The same three addresses at the origin root ofdevelopers.hubspot.comanswer 404.An agent that follows the specification and asks at the origin root finds nothing about the HubSpot MCP server. It finds a working layer only if it happens to try a documentation prefix, and what it finds there is a different server.
2. /.well-known/api-catalog answers 406 with an empty body to a correct request
This one is simpler. On
www.hubspot.com, the same address answers differently depending on the Accept header. Three requests per combination, same result each time:application/linkset+jsonis the media type RFC 9727 tells a client to send. I ran the same matrix with a browser user agent and got the same result, so the response follows the Accept header rather than the user agent. A client that asks correctly therefore receives less than a browser receives, and it receives a status meaning the format was refused rather than one meaning the document is absent.Suggested changes
/.well-known/mcp/server-card.jsonfor the HubSpot MCP server atmcp.hubspot.com, so the card an agent finds on the domain describes that server.scopes_supportedand state how a client registers, in the documentsmcp.hubspot.comalready serves./.well-known/api-catalog, or serve the catalog.One smaller note while I was there.
www.hubspot.com/llms.txtanswers 200 with 30 688 bytes and does not contain the stringmcponce, whiledevelopers.hubspot.com/docs/llms.txtanswers 200 with 28 966 bytes and names the developer MCP server on three lines. Neither file names the other, and neither host names either file in robots.txt.I am not a HubSpot customer and I have no account. I did not log in, install an agent, connect a connector, issue an API key, register an OAuth application or start an MCP session, and I make no claim about anything behind authentication. The full reading, with every figure and the method, is at https://turva.dev/brief/hubspot-1yl4a9guzbg2i and needs no reply.