June 18, 2026 / Whiteboard Templates, Delegate user management via access templates

News & Announcements Changelog
21

Sure, thank you! I’ll ask my colleagues to prepare a short description of our use cases for working with video on Whiteboards and send it to you. :+1:

22

Thanks :ok_hand:

1 Like
23

Great! Does this include a way to share templates?

25

I asked claude to find all our friction points from things we’ve tried to do recently:

Context: we run Wildkind on one Fibery workspace (~271 databases, ~30 spaces, 1,840 views) with Claude agents reading and writing across the business through the MCP daily, plus our own connectors/apps on your REST/GraphQL API. Everything below is friction we’ve actually hit, checked against what’s already shipped. Grouped by theme; tier A is where the daily pain concentrates.

A. The write path

  1. Transactional one-shot writes. Let one create/update set state, relations, collections and document content together. Today a realistic entity is 4+ sequential calls (create_entities → set_state → add_collection_items → set_document_content) — each its own round-trip, and a mid-sequence failure leaves a half-built record.
  2. Upsert / find-or-create with idempotency keys. No dedup primitive, so every skill runs a mandatory multi-search before each write to avoid double-logging — and still races.
  3. Cross-call atomicity + rate-limit headroom. Array batching within a database works; what’s missing is atomicity across the calls above, and headroom on the ~3 req/s ceiling (a launch-blocker we’ve engineered around; serverless can’t coordinate under it).

B. Trust, identity & access

4. Scoped agent seats + AI-vs-human attribution. The activity log separates automation/integration changes from human edits — but an MCP agent’s write is indistinguishable from one I made by hand (it uses my token and admin role). Dedicated agent seats with per-space scopes + agent attribution would let us delegate confidently and audit. (I’ve raised this as “MCP access for trusted member accounts.”)

5. Permissions management via the MCP. The platform has rich access control (you added user-visibility controls in May) — the MCP exposes none of it. Agents can build a database but can’t set who sees it, so your own “put sensitive data in its own database and permission it” pattern can’t be automated end-to-end. Read effective access + share/revoke at space/database/entity + groups.

6. Provenance / trust signals on externally-sourced data. Expose where an entity came from (public form, which connector) and a “treat as untrusted” read. We caught a prompt-injection payload in a record created via a public Fibery form; agents process that data routinely.

C. Read, query, context & hygiene

7. Slim, scoped, cacheable schema. schema_detailed is already scopeable — great. The top-level schema is all-or-nothing and includes dozens of databases marked “should not be used”; add active-only/space filters, server-side schema search, and a schema version/ETag so agents can cache instead of re-pulling and re-resolving option UUIDs every session.

8. Richer querying. Aggregation inside sub-queries, group-by, filter-parent-by-child. Today nested aggregation fails outright (Sub query aggregate expressions are not supported), forcing us to pull raw rows and compute client-side under the rate cap.

9. Create report and embed views. create_view builds grids, boards, timelines… but supports neither report (“not yet supported here”) nor embed — so an agent can generate an AI HTML report but can’t publish it as a chart or surface it in the sidebar. We already run ~32 reports and use Embed View for AI-generated HTML.

10. View & workspace usage analytics. Expose telemetry through the MCP — when a view was last opened, how often, by whom — plus last-modified and created-by on views (today query_views returns only a creation date). Concrete case: 1,840 views across 34 spaces, ~53% auto-named clutter (“List”, “… copy”, “Test”); we want agents to retire the dead ones, but with no usage signal they can only guess from names.

D. Content fidelity

11. Entity references / backlinks in agent-written text. Let document content include a mention token that creates a true bidirectional reference, not a flat link (your own community still lists this as open). Every database has a References collection driving navigation; agent-written prose is currently a dead-end in it.

12. Inline & whiteboard comments via the MCP. The product supports these; add_comment can’t create them (“Inline comments … are NOT supported”). It’s exactly how a human reviews an AI-drafted doc in context.

13. Direct file upload + OCR/transcription. download_file reading images/text inline is great. Gaps: agents can’t upload file bytes (only from a public URL), and can’t get text out of PDFs/Office/audio/video. A lot of our knowledge is locked in those attachments.

E. Structure & automation

14. Sidebar & navigation management. Let agents read and set the sidebar itself — Smart Folders, view ordering, pinning/favourites, placement — not just which space a view belongs to. Today the MCP can move/rename/delete views but can’t arrange the navigation a human stares at all day. (From a live task: “our Fibery feels bloated, refine the sidebar” — the MCP gets ~80% and stops.)

15. Entity & relation view layouts. Let agents manage the per-database Entity View (Manage Fields & Layouts — columns, sections, hide/move/pin fields, plus Multiple Entity Views and Entity View Rules) and Relation Views (how each to-many relation renders on the entity page — List/Table/Timeline, grouping/sort, or Compact List). Today the MCP only touches standalone sidebar views — none of the 1,840 it can see are entity or relation views — so an agent can build a database and add fields but can’t arrange how the entity presents, leaving a human to finish every one.

