Fibery

Enables comments on entities in one or more databases. Creates a "comments/comments" field automatically. Call `get_fibery_skill({skill: "schema"})` for the schema-building workflow. Prerequisites: `schema` to get database names.

create_comments_fields

Create an empty Fibery custom app from the starter template (no app code is generated). For the development loop call `get_fibery_skill({skill: "custom-apps-dev"})`. Examples: - "create a custom app 'Roadmap' in the Product space" → `{name: "Roadmap", kind: "view", spaceName: "Product"}` - "add an entity view / custom tab to Bugs" → `{name: "Bug health", kind: "layout", databaseName: "SoftDev/Bug"}`

create_custom_app

Issue a short-lived (~1 hour) access token for developing a custom app locally. The token authenticates only the app's `get-source-files` / `update-source-files` endpoints, passed as the `custom-app-dev-token` query parameter — see `get_fibery_skill({skill: "custom-apps-dev"})` for the full development loop.

create_custom_app_dev_token

Creates one or more databases within a space. Call `get_fibery_skill({skill: "schema"})` for naming rules and the auto-created system fields (do NOT add them manually). Prerequisites: `schema` to check existing spaces and databases.

create_databases

Creates entities. Handles primitive and single relation/select fields only — collections, `workflow/state`, and document fields have dedicated tools (error thrown if set here). Never pass arrays; pass a single relation/select as the bare id string. Objects are only for date ranges and locations. Call `get_fibery_skill({skill: "data"})` for field value formats and which tool handles which field type. Prerequisites: `schema` / `schema_detailed` to get database and field names.

create_entities

Creates one or more file attachment fields in databases. Each files field is a reference to the built-in fibery/file database. Call `get_fibery_skill({skill: "schema"})` for naming rules. Prerequisites: `schema_detailed` to check existing fields.

create_files_fields

Creates a formula field in a database. The formula expression is generated automatically from the provided description — be precise about the inputs and the expected result. Call `get_fibery_skill({skill: "schema"})` for naming rules and formula field semantics. Prerequisites: `schema_detailed` to see available fields in the database.

create_formula_field

Enables emoji icons on entities in one or more databases. Creates an "icon/icon" field automatically. Call `get_fibery_skill({skill: "schema"})` for the schema-building workflow. Prerequisites: `schema` to get database names.

create_icon_fields

Creates one or more multi-select fields with predefined options. Prefer selects to bare text fields. Call `get_fibery_skill({skill: "schema"})` for the option shape, colors, and naming rules. Prerequisites: `schema_detailed` to check existing fields.

create_multi_select_fields

Creates one or more primitive fields (text, number, checkbox, date, location, rich text) in databases. Avoid bare text fields — prefer select/relation fields, or a text field with specific meta (email, url, phone). Call `get_fibery_skill({skill: "schema"})` for the field type catalog with `meta` options. Prerequisites: `schema_detailed` to check existing fields — creating an already-existing field is an error.

create_primitive_fields

Creates one or more relation fields between databases. Each relation creates a field in BOTH the source and target databases. Call `get_fibery_skill({skill: "schema"})` for cardinality semantics and naming rules. Prerequisites: `schema_detailed` to check existing fields.

create_relation_fields

Creates a Fibery report with sources and a title. The report is placed in the user's private space unless `spaceName` is provided. The report is created with one default bar chart tab (count of records by creation date). Edit it in place with `update_dimension` / `update_tab`, or add the tab you need and then `remove_tab` the default one. Prerequisites: call `schema` to discover valid database names; call `display_report_schema` to discover field expressions before configuring dimensions. Reports are a specialized domain — call `get_fibery_skill` with `skill: "reports"` for the full report model, expression syntax, palettes, conditions, and workflow.

create_report

