[BUG] update_table requires newDisplayName despite documenting it as optional, silently renaming tables

Summary

The newDisplayName parameter on update_table is documented as optional — "New display name for the table. If not provided, the display name will not be changed." — but the server rejects any call that omits it. Because the value is applied when supplied, a caller who only wants to add a column is forced to also send a table display name, and any caller that does not already know the current value will silently rename the table. There is no read path through the MCP server to recover the current display name.

Environment

Steps to reproduce

1. Call update_table with only the required parameters per the tool schema (tablename, item), omitting newDisplayName:

{
  "tablename": "account",
  "item": [
    { "name": "Claude", "type": "string", "maxLength": 100, "required": false }
  ]
}

2. Observe the failure.

Expected result

Per the documented contract, the column is added and the table's display name is left unchanged.

Actual result

Required field 'newDisplayName' is missing for RequestName='McpUpdateTable'

Why this is more than a documentation defect

To add one column, the caller must supply a table display name that the server then writes. An LLM-driven client — the intended consumer of this server — will guess it. On a core table such as account, a wrong guess relabels the table across the entire application UI, and the caller receives a success response.

The current display name is also not retrievable through the server:

• describe('tables/account') returns the collection name, columns and description, but not the display name.
• The entity metadata table rejects queries: Service type is not defined for the Component: Entity.
• It was recoverable only incidentally, via search('account') at a raised result limit, which returned tables/account - Organisatie. At the default limit the correct table did not appear in the results at all.

Suggested fix

Either:

1. Honour the documented contract — make newDisplayName genuinely optional, and leave the display name untouched when it is absent. (Preferred; this is what the tool description already promises.)
2. Or, if it must remain required, stop applying it when unchanged and expose the current display name through describe('tables/{name}') so a caller can read it before writing. Update the tool description to state that the parameter is required and that it overwrites.

Option 1 is the safe fix: a tool whose only documented purpose in the call is "add a column" should not be able to rename the table as a side effect.

Related

Found alongside a separate, more severe defect in the same tool: update_table hardcodes LCID 1033, which blocks all metadata writes in non-English environments. Filed separately.

Start at the update_table tool entry point and its request handling, then compare the implementation with the documented optional newDisplayName behavior. Reproduce the omission case and verify that adding a column succeeds without changing the existing display name, including the nl-NL scenario described.