Basedash MCP write - Build charts and dashboards from Cursor and Claude

Basedash MCP can now write, not just read. From Cursor, Claude, or any MCP client, ask for a chart or a whole dashboard—Basedash explores the schema, writes and validates the SQL, picks the visualization, and lays it out. The result comes back as a real Basedash chart with a durable link and a rendered image, so you can keep iterating in the IDE or share it with the team. Edit it the same way: “break it out by plan” updates the live chart. Not just read. Write.

Add a comment

Replies

Best
Hey everyone, Max here from Basedash. Today we're launching write access for the Basedash MCP server: your coding agent can now create and edit charts and dashboards, not just read data. Until now, MCP meant asking questions. Now it means building. From Cursor or Claude you can say "chart weekly signups, last 90 days," get a real Basedash chart back with a link and a rendered image, then say "break it out by plan" and watch it update. "Build a growth dashboard: signups, activation, revenue, churn" gives you a laid-out, validated dashboard in one call. Four new tools do the work: create_chart, edit_chart, create_dashboard, edit_dashboard. Basedash explores the schema, writes and validates the SQL, and picks the visualization, so the agent never has to guess at your tables. We've been building our own internal dashboards this way for the last month. Most of them never touched the Basedash UI until someone opened the link. The Product Hunt community gets an extra week on their trial this week. Happy to answer anything.

Once a dashboard has been generated through MCP, does it automatically stay in sync with the underlying database? How do you handle schema changes?

 yes it does! Every chart on the dashboard runs SQL against your database, so if you check back in a week or a month it'll always be up-to-date.

If a schema change breaks a query we show a button that gets the AI to fix it for you in one click.

 Thanks Max! The one-click SQL repair is a clever approach. But what about schema changes that don't break the query, yet silently change the meaning of the data? For example, if a revenue field changes its definition, the dashboard might still work while showing misleading numbers. Is there any way to detect that kind of issue?