Creates a whole schema in ONE call: spaces, their databases, and every field kind (primitive, single/multi select, relations, files, workflow, comments, icon, avatars). Prefer it over the per-kind create tools whenever you create more than a couple of fields. Example: ```json {"databases": { "Work/Project": {"fields": {"Budget": "money", "Website": "url"}, "workflow": ["Planned", "Active", "Done"]}, "Work/Task": {"comments": true, "fields": { "Estimate": "int", "Priority": {"select": ["High", "Medium", "Low"]}, "Tags": {"multiSelect": ["UI", "API"]}, "Project": {"relation": "Work/Project", "back": "Tasks", "cardinality": "many-to-one"}, "Assignees": {"relation": "fibery/user", "back": "Assigned Tasks", "cardinality": "many-to-many"}, "Files": "files"}}}} ``` - Databases are keyed by "Space/Database"; missing spaces are created. Use `spaces` only to give a new space a description or color. - `fields` maps each short field name to a type name, or to an object for selects, relations, or a type with extra `meta` (e.g. `{"type": "money", "meta": {"ui/number-currency-code": "EUR"}}`). - Select options and workflow states can be plain names. Workflow state types follow position (first "Not started", last "Finished", others "Started") and the first state is the default; use a state object to override type, color or `default`. Use a workflow (not a select) for status. - Relations may point to databases created in the same call, to any database that already exists in the workspace (any space), or to built-in "fibery/user" for people. To link an existing database to a new one, add the existing database's key with just the new relation field. Declare each relation once, on one side; `back` is the field created on the target. Cardinality is read from this database: `many-to-one` means many of these link to one target (e.g. Task.Project), `many-to-many` means many on both sides. - Existing spaces, databases and fields with the same name are skipped and listed in `unchanged`, so sending the spec again is safe. To extend a database, send only what to add. Changing or deleting existing items needs the update/rename/delete tools. - The spec is validated before anything changes; every problem is returned at once. - Every database gets Name and Description fields automatically; do not add them. - Formulas are not supported here: create them afterwards with `create_formula_field` if needed.

create_schema

Creates one or more single-select fields with predefined options. Prefer selects to bare text fields; for status-like fields use `create_workflow_fields` instead. Call `get_fibery_skill({skill: "schema"})` for the option shape, colors, and naming rules. Prerequisites: `schema_detailed` to check existing fields.

create_single_select_fields

Creates one or more spaces in the workspace. Call `get_fibery_skill({skill: "schema"})` for naming rules. Prerequisites: `schema` to check existing spaces.

create_spaces

Creates a View in the Fibery workspace — a saved data visualization (grid, list, board, timeline, calendar, map, feed, gallery, gantt, embed), a form, a standalone document, or a whiteboard (canvas). **For anything more complex than a flat grid/list with no filters, no orderBy, no grouping, and no color coding — call `get_fibery_skill({skill: "views"})` FIRST.** That reference covers per-view-type config shapes, the FilterNode operator matrix, conditional color coding, multi-database axes, hierarchy via groupBy, dependency rules for timeline/gantt, form defaultValue formats, and worked examples. Skipping it on non-trivial views leads to invalid configs and retries. Prerequisites: call `schema` (and `schema_detailed` for field details) to discover database and field names. Trivial example — flat grid, no filter or ordering: ```json { "viewType": "grid", "name": "All Features", "config": { "items": [{ "database": "Product/Feature", "fields": [{"field": "Product/Name"}, {"field": "Product/Status"}] }] } } ``` Document view — no `config`. The view is created empty; its body is not set here. Edit the body separately with the document tools (`get_fibery_skill({skill: "documents"})`): ```json { "viewType": "document", "name": "Meeting Notes" } ``` Canvas (whiteboard) view — no `config`; the board is created empty. Only use it when a user asks to create a new Whiteboard. To work with it, call `get_fibery_skill({skill: "whiteboard"})` first: ```json { "viewType": "canvas", "name": "Sprint Retro", "description": "Retro board for sprint 42" } ```

create_view

