I’m using Baserow’s MCP connector with Claude Desktop and while the core functionality works well, the permissions system has several issues that make it difficult to use safely and effectively.
Issues
1. Table identification is impractical
The permissions interface shows a list of table public IDs without their names. With more than a few tables, manually mapping IDs to table names becomes tedious and error-prone.
Suggested improvement: Only show actionable items in the parameters, and apply permission granularity at the database/table level within the MCP configuration itself.
2. No separation between read and write operations
All actions (read, write, modify, delete) are grouped together in the permissions interface. This increases the risk of accidentally granting destructive permissions.
Suggested improvement: Separate read-only actions from write/modify/delete actions, similar to how other MCP connectors handle this. This would provide a clearer security model and reduce the risk of unintended permissions.
3. Missing scope-based permissions
Currently, there’s no way to limit MCP access to specific databases or workspaces.
Suggested improvement: Allow creating multiple MCP connection points, each scoped to different databases. This would enable better isolation and security for different use cases.
4. Unclear scope of structural permissions
Question: The MCP connector currently exposes list, create, update, and delete operations for rows. Does it also have permissions to:
Create, delete, or modify fields?
Create, delete, or rename tables?
Modify database structure?
If these operations are possible, they should be clearly documented and separately controllable in the permissions system.
Environment
MCP Connector version: baserow
Claude Desktop version: Claude 1.1.2685 (f39a62) 2026-02-10T19:42:56.000Z
Hey @bastien, we’ve already made a few improvements to the MCP server. After the next release, it should be more efficient — we’ve optimized it to handle more tasks with fewer resources.
As for permissions, we’re aware there’s still a lot to improve. We’re planning to implement a system similar to what we currently have in the API settings, where you can define permissions per table:
