[BUG] update_table / create_table hardcode LCID 1033, blocking all metadata writes in non-English environments

Summary

All metadata-writing tools (create_table, update_table, and therefore all column creation) fail in an environment whose base language is not English (US), because the server writes metadata labels with LCID 1033 hardcoded. There is no parameter to override the language, so the failure is unavoidable from the client side. This makes the entire schema-authoring surface of the MCP server unusable in any organization that does not have en-US provisioned.

Environment

Server	Dataverse remote MCP server (via local proxy)
Client	MCP client, tools invoked directly
Base language / locale	1043 (nl-NL) — confirmed via SELECT languagecode, localeid FROM organization → 1043 / 1043
en-US (1033) provisioned	No
Date	2026-09-08

Steps to reproduce

1. Use an environment whose base language is not 1033 and which does not have 1033 provisioned as an additional language. (Reproduced on 1043 / nl-NL.)
2. Call update_table to add a single text column to any table:

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

3. Observe the failure.

Expected result

The column is created, with its DisplayName and Description labels written in the organization's base language (1043), matching the behaviour of the maker portal.

Actual result

The language code 1033 is not a valid language for this organization

No column is created. The call fails before any metadata is written.

Suspected cause

The server appears to construct Label / LocalizedLabel objects with LanguageCode = 1033 as a constant, rather than reading the organization's base language (Organization.LanguageCode) or the user's UI language. Dataverse rejects any LocalizedLabel whose language is not provisioned for the organization, so the request is refused server-side before the metadata operation runs.

Impact

• Severity: blocker for the schema-authoring capability of the MCP server in non-English organizations.
• Affects create_table, update_table, and all column creation — i.e. every metadata-writing tool the server exposes.
• Not workaroundable from the client: no tool parameter accepts a language or LCID.
• Data tools (create_record, update_record, delete_record) are unaffected in principle, since they write values rather than labels.
• Any agent scenario that provisions or extends the data model is dead on arrival in these environments, which includes most non-US Dataverse tenants.

Suggested fix

Resolve the label language at runtime instead of hardcoding it, in this order of preference:

1. Use Organization.LanguageCode (the organization's base language) as the default for all labels the server writes.
2. Optionally accept an explicit languageCode parameter on create_table / update_table for callers that want to control it.
3. As a defensive measure, validate the intended LCID against provisioned languages before issuing the metadata request, and return an actionable error naming the provisioned languages if it is not available.

Workarounds considered

• Provision en-US as an additional language in the Power Platform admin center. This does unblock the tool, but it means adding a language to a production organization purely to satisfy a client-side default — with knock-on effects for users, translations and solution exports. Not acceptable as a permanent answer.
• Perform schema changes in the maker portal instead. Works, but removes the MCP server from exactly the workflow it is meant to enable.

---

I have correlation IDs and the local proxy log for this failure and can share them through a support incident if that is more appropriate for this repo — happy to move it there if issues here are scoped to the labs only.

Start at the create_table and update_table entry points and reproduce the metadata write in a 1043/nl-NL organization. Trace where label language codes are assigned; done means create_table, update_table, and column creation write labels using the organization's base language without the 1033 error.