Creates elements (shapes, text, links, sticky notes, sections, pictures, videos, freehand pen strokes) on a Fibery Whiteboard and returns a link to the whiteboard view. **Call `get_fibery_skill({skill: "whiteboard"})` first** — it covers every element type's full property set, the coordinate system, placeholder-ID resolution, and styling/placement conventions. Skipping it leads to invalid or overlapping elements. Element `ID`s may be placeholders you invent (e.g. `"node1"`) — they resolve to real numeric IDs automatically within the call, including cross-references between the elements you create (a Link's `points[].nodeID`, a label's `parent`, `sectionID`). The returned `idMap` gives you the real ID for each placeholder. Use those numeric IDs with `update_whiteboard_elements` and `delete_whiteboard_elements`; placeholder mappings are not retained across calls. Results reference Fibery objects by `url`: use it when referencing the object.

create_whiteboard_elements

Creates workflow (state) fields, one per database and several databases in one call, for tracking entity status through stages — do NOT use a single-select for status-like fields. Only ONE workflow field can exist per database; it is always named "workflow/state". Call `get_fibery_skill({skill: "schema"})` for option types, colors, and default option rules. Prerequisites: `schema_detailed` to verify no workflow field exists yet (otherwise use `update_workflow_fields`).

create_workflow_fields

Disables avatar/profile picture attachments on entities in one or more databases by deleting the "avatar/avatars" field. Restorable by the user via the Activity Log. Call `get_fibery_skill({skill: "schema"})` for deletion semantics. Prerequisites: `schema_detailed` to verify the avatars field exists.

delete_avatars_fields

Disables comments on entities in one or more databases by deleting the "comments/comments" field. Restorable by the user via the Activity Log. Call `get_fibery_skill({skill: "schema"})` for deletion semantics. Prerequisites: `schema_detailed` to verify the comments field exists.

delete_comments_fields

Deletes one or more databases from a space. Restorable by the user via the Activity Log. Call `get_fibery_skill({skill: "schema"})` for deletion semantics. Prerequisites: `schema` to get database names.

delete_databases

Deletes blocks from a document, each with all its children. Call `read_document` first to get block ids. Call `get_fibery_skill({skill: "documents"})` for the block model and the editing workflow. Delete a `table` only by the whole `table` block's id — `table_row`, `table_cell` and `table_header` CANNOT be deleted, adding/removing rows or columns is not supported. ## Example ``` { secret: "123", deletions: [{blockId: "456"}, {blockId: "789"}] } ```

delete_document_blocks

Deletes entities by their `fibery/id` values. Can be undone only by the user in the Activity tab (history icon at the bottom of the sidebar). Call `get_fibery_skill({skill: "data"})` for how to work with Fibery data. Prerequisites: `query` to find the entity ids.

delete_entities

Deletes one or more fields from their databases. Deleting a relation field also removes its paired field in the related database. Restorable by the user via the Activity Log. Call `get_fibery_skill({skill: "schema"})` for deletion semantics. Prerequisites: `schema_detailed` to get field names.

delete_fields

Disables emoji icons on entities in one or more databases by deleting the "icon/icon" field. Restorable by the user via the Activity Log. Call `get_fibery_skill({skill: "schema"})` for deletion semantics. Prerequisites: `schema_detailed` to verify the icon field exists.

delete_icon_fields

Deletes one or more spaces with all their databases. The built-in `fibery` space cannot be deleted. Restorable by the user via the Activity Log. Call `get_fibery_skill({skill: "schema"})` for deletion semantics. Prerequisites: `schema` to get space names.

delete_spaces

Delete Fibery Views by their IDs. The data present on the views WILL NOT be deleted. This action can be undone by the user via the Activity Log (by selecting the view and restoring it). Prerequisites: use `query_views` to find view IDs. ## Example ``` { "ids": ["123"] } ```

delete_views

Deletes elements from a Fibery Whiteboard by their numeric IDs (from the `idMap` of `create_whiteboard_elements`, or from `query_views` with `viewType: "canvas"`). Links attached to a deleted element, and their labels, are deleted with it. Also returns a link to the whiteboard view. Never delete the board itself (ID `1`). Results reference Fibery objects by `url`: use it when referencing the object.

delete_whiteboard_elements

