This topic was automatically generated from Slack. You can find the original thread here.
I’m having some difficulty using a private MCP server with hubspot, specifically using the hubspot-search-crm
tool. Details in
This topic was automatically generated from Slack. You can find the original thread here.
I’m having some difficulty using a private MCP server with hubspot, specifically using the hubspot-search-crm
tool. Details in
according to list-tools
, the comand syntax is:
{
"name": "hubspot-search-crm",
"description": "Search companies, contacts, deals, feedback submissions, products, tickets, line-items, quotes, leads, or custom objects. [See the documentation](https://developers.hubspot.com/docs/api/crm/search)",
"inputSchema": {
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"required": ["objectType"],
"properties": {
"objectType": {
"enum": [
"contact",
"company",
"deal",
"ticket",
"line_item",
"product",
"feedback_submission",
"lead",
"custom_object"
],
"type": "string",
"description": "Type of CRM object to search for"
},
"createIfNotFound": {
"anyOf": [
{
"anyOf": [
{
"not": {}
},
{
"type": "boolean"
}
]
},
{
"type": "null"
}
],
"description": "Set to `true` to create the Hubspot object if it doesn't exist"
}
},
"additionalProperties": false
}
}
So, my agent can specify the objectType to search for, but it is unable to specify the additional criteria by which to search. based on the static schema that validates the call, anything beyond these listed properties gets wiped from the call, meaning that any attempt results in an error similar (based on the objectType) to this:
{
"ts": 1747065180986,
"k": "error",
"err": {
"name": "ConfigurationError",
"exposeStack": false,
"message": "Property `undefined` is not a searchable property of object type `company`. \n\nAvailable searchable properties are: `website`, `phone`, `domain`, `name`",
"stack": "ConfigurationError: Property `undefined` is not a searchable property of object type `company`. \n\nAvailable searchable properties are: `website`, `phone`, `domain`, `name`\n at Object.run (file:///tmp/__pdg__/dist/code/cc6182a29d21e4746f0a99d95f5b3c600f93b7b669f4cc56cadcb96bc9735175/code/actions/search-crm/search-crm.mjs:227:13)\n at async file:///var/task/component_maker.mjs:151:11\n at async captureObservations (/var/task/node_modules/@lambda-v2/component-runtime/src/captureObservations.js:28:5)\n at async run (file:///var/task/component_maker.mjs:141:20)\n at async MessagePort.<anonymous> (file:///var/task/component_maker.mjs:177:9)"
}
}
I was linked to this issue, which appears to have been resolved for non-hosted MCP servers
and while some calls that didn’t work previously now are working (like create contact, create company), the search is still non-functional
We published an update to the reference implementation in our public repo, and specifically we’ve exposed a new method: getTools()
, which enables the client to call an additional set of meta-tools to step through the configuration for the primary tool, which should hopefully unblock you to get things in a better state:
https://github.com/PipedreamHQ/pipedream/blob/824f6a2a5861957d70ec519412c7cae9e0a0[…]49/modelcontextprotocol/src/lib/tools/toolConfigStateMachine.ts
Are you using your own custom MCP client?
Hey Danny! I’m using the modelcontextprotocol client baked into a native tool in our platform that has a few commands exposed: list-tools
and call-tool
, both of which are MCP client calls (client.listTools()
, client.callTool()
) I’m unsure how I would access what you linked via mcp client. when I use the inspector I don’t see these additional tools as being available? Do I need to be running the stateful server (which requires the supabase backing?)
Is there a specific client I should be using instead, maybe?
Ah interesting, just wasn’t sure if you were using a custom client or not – so it sounds like the client probably doesn’t support tool updates, right?
Yea, the dynamic / stateful server would help here, but the code we published is purely a reference implementation, you’d need to have a db backing it – we’ll probably publish it in our production API at some point, we just haven’t yet.