I’m able to do everything I need with the search_crm_objects tool, however when a result comes back with an hs_object_id, I would think using get_crm_objects would be more efficient for my app. The issue is - this tool seems to always return no data, no matter what I have tried.
For example:
{ “objectType”: “CONTACT”, “objectIds”: [ 187115554929 ] }
will return:
{ “objects”: [], “notFound”: [ 187115554929 ] }
even though I have validated 187115554929 exists. I have tried with other objects such as company with the same results. The app has proper scope. Tried lowercase and uppercase. Is anyone else having success with this tool?
@bbither wrote:
I’m able to do everything I need with the search_crm_objects tool, however when a result comes back with an hs_object_id, I would think using get_crm_objects would be more efficient for my app. The issue is - this tool seems to always return no data, no matter what I have tried.
For example:
{ “objectType”: “CONTACT”, “objectIds”: [ 187115554929 ] }
will return:
{ “objects”: [], “notFound”: [ 187115554929 ] }
even though I have validated 187115554929 exists. I have tried with other objects such as company with the same results. The app has proper scope. Tried lowercase and uppercase. Is anyone else having success with this tool?
The reason get_crm_objects is returning notFound even though the record exists is usually due to how the request is formatted, not permissions or the object itself. Although hs_object_id looks like a number, HubSpot treats it as a string, so passing it as a numeric value can cause the API to fail to match the record. Wrapping the ID in quotes often resolves the issue. In addition, the object type must be passed in the exact format the API expects, such as contacts or the internal object type ID like 0-1 for contacts and 0-2 for companies, rather than uppercase values like CONTACT. If the record is archived or was created very recently, it may also not be returned. In practice, using “objectType”: “contacts” and providing the hs_object_id as a string fixes the issue for most developers, and if problems persist, calling the single-object endpoint (/crm/v3/objects/{objectType}/{id}) is a reliable fallback.
Hi @bbither
Please share the piece of code so we can review it and provide more accurate assistance.
Thanks!
Hey @bbither
TG6 nailed the main issue. The MCP server’s get_crm_objects tool is picky about formatting in ways that arent obvious from the docs.
Two things to try:
1. Pass objectIds as strings, not numbers:
{ “objectType”: “contacts”, “objectIds”: [“187115554929”] }
Instead of:
{ “objectType”: “CONTACT”, “objectIds”: [187115554929] }
JavaScript can also silently mangle large integers, so if you’re getting the ID from search_crm_objects and passing it along, it might be getting corrupted. Always treat hs_object_id as a string throughout your code.
2. Use lowercase object types:
The MCP tools expect contacts, companies, deals, etc., not the uppercase versions. This is inconsistent with some other HubSpot interfaces which is confusing, but thats how it works.
One other thing, the MCP server is still in beta and I’ve seen it behave inconsistently depending on which version you’re running. If you’re self hosting it, make sure you’ve pulled the latest. There were some fixes pushed recently around object retrieval.
If strings + lowercase still doesnt work, the fallback like TG6 mentioned is using the single object endpoint directly. Less efficient for batches but at least its reliable.
At Stacksync we’ve run into similar HubSpot API quirks where the same ID works in one endpoint but fails in another due to type handling. Their API isnt always consistent about string vs number for IDs across different endpoints. Annoying but you get used to defensive coding around it. Note: This response was written based on my own experience and lightly reformatted with AI for clarity.
Let us know if the string format fixes it!