Deletes the workflow (state) field from one or more databases. Restorable by the user via the Activity Log. Call `get_fibery_skill({skill: "schema"})` for deletion semantics. Prerequisites: `schema_detailed` to verify the workflow field exists.

delete_workflow_fields

Returns per-entity capabilities derived from sharing for the requested Fibery databases. Use this when the user wants to know what access they have at the entity level (not just space- or database-level). For each database, the response includes the entities they can reach and how they reach them. Three access paths are covered: 1. **Direct sharing** — the entity was explicitly shared with the user, returned in `entityLevelGrants`. 2. **Propagated sharing** — access was inherited from a related entity, returned in `indirectEntityLevelGrants`. 3. **Assignment rules** — the user appears in a People-field rule on the entity type, returned in `assigneeGrants`. Capabilities from every source (space-level, database-level, per-entity grants, propagation from other databases) ACCUMULATE — they NEVER override. To compute effective capabilities on a specific entity, take the UNION of all sources. Limitations for assignee grants: sample only (up to 10 entities per rule) Per-database result fields: - `spaceLevelCapabilities` — capabilities granted at the space level. - `databaseLevelCapabilities` — capabilities granted at the database level. - `entityLevelGrants` — per-entity grants from direct sharing. - `indirectEntityLevelGrants` — grants propagated from related entities. - `assigneeGrants` — grants derived from assignment rules on People-type fields. If a database can't be resolved in the schema, its entry is `{database, error}` instead.

display_entity_capabilities_via_sharing

Get the vizydrop report source schema for one or more Fibery databases. This is distinct from the Fibery type/relation schema returned by `schema` or `schema_detailed`. Returns the flat set of fields and enum values usable in report dimension/metric expressions and filter conditions. Call this before configuring chart, table, or metric dimensions so you know the valid field names and types. **`sourceMode`**: `current` (default) for live entity state; `historical` for modification events (time-in-state data). When multiple databases are specified, a synthetic `Entity Database` field is added to allow splitting results by source. Reports are a specialized domain — call `get_fibery_skill` with `skill: "reports"` for the full report model, expression syntax, palettes, conditions, and workflow.

display_report_schema

Returns the current user's access info per space and per database in the Fibery workspace. Use this when explaining what the user can/cannot do, or before suggesting an action that requires specific access. URL conventions: - For spaces: user will see anything if they have ANY access to the space. - For databases: user will see anything only if they have architect-level access; otherwise it will render as "No Access". Capabilities from every source (space-level, database-level, per-entity grants, propagation from other databases) ACCUMULATE — they NEVER override. To compute the user's effective capabilities on a specific entity, take the UNION of all sources. The response shape: - `accessInfo.spaces` — map keyed by space namespace. - `accessInfo.databases` — map keyed by `Space/Database` name. Each entry value is one of: - `'no-access'` — the user has no access. - `'entity-level'` — no space/database-level grant, but the user has access to at least one entity via an entity-level access template. - `{level, templateId, isDefault, url}` — standard template-based access. `level` is the template name with the `app.access/` / `type.access/` prefix stripped. `isDefault: false` indicates a custom template. - `'derived-per-field'` — applies only to `fibery/file` and `comments/comment`; access is granted via per-field grants on the owning database, not at the type level. - `levelInfo.space` and `levelInfo.database` — keyed by `level` (the same string as above); each value carries the template's full title, description, and capability set so the caller can explain what a level grants.

display_schema_capabilities

Fetches a Fibery file attachment by its `secret` and returns a signed download URL valid for ~60 minutes, along with file metadata. For small images and text-ish files, the file contents are also delivered inline so the model can read or analyze them directly without any extra step. The URL expiration timestamp is included in the response. ## What the model receives inline - **Images ≤ 5 MB, Text-ish files ≤ 256 KB**: included in tool's response (you should be able to see them directly) - **Everything else** (PDFs, Office documents, archives, larger files, or unsupported types): only the signed download URL is returned (which is valid for an hour). ## Prerequisites You must already know the file `secret`. Call `get_files_meta` with the entity ID to discover available files and their secrets. ## Example ```json { "secret": "<secret>" } ```