16. Automation & button management via the MCP. You’ve built strong automations (incl. the new Send Web Request action) and outbound webhooks — none reachable from the MCP. Let agents read and create automations and buttons. Much of the friction we log resolves to “needs automation”; today agents can diagnose it but can’t build the durable fix.

17. Workspace environment variables (server-side secret store). A named, workspace/space-scoped variable store — like Vercel or GitHub Actions secrets — that automations, integrations and Fibery-hosted artifacts reference by name (e.g. {{env.STRIPE_KEY}}), encrypted and resolved server-side, never sent to the browser. You already do this in miniature (Send Web Request stores encrypted tokens) and “global variables” is a long-standing community request; generalising it to a secret tier is what lets AI-generated automations and artifacts “just work” without us standing up a proxy for each one.

F. Vision / emerging

18. AI-generated HTML artifacts — live and secure. Embed View (April 2026) already surfaces AI-generated HTML in the sidebar — great. To make it a real workflow: (a) let the MCP create/manage Embed Views so an agent can publish a generated dashboard end-to-end; (b) give an embedded artifact a sandboxed, viewer-permission-scoped data token for live Fibery data, and let it reach other sources via the workspace env vars (#17) through a server-side call — so no credential ever ships to the browser.

19. A “Fibery Architect” capability. First-party guidance/skill that helps an AI design and tidy a workspace — databases, relations, views, reports, sidebar, entity layouts, permissions — from plain-language intent. The natural top of the funnel for everything above.

26

My personal choice of from that (in no particular order) would be:

  • Backlinks

  • File attachments

  • Permissions

  • Create reports & embed views

  • Manage entity views and relation views

  • Workspace analytics

  • Automations

  • Sidebar management

Could sum it up by saying anything a human can do an agent should be able to do. I want claude to be able to build a process across our tech stack end to end, which involves fibery, and it can do it on almost everything else but always hits blockers at fibery stage.

Also, Fibery has always had a bit of an adoption problem because it takes so much to understand and set it up right, those that cant access an expert cannot adopt it. With claude/chatgpt everyone has access to that expert as long as you give it the abilities, so sorting this could be very good for your business.

27

Could you describe the this case? Templates can be saved in the Custom tab and will be visible to all workspace users and your personal templates will be visible only to you.

28

Hi! I am the dev responsible for MCP. Here are some comments regarding the things You mentinoed in order:

  1. Backlinks - Agreed, and improving interaction with rich-text has a very high priority for us. Right now it’s a pain, and we are actively working to make them better.
  2. File attachments - it’s working for text/images natively (meaning, an agent can see the content right away after calling download_file tool. For PDFs, we return a link that is publicly accessible for a short period of time and which Claude/GPT can download. The reason they are not returned as raw file contents is limitation of how Claude Desktop client works with non-text/image files. They don’t render the content of PDFs to the model if PDF file is returned via MCP tool response.
  3. Permissions - reading “What do I have permissions to do and why” is coming soon (probably this week). Setup of permissions comes later, but it’s not a priority
  4. Create reports & embed views - MCP already can create Embed views. The support of reports generation may come later (it’s tricky to trasfer this ability from our Internal Agent to MCP)
  5. Manage entity views and relation views - agreed, it wasn’t on our radar at all. Not sure when support of these will be added
  6. Workspace analytics - in case You meant asking AI things like “How many syncs/automation runs I have” - agreed as well. Was not on our radar as well just yet.
  7. Automations - You may remember we actually had an Automations agent in Fibery. However, we had to sunset it due to very inconsistent results producted by this agent. In general, it is the hardest part of Fibery to automate with agents. Hopefully, we will be able to add this ability back to Internal Agent and MCP in the near future.
  8. Sidebar management - agreed. In more general case, it would be nice to make our AI aware of order of the things (fields, fields on views, etc). Right now it sees list of fields/dbs/spaces, but it cannot re-order things in sidebar or views.

I would like to thank You for Your time, and for the feedback - it’s very useful. We appreciate it a lot! :heart_hands:

1 Like
29

“Automations - You may remember we actually had an Automations agent in Fibery. However, we had to sunset it due to very inconsistent results producted by this agent. In general, it is the hardest part of Fibery to automate with agents. Hopefully, we will be able to add this ability back to Internal Agent and MCP in the near future.”

I’m not sure if it helps, but N8N actually does a good job of this. Not sure if there’s any insights that can be gleaned there? We use ChatGPT and N8N (Set up and use n8n MCP server | n8n Docs) to design, implement, and patch/update N8N workflows (especially ones that work with Fibery). It works really well and has started unlocking a number of connections that we didn’t have the time to implement before.
I also recently found this, which could also possibly give some insights: n8n-as-code - Manage n8n workflows as code with version control and AI assistance | n8n-as-code

1 Like
30

Thanks Max, a few clarifications:

  • Workspace analytics: I meant something different from sync/run counts: per-view usage telemetry (last opened, how often, by whom; plus last-modified and created-by). The use case is hygiene: we’ve got 1,840 views, ~53% auto-named clutter, and an agent can only guess which are dead without a usage signal.
  • Permissions: reading “what can I do” is a start. The bigger unlock for us is reading effective access for any entity/user (the “shared with…” audit) and setting up access, so an agent can finish setting up a user or database end-to-end rather than hand it back to a human.
  • File attachments: reading works well for us the BIG GAPS are uploading file bytes (currently only from a public URL) and OCR/transcription for scanned PDFs/images/audio/video.
  • Automations: totally understand sunsetting an agent that designs automations. What we’d really value is deterministic MCP access: read the automations that already exist (avoid dupes, document them) and create ones from an explicit spec.
  • Entity/relation views + ordering: thank you for adding these i’d say they were high priority along with the workspace analytics in order for claude to act as an expert fibery solution architect (and therefore unlock growth for you)
1 Like
31

+1 to pushing MCP further - it’s our main way of building with Fibery. Two things at the top of our list:

1. Read/write automation rules, buttons and their scripts via MCP. Right now MCP/API can’t see any automation logic, we can create entities and edit data, but the agent is blind to the rules and scripts that actually drive the workspace

2. Create/clone views via MCP with full filter + color-coding config. create_view exists, but it can’t set filters or color rules. Our use case: we have ~10 departmental boards with near-identical structure, and we’d love to build a view once - with its filters and conditional color coding and have the agent replicate it across the other DBs, preserving every filter and color setting. Today it’s all manual, board by board.

Thanks!

1 Like
32

Sounds like the perfect job for smart folder context views, no?

1 Like
33

@maxdubakov it is not possible to create embed views using MCP as you suggest. I tried for an hour with claude. Here is it’s writeup of the problem:

What we are trying to do

We run the Fibery MCP server with Claude so our team and our AI tools build and maintain our company guides directly in Fibery. Fibery is our source of truth, and our working principle is that the documentation is the product. We want an AI agent to author a guide end to end, including a live embedded database view inside the guide body (the thing the editor inserts with << / Insert View), with no manual step left for a human.

Today it cannot, and we would like your help to close the gap.

What we tested (2026-06-25)

  1. create_view works well through the MCP. We created a filtered, sorted grid on one of our databases and got back its view id and URL.
  2. The document write tools, set_document_content and append_document_content, accept Markdown only. The read tools, get_documents_content and fetch_by_url, return Markdown.
  3. We tried three ways to place that created view into a guide body through the document API:
    • a bare view URL,
    • a Markdown-wrapped view URL,
    • the <div data-view-id="..."> node form the editor stores a << embed as.
  4. All three round-tripped as plain text or a plain link. The div came back, and rendered in the UI, as literal text. None became an embedded view. We confirmed this in the Fibery UI.

Conclusion: embedding a database view in a document is currently possible only by hand in the editor. An agent cannot do it through the API or the MCP.

Two problems this creates for us

  1. Creation gap. An agent cannot insert an embedded view at all, so any guide that should show a live view needs a manual editor step we are trying to remove.
  2. Preservation gap. This one bites even when a human adds the embed by hand. Because the read tools return Markdown with no representation of an embed node, when an agent later edits the same guide with set_document_content (a full-document write), the human-added embed is silently dropped. As things stand, embedded views and agent-maintained guides are incompatible.

What we would need

Either of these helps. Both together would let an agent build and maintain guides containing live views with no manual step.

A. A first-class way, callable from the MCP, to insert an existing view (by view id) as an embedded-view node into a Rich Text / Document field at a chosen position. For example a dedicated tool:

embed_view_in_document({ database, field, entityId, viewId, position })

or an option on create_view that targets a document, or support in set_document_content / append_document_content for an embed token.

B. Lossless round-tripping of embed nodes through the document tools.

  • get_documents_content should serialise an existing embedded view to a stable, machine-readable token (for example a fenced block such as ```fibery-view\nviewId: <id>\n``` or an HTML-comment directive), and
  • set_document_content / append_document_content should accept that same token and recreate the node.

This closes the preservation gap, so an agent can read, keep and reposition embeds it did not create, rather than deleting them on the next edit.

A related nice-to-have

A portable serialisation (B) would also help downstream consumers of a shared Fibery document. We read these guides in Anthropic’s Cowork, where an embedded view currently renders as nothing. A stable token would at least tell the consumer what is there, so it can render the view or degrade gracefully to a labelled link, instead of showing a blank gap.

34

I think there has been a misunderstanding of the terminology.
An ‘embed view’ is a sidebar view that allows you to display something from an external source, e.g. a YouTube video.
This is not the same as an ‘embedded view’ which is a regular Fibery data view displayed inline within a rich text field (or a document).
AI should be able to create the former, but not yet the latter.

35

Can you add the latter asap with the other mcp requirements then please

36

Now you can upload videos to whiteboards

1 Like
37

We’ve updated the whiteboard behavior in dark mode, so the issue shown in your video no longer happen.

38

Looks much better, thanks Alex. I noticed the size of the arrow heads has been reduced also, which I think is a great improvement. Thanks for being so responsive to feedback. Great dev team.

1 Like