# MCP Server type issue for single/multi select **URL:** \ **Category:** Technical Help\ **Created:** [June 7, 2025, 1:37pm UTC](https://community.baserow.io/t/mcp-server-type-issue-for-single-multi-select/10447 "2025-06-07T13:37:26Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![rlamers](https://community.baserow.io/user_avatar/community.baserow.io/rlamers/32/4281_2.png) [@rlamers](https://community.baserow.io/u/rlamers)\ **Post date:** [June 7, 2025, 1:37pm UTC](https://community.baserow.io/t/mcp-server-type-issue-for-single-multi-select/10447/1 "2025-06-07T13:37:26Z")
### Are you using our SaaS platform ([Baserow.io](http://Baserow.io)) or self-hosting Baserow? SaaS ### What are the exact steps to reproduce this issue? Use the MCP server, try to create or update a row that has a single select or multi select field, then when the MCP client provides an integer value for the single/multi select option the server rejects the create/update call, but when it provides the string value of that option, it works server side, but the schema validation of the input arguments of the tool call fail. For MCP clients that strictly validate the tool input arguments this leads to an impossibility of creating/updating rows with single/multi select fields. ---
**Author:** ![bram](https://community.baserow.io/letter_avatar_proxy/v4/letter/b/9d8465/32.png) [@bram](https://community.baserow.io/u/bram)\ **Post date:** [June 10, 2025, 11:31am UTC](https://community.baserow.io/t/mcp-server-type-issue-for-single-multi-select/10447/2 "2025-06-10T11:31:08Z")
Hey @rlamers, how does the tool call look like specifically for you, and which software are using to integrate with Baserow using the MCP? When I was testing this with Claude, it was working as expected. However, I can see where this could go wrong because it accepts both an int and string as type. If an int is provided, then a lookup will be done on the select option ID, but if a string is provided, then on the name. Maybe we can improve how this works from our side by including the option IDs in the property description of schema. ---
**Author:** ![rlamers](https://community.baserow.io/user_avatar/community.baserow.io/rlamers/32/4281_2.png) [@rlamers](https://community.baserow.io/u/rlamers)\ **Post date:** [June 13, 2025, 7:37am UTC](https://community.baserow.io/t/mcp-server-type-issue-for-single-multi-select/10447/3 "2025-06-13T07:37:47Z")
This error came up in LangChain js as part of n8n. I think LangChain/LangGraph check the argument type matching. The argument type of “entity\_type” is strictly “integer” not “string”, so a stricter library will reject a string value. ![Screenshot 2025-06-12 at 10.08.06 PM](https://community.baserow.io/uploads/default/original/2X/e/eb63b785b253d6343f2f0b6508c9def4bb810820.jpeg) Does that help? ---
**Author:** ![bram](https://community.baserow.io/letter_avatar_proxy/v4/letter/b/9d8465/32.png) [@bram](https://community.baserow.io/u/bram)\ **Post date:** [June 16, 2025, 10:59am UTC](https://community.baserow.io/t/mcp-server-type-issue-for-single-multi-select/10447/4 "2025-06-16T10:59:59Z")
Hey @rlamers, thanks for all the information provided here. I was able to solve two bugs related to it here [Fix MCP select option bug (!3547) · Merge requests · Baserow / baserow · GitLab](https://gitlab.com/baserow/baserow/-/merge_requests/3547). ---
**Author:** ![rlamers](https://community.baserow.io/user_avatar/community.baserow.io/rlamers/32/4281_2.png) [@rlamers](https://community.baserow.io/u/rlamers)\ **Post date:** [June 16, 2025, 6:45pm UTC](https://community.baserow.io/t/mcp-server-type-issue-for-single-multi-select/10447/5 "2025-06-16T18:45:28Z")
I quickly looked at the MR and I recall the MCP server actually not even accepting a correct integer ID for the option (I looked up the ID through using the frontend and finding option names having IDs in their ‘value’ property). Not sure if the MR addresses that, but would be good to test. ---
**Author:** ![bram](https://community.baserow.io/letter_avatar_proxy/v4/letter/b/9d8465/32.png) [@bram](https://community.baserow.io/u/bram)\ **Post date:** [June 19, 2025, 7:56am UTC](https://community.baserow.io/t/mcp-server-type-issue-for-single-multi-select/10447/6 "2025-06-19T07:56:16Z")
Yes, that will be addressed in this merge request. There was a problem in how the MCP tool forwards the request to the API. The data structure was wrong, causing integers to be converted to strings. This has been fixed. ---
**Author:** ![radekmaziarka](https://community.baserow.io/letter_avatar_proxy/v4/letter/r/a698b9/32.png) [@radekmaziarka](https://community.baserow.io/u/radekmaziarka)\ **Post date:** [July 1, 2025, 5:57am UTC](https://community.baserow.io/t/mcp-server-type-issue-for-single-multi-select/10447/7 "2025-07-01T05:57:43Z")
I am experiencing the same problem - and PR is ready to merge. Could we just merge it? 😃 ---
**Author:** ![skillhacker](https://community.baserow.io/user_avatar/community.baserow.io/skillhacker/32/4051_2.png) [@skillhacker](https://community.baserow.io/u/skillhacker)\ **Post date:** [April 6, 2026, 5:18am UTC](https://community.baserow.io/t/mcp-server-type-issue-for-single-multi-select/10447/8 "2026-04-06T05:18:37Z")
Calude.ai and Claude Code experience the same thing now. Their report is: > The error is `select_for_update cannot be used outside of a transaction`. Here’s the technical summary: > > `select_for_update()` is a Django ORM call that locks a row during a read-before-write operation. Django requires it to be wrapped in an `atomic()` transaction block. Somewhere in Baserow’s MCP server implementation, a write operation (create, update) is calling `select_for_update()` outside that block — most likely a race condition or a missing `with transaction.atomic():` wrapper introduced in a recent Baserow release. > > **What works:** read operations (list, search, schema, delete — delete doesn’t use select\_for\_update). > > **What’s broken:** create and update — both write paths. Two connectors, same error, three days — this is a Baserow-side regression, not our configuration. I tried to recreate the MCP connector, but encountered the same problem. Has this issue been resolved, or is there a workaround? ---
**Author:** ![olgatrykush](https://community.baserow.io/user_avatar/community.baserow.io/olgatrykush/32/219_2.png) [@olgatrykush](https://community.baserow.io/u/olgatrykush)\ **Post date:** [April 10, 2026, 12:30pm UTC](https://community.baserow.io/t/mcp-server-type-issue-for-single-multi-select/10447/9 "2026-04-10T12:30:51Z")
Hey @radekmaziarka and @skillhacker, it looks like this have been fixed in the 2.2 release. Could you check if it’s working correctly now? ---
**Author:** ![rmdes](https://community.baserow.io/letter_avatar_proxy/v4/letter/r/f9ae1b/32.png) [@rmdes](https://community.baserow.io/u/rmdes)\ **Post date:** [May 22, 2026, 2:17pm UTC](https://community.baserow.io/t/mcp-server-type-issue-for-single-multi-select/10447/10 "2026-05-22T14:17:20Z")
Confirming this on our self-hosted instance — with additional detail on the root cause and a data-integrity angle that may not be in the thread yet. Environment - Baserow self-hosted, version 2.2.2 - Backend served via ASGI (Server: uvicorn confirmed in response headers) - PostgreSQL backend - Accessed through the built-in MCP server endpoint (/mcp//sse) via the mcp-remote stdio\<-\>SSE bridge Symptom Every MCP write tool call (create\_rows) returns: `Error: select_for_update cannot be used outside of a transaction.` MCP read tools (list\_databases, list\_tables, get\_table\_schema, list\_table\_rows) work fine. The identical write via the REST API (POST /api/database/rows/table/{id}/) also works fine. So the fault is specific to the MCP server’s write path. Data-integrity angle (the important part) Despite returning an error, the row is actually created and committed. The caller sees a failure, but a row appears in the table. A client that retries on error therefore produces duplicates — in our case 4 retries created 4 duplicate rows plus the original. This isn’t just a feature outage; it’s silent partial-write + duplication. Root cause analysis `select_for_update cannot be used outside of a transaction is Django’s TransactionManagementError, raised when QuerySet.select_for_update() runs with the DB connection in autocommit mode and no active transaction.atomic() block.` - Baserow’s REST mutating endpoints execute inside a transaction (ATOMIC\_REQUESTS / explicit atomic()), so the row-creation logic — which internally uses select\_for\_update to lock rows for order computation and link-field integrity — works correctly. - The built-in MCP server’s write tools dispatch into the same RowHandler code, but the MCP tool-handler path is not wrapped in transaction.atomic(). Under autocommit, the internal select\_for\_update raises immediately. - Because there is no surrounding transaction, the work completed before the failing select\_for\_update (the row INSERT, and link/m2m writes) is auto-committed and never rolled back → error returned to the client and an orphan row left behind. Workaround Use the REST API with a Database token for writes; the MCP endpoint remains usable for reads. ---
**Author:** ![rmdes](https://community.baserow.io/letter_avatar_proxy/v4/letter/r/f9ae1b/32.png) [@rmdes](https://community.baserow.io/u/rmdes)\ **Post date:** [June 4, 2026, 8:03pm UTC](https://community.baserow.io/t/mcp-server-type-issue-for-single-multi-select/10447/11 "2026-06-04T20:03:16Z")
Anyone is still alive ? ---
**Author:** ![olgatrykush](https://community.baserow.io/user_avatar/community.baserow.io/olgatrykush/32/219_2.png) [@olgatrykush](https://community.baserow.io/u/olgatrykush)\ **Post date:** [June 9, 2026, 10:17am UTC](https://community.baserow.io/t/mcp-server-type-issue-for-single-multi-select/10447/12 "2026-06-09T10:17:24Z")
Hey @rmdes, I must have missed the message — sorry about that! I’ve asked the dev team to take a look at the request. ---
**Author:** ![olgatrykush](https://community.baserow.io/user_avatar/community.baserow.io/olgatrykush/32/219_2.png) [@olgatrykush](https://community.baserow.io/u/olgatrykush)\ **Post date:** [June 10, 2026, 9:41am UTC](https://community.baserow.io/t/mcp-server-type-issue-for-single-multi-select/10447/13 "2026-06-10T09:41:20Z")
Hey @rmdes, thanks for pointing this out. Here is the PR to fix the issue: [fix(backend): MCP create\_rows does not fail when table has rich text fields with @mentions by dimmur-brw · Pull Request #5494 · baserow/baserow · GitHub](https://github.com/baserow/baserow/pull/5494) 🙌 ---
**Author:** ![rmdes](https://community.baserow.io/letter_avatar_proxy/v4/letter/r/f9ae1b/32.png) [@rmdes](https://community.baserow.io/u/rmdes)\ **Post date:** [June 22, 2026, 12:23pm UTC](https://community.baserow.io/t/mcp-server-type-issue-for-single-multi-select/10447/14 "2026-06-22T12:23:23Z")
Good news, do you know when this will be published on the next release docker image ? ---
**Author:** ![olgatrykush](https://community.baserow.io/user_avatar/community.baserow.io/olgatrykush/32/219_2.png) [@olgatrykush](https://community.baserow.io/u/olgatrykush)\ **Post date:** [June 22, 2026, 12:25pm UTC](https://community.baserow.io/t/mcp-server-type-issue-for-single-multi-select/10447/15 "2026-06-22T12:25:43Z")
Hey @rmdes, the next release is planned for the beginning of July 🙌