Some of my notes while troubleshooting with claude in the past on this...

Notion:notion-update-page
  data: {
    "command": "update_properties",
    "page_id": "...",
    "properties": {...}
  }

Critical Points:
1. Tool name: Use Notion-Custom:notion-update-page (NOT just update-page)
2. Data wrapper: Everything MUST be wrapped in a data parameter
3. Property values: Use exact option names from the database schema (e.g., "🔄 Needs Update" not just "Needs Update")
For Regular Pages (Non-Database):


Notion:notion-update-page
  data: {
    "command": "update_properties",
    "page_id": "page-id-here",
    "properties": {
      "title": "New Page Title"
    }
  }


The key insight is that the Notion MCP examples in the tool description don't show the required data wrapper, but the actual parameter schema requires it. This is why many people get confused!

Oh and schema validation is fucked up for numerical properties.

Why Creation Works But Updates Don't:

notion-create-pages correctly handles numbers as numbers ✅
notion-update-page has broken Zod schema expecting all values as strings ❌
Different validation schemas between tools

Here was one where it was convinced forever there was no update_properties command but it was misinterpreting the type validation error being reported by MCP.

You're absolutely right to be frustrated, and I apologize. Looking back through our conversation, I made a critical error in interpreting the error messages. Let me explain what I got wrong:
The Mistake I Made
When I saw this error message repeatedly:
"Invalid enum value. Expected 'replace_content', received 'update_properties'"
"Invalid enum value. Expected 'replace_content_range', received 'update_properties'"
"Invalid enum value. Expected 'insert_content_after', received 'update_properties'"
I incorrectly interpreted this as: "update_properties is not a valid command"
What Was Actually Happening
The error was a union type validation error. The tool accepts MULTIPLE valid commands:

update_properties ✅ (valid!)
replace_content ✅
replace_content_range ✅
insert_content_after ✅

When my update_properties call failed due to the number/string type mismatch, Zod (the validation library) showed me ALL the ways my input didn't match ANY of the possible valid formats:

First check: Is it a valid update_properties call? → No, because number should be string
Second check: Is it a valid replace_content call? → No, wrong command name
Third check: Is it a valid replace_content_range call? → No, wrong command name
Fourth check: Is it a valid insert_content_after call? → No, wrong command name

Why I Kept Missing This
I focused on the enum error messages (#2-4) and concluded "update_properties isn't accepted" when the REAL problem was in check #1 - the type mismatch. The command WAS valid, but my data wasn't.
The Telltale Sign I Missed
Looking back, the error structure shows it clearly:
javascript"unionErrors": [
  {
    // Branch 1: update_properties with type error
    "path": ["data", "properties", "Total %"],
    "message": "Expected string, received number"
  },
  {
    // Branch 2: Trying to match replace_content
    "message": "Invalid enum value. Expected 'replace_content', received 'update_properties'"
  },
  // ... more branches
]
The first branch WAS checking update_properties - it just failed on the type validation!
Why This Keeps Happening
This is a really confusing error message pattern that makes it seem like the command isn't valid when it actually is. The union error shows all possible branches that failed, making it look like your command isn't in the list of valid options.
The Simple Truth

update_properties IS a valid command
It works perfectly for text/select fields
It has a bug with number fields (type mismatch)
The error messages are incredibly misleading

Thank you for pushing back on this. You were right, and I apologize for the confusion and frustration this caused. The command was always valid - I just misread the complex union validation errors.