download_file

Fetches entity or view data from a Fibery URL and renders it as markdown. Accepts URLs in these formats: - Entity: `https://{account}.fibery.io/{Space}/{Type}/{Entity-Title}-{id}` - View: `https://{account}.fibery.io/{Space}/{View-Title}-{id}` Returns formatted markdown with entity fields, document content, or view data including a table of items. ## Examples ``` { "url": "https://myteam.fibery.io/Project_Management/Feature/My-Feature-42" } ``` ``` { "url": "https://myteam.fibery.io/Project_Management/Backlog-7", "limit": 50 } ```

fetch_by_url

Fetches actual entity data from a Fibery View by executing the view's query. This is different from `query_views` which returns view configuration. `fetch_view_data` executes the view's query against the database and returns the entities that the view would display, respecting the view's filters, field selection, and sort order. Prerequisites: call `query_views` first to find the view's publicId. ## Examples ``` { "publicId": "42", "limit": 50 } ```

fetch_view_data

Get a list of available connectors (built-in integrations) in Fibery. Fibery Connectors are built-in integrations that allow users to directly import or continuously sync data from external sources (like Trello, Notion, CSV files and others) into their Fibery workspace. Each connector has a name, id and abilities to import and/or continuously synchronize data. In case the user asks to import data from a source not yet supported, go for CSV option as default — offer to extract data from there and import in Fibery using CSV.

get_connectors_list

List the custom apps the user can see. Custom apps are small React apps. `kind`: "view" (App view in a space) or "layout" (Entity View tab on entity pages). Use the `id` to work on an app's source code with the custom-app development flow — call `get_fibery_skill({skill: "custom-apps-dev"})` for the full guide.

get_custom_apps_list

Displays Fibery databases schema with fields and related databases in YAML format. The structure is the following: ```yaml {space}/{database}: # Database description fields: {fieldName}: {fieldType} # metadata comments (collection, UI title, read-only, default value, etc.) values: # Only for enum types - id: {enumId} name: {enumName} color: {enumColor} icon: {enumIcon} ``` Metadata comments include: - collection: Field is a collection of references - UI title: Field is used as the display title - read-only: Field value cannot be modified - default: Default value for the field - dependency/dependency start: Field is part of dependency relationships - formula: Field is calculated via formula. Formula is always read-only - values: Available enum values (for enum fields) Use it to explore fields and relations of a database. Prerequisites: call `schema` first to discover available database names.

schema_detailed

Generates Fibery web links for entities based on their public IDs. Public IDs are human-friendly auto-incrementing identifiers (e.g., "42"), different from fibery/id UUIDs. You can get public IDs using `query` tool by selecting the "fibery/public-id" field. ## Examples ``` { "database": "Project Management/Feature", "entityPublicIds": ["42", "43"] } ```

get_entity_links

Builds a mention for an entity. Rendered by Fibery, it becomes a "live" mention: current name, clickable, and it survives renames. Never construct a Fibery URL instead. Use the returned string as-is in content passed to the document editing tools (`insert_document_blocks`, `set_block_text`, comment bodies). Call `get_fibery_skill({skill: "documents"})` for the markdown reference in documents. `entityId` is the fibery/id UUID. If you only have a public id (e.g. "42"), resolve it first: `query` the database for "fibery/id" where "fibery/public-id" matches. Works for meta databases too: pass `database: "fibery/view"` with a view id, `"fibery/type"` with a database id, or `"fibery/app"` with a space id to mention a view, database, or space. For automations pass `"fibery/automation-rule"` or `"fibery/automation-button"` with the automation id from `query_automations`. Fails when the object doesn't exist in that database or was deleted. Don't build the mention by hand then: find the right id, or tell the user. ## Example ``` { database: "SoftDev/Task", entityId: "b1f2a3c4-...", label: "Fix login bug" } ```

get_entity_mention