Unable to produce correct `object` type tool call param

#18
by arnrightnow - opened

Not sure which step is the problem here, but you can have a stable reproduction of the issue using the update tool in Notion MCP.

The tool call param that GLM 4.7 produced:

<parameter name="data">{"command": "insert_content_after", "page_id": "[REDACTED]", "selection_with_ellipsis": "[REDACTED]"}</parameter>

For some reason it's parsed and interpreted as a JSON string instead of an object so the Notion MCP tool param validation failed since it expects an object.

Other models have no issue with it, for example, MiniMax M2.1 calls the tool successfully.

Note

The tool call param XML was produced by the model after I asked it "what was the exact tool call params you used for the tool"

Are you using the API or the open-source model?

Are you using the API or the open-source model?

@ZHANGYUXUAN-zR Hi, I am using the official Z.AI provider on OpenRouter. The same issue also occurred using OpenCode Zen's GLM 4.7 API

Could you provide a specific request to reproduce the issue? Or the request ID (if you can reproduce it using the official zai API).

@ZHANGYUXUAN-zR I don't really have official ZAI request IDs but you can reproduce using these exact steps using either Claude Code or OpenCode, or anything with MCP support I guess:

  1. Add Notion MCP and finish OAuth
  2. Ask the model to update a specific document with a given content, the document and content don't seem to matter

I will attach some reasoning from the model here, not sure if it helps:

The user is asking me to analyze the message history and understand why the Notion update tool is failing. Let me trace through the issue:

  1. The user asked me to update a section in their Work Journal in Notion
  2. I tried to use the notion_notion-update-page tool
  3. Each time I got an error: Invalid arguments for tool notion-update-page: Expected object, received string for path: data

Looking at the tool call format, I was calling:

{
  "data": {
    "command": "replace_content_range",
    "page_id": "...",
    ...
  }
}

But based on the error, it seems like the tool expects the parameters directly without wrapping them in a data key. The tool schema shows:

notion_notion-update-page = (_: {
  data: {
    command: "update_properties" | "replace_content" | "replace_content_range" | "insert_content_after",
    page_id: string,
    ...
  }
}) => any;

So the tool expects the arguments to be passed directly, not nested under a data key. The correct format should be:

{
  "command": "replace_content_range",
  "page_id": "25638121-c06e-80f3-b60c-c52eb77f37a0",
  "selection_with_ellipsis": "...",
  "new_str": "..."
}

NOT:

{
  "data": {
    "command": "replace_content_range",
    "page_id": "...",
    ...
  }
}

The confusion likely came from the example in NOTION_UPDATE_TOOL_GUIDE.md which showed:

{
  "data": {
    "command": "replace_content_range",
    ...
  }
}

But that appears to be misleading - the actual tool schema doesn't expect a data wrapper.

I'll draft a clear, step-by-step guide to help others avoid this tool usage pitfall. I'll create a concise reference that highlights the correct method for invoking the Notion update tool, focusing on the specific parameters and their proper formatting.

This is very frustrating. The tool keeps saying Expected object, received string for path: data.

Let me think about this differently. Maybe the issue is in how the XML interface is being parsed.

Looking at the XML tool interface structure I'm using:

<notion_notion-update-page>
  <data>{...JSON string...}</data>
</notion_notion-update-page>

Maybe the interface is treating <data>...</data> content as a string even though it contains JSON. The schema says data should be an object, but maybe the XML-to-parameter mapping is keeping it as a string.

Let me check if there's a different way to structure the XML call that would make data an actual object instead of a string...

Actually, I wonder if I should NOT use the <data> tag at all, and instead pass the parameters directly as sub-elements?

Like:

<notion_notion-update-page>
  <command>insert_content_after</command>
  <page_id>25638121-c06e-80f3-b60c-c52eb77f37a0</page_id>
  <selection_with_ellipsis>...</selection_with_ellipsis>
  <new_str>...</new_str>
</notion_notion-update-page>

Let me try this approach:

Now it says data is undefined. So data IS required. The schema clearly shows it's required.

But when I pass data as a JSON string in the <data> element, it says "Expected object, received string". And when I don't include <data>, it says "Required".

This seems like a fundamental issue with how the XML interface handles the data parameter when it's supposed to be a complex object.

Let me look at the function definition one more time at the beginning of the conversation...

{
  "name": "notion_notion-update-page",
  "parameters": {
    "$schema": "http://json-schema.org/draft-07/schema",
    "properties": {
      "data": {
        "allOf": [
          {
            "anyOf": [
              {
                "properties": {
                  "command": {"enum": ["update_properties"], "type": "string"},
                  ...
                },
                "required": ["command", "page_id"],
                "type": "object"
              },
              {
                "properties": {
                  "command": {"enum": ["replace_content"], "type": "string"},
                  "new_str": {"type": "string"},
                  "page_id": {"type": "string"}
                },
                "required": ["command", "page_id", "new_str"],
                "type": "object"
              },
              {
                "properties": {
                  "command": {"enum": ["replace_content_range"], "type": "string"},
                  "new_str": {"type": "string"},
                  "page_id": {"type": "string"},
                  "selection_with_ellipsis": {"type": "string"}
                },
                "required": ["command", "page_id", "selection_with_ellipsis", "new_str"],
                "type": "object"
              },
              {
                "properties": {
                  "command": {"enum": ["insert_content_after"], "type": "string"},
                  "new_str": {"type": "string"},
                  "page_id": {"type": "string"},
                  "selection_with_ellipsis": {"type": "string"}
                },
                "required": ["command", "page_id", "selection_with_ellipsis", "new_str"],
                "type": "object"
              }
            ]
          }
        ]
      }
    },
    "required": ["data"],
    "type": "object"
  }
}

I see the schema is validating the data parameter as an object with specific commands. The validation seems strict about the type, requiring an object rather than a string. This suggests I need to ensure I'm passing a properly structured JSON object when using this function.

The XML interface might be introducing some complexity with object parsing. I'll investigate how other similar tools with nested object parameters are handled, potentially revealing a pattern for correct implementation.

The search for similar complex parameter structures seems promising. Finding a working example could clarify the exact requirements for passing object-type parameters in this system.

Examining the notion_notion-create-pages function's parent parameter provides a potential model for structuring complex nested parameters. The key appears to be passing attributes directly as XML attributes rather than using nested tags.

I'll experiment with converting the JSON structure to XML, using attributes for command and page_id, and CDATA sections for longer text content. This approach might resolve the previous parsing issues with nested XML elements.

The strategy involves flattening the object hierarchy, using XML attributes for simple string values, and CDATA for text fields like selection_with_ellipsis and new_str.

This is a persistent issue. The XML interface seems to be treating <data>content</data> as a string regardless of whether it contains JSON.

Let me think about this from first principles. The tool schema says:

  • data is required
  • data must be an object

But the XML interface is converting <data>...</data> content to a string.

Maybe there's no way to use notion_notion-update-page through this XML interface, and it's a bug in the system?

Or maybe I should inform the user that there seems to be a technical issue with the tool and suggest they update the Notion page directly or through the Notion app/website.

Actually, let me check if there's a NOTION_UPDATE_TOOL_GUIDE file

Here you can see that I actually created a NOTION_UPDATE_TOOL_GUIDE using MiniMax M2.1 to teach GLM 4.7 how to correctly do it but it still failed. At least in its easoning it also speculated that the XML might be the issue.

Sign up or log in to comment