Rootr User Guide

Rootr is a "document tool that your AI writes alongside you." So the very first thing to do is connect your AI to Rootr. There are three ways in — you do not need all of them, just pick one.

This is the non-developer route. No install, no terminal, no config files. Claude and ChatGPT both connect with this one address:

1. 1

   In your AI's settings, open Connectors → Add custom connector.

   Paste the address above into the address field.

2. 2

   A Rootr screen opens in your browser: log in and press Allow.

   This is where you pick the workspace to connect and a permission level (read-only / read + write).

3. 3

   Rootr tools appear in your AI — that means it worked.

   Try asking: "What documents are in my workspace?"

A screenshot-by-screenshot guide to connecting Claude and ChatGPT →

Rootr builds the settings you need for the connection automatically. All you do is copy them and paste them into your AI.

1. 1

   Open Settings from the left-hand menu, then click the Integrations tab.

2. 2

   Under "AI agent integration (MCP)", press the Create MCP key… button.

3. 3

   Give the key a name, choose how much access to allow (permissions), and press Create.

   Pick a name you will recognize later — for example, "Claude on my laptop".

4. 4

   A configuration with your key (API key) already filled in appears in the code box below.

5. 5

   Press the copy button that matches the AI you use, and paste it in as the tabs below explain.

If you are comfortable with development and want to manage config files directly, add it as shown below. This is a setting that tells your AI to "run a small program (rootr-cli) that connects to Rootr." Put the key you made above into ROOTR_API_KEY, and your workspace id into ROOTR_WORKSPACE.

For Claude Code, put this into the ~/.claude.json file; for Claude Desktop, put it into the mcpServers part of the claude_desktop_config.json file. If you installed rootr-cli globally on your computer, you can shorten command to "rootr" and args to ["mcp"].

A CLI (command-line tool) is a way to work with Rootr by typing commands into a black terminal window. It is handy when a person works directly without an AI, or when you put it into a script that runs automatically at a set time. Try running the commands below in order.

• How to write paths: if it starts with a slash (/), it is read as a "folder path"; otherwise it is read as a document's unique number (id). Rootr figures this out for you.
• We recommend "append": it only adds to the end of a document rather than rewriting the whole thing, so it never conflicts even when other people or other programs edit at the same time.
• Deleting moves the document to the trash, so it can be restored. After 30 days it is removed for good.
• If you need a line-by-line explanation, type rootr --help and the usage appears.

If you are building your own program, you can call Rootr with an internet request (HTTP) from any language. The address is https://rootr.io/api/v1, and with each request you carry your key in a label called x-api-key. Below are examples you can try right away in the terminal.

It is fine if you do not know exactly what each command means. The point is that you "carry your key in the header and send a request to the address." You can find the complete list of every request you can make in the technical document (OpenAPI) linked from ⑩ Reference.

There are two kinds of keys, and they differ in how wide a range they can open. Each key also carries a set of permissions (scopes) that decide "how much it is allowed to do." Allowing only as much as you need is the safe choice.

• Examples of permissions (scopes): docs:read (read documents) · docs:write (edit documents) · graph:read (browse knowledge) · ask (ask questions) · webhooks:manage (set up notifications). If you only want it to read, turn on docs:read alone.
• The principle: for most connections, a workspace key is enough. An account key has broad permissions, so use it only when you truly need it.
• To move between work rooms: a workspace key does not open anything outside its own room. For the AI to switch with rootr_use_workspace, use an account key, or issue one key per room and register them with rootr config --add-key <key>.

Once connected, you just tell your AI in plain language ("summarize this document and add it below"). For results that are safer and more accurate, have it follow the points below.

• For adding content, have it use "append" first, and for partial changes, "find and replace" (edit). The approach of rewriting the whole document can accidentally erase existing content, so use it only when it is truly needed.
• When building a workspace from a structure up, have the AI plan first, ask a few questions, and only then create it (so it does not build blindly).
• If you have set the AI to receive change notifications (webhooks) again, have it ignore "changes the AI itself made." Otherwise you get an endless loop where it reacts to the very notifications it created.

Once connected, your AI can use the tools below. This is a table summarized by category; a detailed description of each tool is in ⑩ Reference. For now, just get a sense of "wow, I can have it do this many different things."

If you have several workspaces, you can move between them mid-conversation without reconfiguring anything — just tell the AI "switch to the sales workspace" (by name or by id).

• With an account key (PAT): you can switch to any workspace you belong to.
• With a separate key per workspace: register each key once (rootr config --add-key <key> --label "Sales") and the right key is selected — and remembered — whenever you switch.
• A remote connector (the paste-a-URL option) stays bound to the single workspace you approved, by design. Issue another connector for another workspace.

Only reads, searches, and questions count against a limit. Writing documents and uploading files never do (they are bounded by storage instead).

• At 80% used, your AI tells you how many queries are left today — so you are never cut off mid-task without warning.
• When the quota runs out, your AI reports it and points you at the upgrade page. It refills at midnight.

If Rootr is new to you, just follow this order. No development knowledge is needed.

2.1 Sign up and log in

• You can sign up with an email and password, or start in one click with a Google account.
• The first time you log in, you see a prompt: "Create your first workspace." A workspace is your own space that holds documents and folders.

2.2 Creating documents and folders

On the left of the screen is a tree (a list that unfolds like branches). Here you create folders to organize things and create documents inside them. Think of it just like the folders and files on your computer.

2.3 Building it all at once with "Create with AI"

You do not have to build everything piece by piece from a blank screen. Write in one sentence "what you want to do" (for example, "make me a space to prepare a new product launch"), and after asking you a few questions, the AI automatically builds a ready-to-use structure complete with folders, documents, and tables.

When you save a document, its contents are automatically organized into a "knowledge graph" in the background (details in chapter ⑥). Then go straight to chapter ① and connect your AI — that is where the real power of Rootr begins.

Rootr documents are made of pieces called "blocks." A heading, a paragraph, a list, a table, an image — each is a block. You can drop them in wherever you like and reorder them, which makes writing far more flexible.

• Real-time co-editing: even when several people open the same document and edit it at once, everyone's changes show up instantly. You can also see who is looking at what.
• Version history (an automatic save log): every time you edit a document, its previous state is saved automatically. Even if you delete something by mistake, you can roll back to an earlier version (the clock icon in the top right).
• Special blocks: you can add highlight boxes (callouts), tags (labels), and mermaid diagrams — pictures like flowcharts drawn with code. Even when the AI writes a document, it draws these diagrams automatically.
• Content added from outside shows in real time too: when an AI or a program adds text to a document via the API, it appears right away on the screen of whoever has that document open.

Below is the version history screen. The moments you edited the document remain as a list, so you can check or roll back to the content at any of those points anytime.

What "/" inserts

Type / on an empty line and the block menu appears. It searches in Korean too, so /토글 finds the toggle.

An embed card previews the first rows of a table, the top-left cells of a sheet, or the slide count of a deck. Anything you cannot open normally will not open here either — embedding never widens permissions.

Comments and subpages

• Comments: select a paragraph and comment on it. @name notifies that person.
• Subpages: right-click a document in the tree and choose "New subdocument" — it nests under that document. Tables can hold subpages too.
• Read receipts: for announcements that must be read, name the audience and Rootr shows how many have.

"Node" is the word for each item that goes into the tree (the list on the left). A document is a node, a folder is a node, a table is a node. Rootr has several kinds of nodes, as below, and you pick the one that fits what you are trying to do. First, here is the whole picture at a glance; then we explain the important ones one by one.

DATABASE (table) — a list with a defined format

Think of it as a spreadsheet table crossed with a structured database. For each cell (column) you set a format — "this column is text, that one is a date, this one is a status (a choice)." You can look at the same data in four ways — as a table, as a kanban board (where cards form columns by status), as a calendar, and as a timeline. You can add and edit rows both on the screen and by asking the AI to do it.

Clicking a card opens the row on the right, where you can write a detail note under the properties. That note is a document of its own beneath the table, so your AI can write it too — pass body when it adds or updates a row.

Columns the server fills in — always right, never edited by hand

These columns hold facts, not values you type. The server recomputes them on every read, so they cannot drift and nobody can edit them into disagreement with reality.

Formulas support if, concat, round, min, max and dateBetween (days between two dates), among others — for example if(dateBetween({Due}, now()) < 0, "overdue", "on time"). IDs are never reused: the TASK-42 you talked about yesterday must not point at a different row today.

Locking a table (Notion has no equivalent)

The "Permissions" button above a table gives you three locks. None of them apply to managers, and a table you never configure behaves exactly as it did before.

• Only managers change columns and views: editors still fill in rows. Stops someone deleting a column everyone depends on.
• People only see rows they created: for applications or report boxes where submissions must stay private. Managers see everything.
• Columns only managers can edit: approval flags, final scores — the cells that must not move.

Putting other things inside a document (wider than Notion)

Notion lets you embed a database in a page. Rootr lets you embed a table, spreadsheet, deck, whiteboard, form, recording or issue tracker — because a meeting note is more useful when that meeting's recording, decision table and deck are on the same page.

Type "/" in a document, choose Embed, and search by name. The card previews the first rows of a table, the top-left cells of a sheet, the slide count of a deck. Anything you cannot open, you cannot embed-preview either — embedding never widens what someone can see.

The same menu adds a Table of contents (built from the document's own headings) and a Bookmark (a link shown as a card instead of a bare URL).

WHITEBOARD · PRESENTATION · FORM

• Whiteboard: a wide canvas where you draw freely with shapes and connectors. Great for structure diagrams or organizing ideas.
• Presentation (PRESENTATION): where you make slides. The "text" you write in a slide's title, body, and notes is linked automatically into the knowledge graph, so always write important content as text, and add descriptions (captions) to images.
• Survey/form (FORM): a form for requests and surveys. Members can fill it in inside the workspace (a leave request, say), and you can also send it as a link to people outside. Responses are gathered automatically into a table (DATABASE), and each person sees only what they submitted.

Ask the AI to "draw this as a diagram and put it on a slide" and it picks the right one of five kinds — architecture, workflow, sequence, data flow, or lifecycle — and draws it in. The drawing survives export too: it appears in the PDF and PPTX, not just on screen. Text inside the drawing is not searchable, though, so keep the important points in the slide title and body as well.

SIGNED (signed document) — approvals and research notes in one

It looks like an ordinary document, but the moment you press [Submit] the body freezes. After that nobody can change it — not on screen, not through AI, not by restoring an old version. The people on the approval line sign in order, and every signature carries a timestamp from an outside authority plus a hash that links it to the signature before it. So months later, "is this really what it said back then?" is answered by one screen instead of an argument.

The three things a Korean national R&D electronic research note must have — ① an electronic signature ② an automatically recorded time ③ a tamper check — are exactly these three. Approvals and research notes are not separate features here, because they do the same job. A document that carries a signature cannot be deleted (30-year retention); deleting the folder it sits in is refused for the same reason.

• Create: [New] in the tree → "New signed document". Edit the body normally until you submit.
• Who signs: add them in order in the signing panel on the right. For a research note, picking just the reviewer (the principal investigator) builds the two steps — author, then reviewer — for you.
• Signing: pressing [Submit] mails you a 6-digit confirmation code. A code, not your password — people who signed up with Google have no password at all.
• Sending it back: reject it with a reason and the document unlocks so the author can fix it.
• Changing a signed document: you do not edit it, you create a revision. The original stays, marked as superseded — the guideline requires both the correction and the original to remain visible.
• Proof: [Show verification] recomputes the body hash, every signature, every timestamp and the ledger links, and shows the result. Print it for submission.

You get an email when it is your turn. The moment the person before you signs, the next signer receives a "please sign" mail whose link opens that exact document. There is no separate queue to check — open the document and sign from the panel on the right.

Getting a signature from someone outside your company

When you add a signer, enter just an email address and that person needs no Rootr account. On submit a link is mailed to that address; opening it lets them read the document and sign right there. Use it for agreements and change orders with a client or supplier.

• The link alone signs nothing. It only lets them read. Signing still needs a 6-digit code sent to that same mailbox, so a forwarded or leaked link is not enough.
• Other signers' addresses are masked on that page (ki*@corp.com), so a signing link never becomes a contact list.
• The link opens that one document and nothing else in the workspace.
• They can send it back instead — with a reason, which unlocks the document so you can fix it.

When every signature is in, a PDF copy is mailed out automatically — to the outside signer and to everyone on your side who signed. The copy carries the body, who signed when, the content fingerprint (hash), and the address where anyone can check later that it is genuine. Print it and file it as is.

Open a DATABASE row and choose signed document and that row becomes a record with signatures and timestamps. Use it for experiment logs and inspection registers — tables where one row is one record that has to be signed. To make a whole table work that way, ask your AI for it (that becomes the table default). Rows whose page is already signed cannot be deleted.

AI can drive all of this — creating the document, building the approval line, listing what is pending, verifying integrity. The one thing it will not do is sign for you. The confirmation code goes only to a person's mailbox, and that code is the only evidence a human pressed sign; AI asks you for the six digits instead.

ISSUE_TRACKER (issues) · LOG (data records)

• Issue tracker: turn each bug or task into an "issue" and track it with a number (#1, #2…), a status (open/closed), labels, an assignee, and comments. It works the same way as the issues in a development-collaboration tool (GitHub).
• LOG (data logbook): a place to put records that pile up over time (for example, server response times or incident events) in a defined format. When you use a "relation" column here, a "data lineage" is created automatically, tracing where each record came from (chapter ⑦).

A Rootr table is a spreadsheet and a Notion database in one. Give each column a type and every cell gets the right editor — a date picker, a status pill, a member picker — and wrong values simply cannot be entered. Create one from the ＋ next to "Documents" in the sidebar → New database.

Adding a column — twenty types to pick from

The ＋ at the far right of the header row opens the new-column dialog in the middle of the screen. Pick a type on the left; fill in only what that type needs on the right. There are twenty types, so a search box filters them, and each carries a one-line description. On a phone the dialog rises from the bottom as a sheet and moves to a settings step once you pick a type.

Types come in two groups. You fill in the first group; the second is filled in by the server and cannot be edited, which is exactly why it never drifts.

Formulas — nothing to memorize

Pick the formula type and the available functions appear under the input with a description and an example. Start typing a name and the list narrows; click one and the parenthesis is inserted for you. Type { and this table’s own column names appear, so you never have to transcribe them. Unknown functions and unknown column names are flagged before you hit save.

Formulas stay live: change an input column and the result follows immediately. Tables imported from Notion carry the formula definition, not a frozen number, so rows added after the import compute too.

Relations and rollups

A relation column points at rows in another table — give each task a "Project" relation and every task knows which project it belongs to. Then a rollup column on the project table gathers the linked tasks: count them, total an amount, average a score, or show the percentage checked. Edit a linked row and the rollup follows.

A rollup needs a relation first. Pick rollup on a table without one and Rootr says so and offers to create the relation right there.

Six views over the same rows

Add a view with the ＋ next to the view tabs. Views never copy data — they show the same rows differently, so an edit anywhere lands everywhere.

Dragging a card to another column saves that status immediately. Turn on grouped mode and many options collapse into the three stages, which keeps a wide board readable. The choice is remembered per table.

Each view keeps its own filters, sort and visible columns. Filters narrow the rows (the button shows how many are active), the properties menu hides columns from this view only — values are never deleted — and clicking a header sorts. The active view is kept in the URL, so a refresh returns to it and a shared link opens it.

Row detail — a document under every row

Open a row and a panel slides in from the right: column values on top, a body note underneath. That note is the same block editor as a normal document, so it takes lists, tables and images, and it joins the knowledge graph. Agents can write it too when they create or update a row.

The detail does not have to be a plain document. Open a row that has nothing attached yet and the right-hand panel offers eight choices — document, signed document, spreadsheet, whiteboard, deck, recording, form, issue tracker — and one click creates it. Each row can be a different one, so one meetings table can hold recordings of the meetings alongside circulars that went out for signature. Documents are written right there in the panel; the rest open in their own screen.

You can also attach something you already wrote — "Link an existing page" in the same panel, found by name. Do not copy and paste it in. A linked page stays where it is and the row just points at it, so deleting the row later leaves the page alone. To detach, use "Unlink" in the row menu — that does not delete the page either.

Ask your AI for "a meetings table where every row is a recording" and the table gets a default. In such a table the default choice is marked "default" in that panel — and you can still pick something else for one row.

Select many, change many, delete many

The box at the left of a row selects it; the box in the header row selects every row currently visible (only the filtered ones, if a filter is on). Shift-click extends the selection from the last row you picked.

A bar appears at the bottom showing how many you picked, plus Change date and Delete. If the table has a date column, choosing one date moves every selected row to it. Delete asks once and is all-or-nothing — if even one row is already signed, nothing is deleted and you are told which row blocked it. A batch never half-succeeds.

Three locks Notion does not have

Open the padlock "Permissions" button above the table. None of the three applies to managers, and a table you never configured behaves exactly as before. Each is enforced on the server, not just hidden in the UI — calling the API directly does not get around them.

• Only managers change columns and views — editors do not even see the add-column or add-view buttons. Nobody deletes a column someone else built.
• See only your own rows — for application forms and report boxes where submissions must stay private. Other people’s rows never appear in the list.
• Manager-only columns — lock just the approval flag or the final score. Locked columns show a padlock in the header and cannot be typed into.

Notifications — tell the right people (Notion cannot)

The bell-shaped "Notifications" button above the table holds the rules. When a row is added, changed or deleted, the people you named get notified. In Notion each person has to turn on watching for themselves, which means the owner of the work has to think to open that table first — no good for application forms, report boxes or incident logs where the responsible person is fixed.

• Who — any workspace members, as many as you like.
• When — row added, row changed, row deleted.
• Only when — pick a column and a condition: status equals urgent, title contains outage, owner changed.

Working together

• Live updates — when two people have the same table open, one person’s edit shows up on the other screen without a refresh. So do new rows, deleted rows and new columns.
• Simultaneous edits are safe — one person changing the assignee while another changes the status keeps both changes.
• Assignment notifications — filling a person column pings that member.

Other ways to work with a table

• Reorder columns by dragging a header, or from the header menu. The title column moves too.
• Collect through a form — point a FORM at this table and outside submissions arrive as rows.
• Ask an agent — "add a row", "move it to done" (chapter ①).
• Export to .xlsx.

When you use it as a team, the most important thing is "who can see how much." Rootr handles this very simply.

Roles (permission tiers)

• Owner: manages everything in the workspace. Admin: manages members and settings. Member: creates and edits documents. Viewer: can only view.
• Permissions are inherited automatically from a folder to the documents inside it. In other words, set permissions once on a folder and they apply to everything within it. You can also make a specific document an exception and set it separately.

Private · shared · public

• Private nodes: turn on the "Invited people only" switch and you can hide a document/folder you created so that only you (and the people you invited) can see it.
• Invite by share link: send a link to invite people from outside the workspace.
• Public publishing: you can make a specific document viewable by anyone at an internet address (/p/document-name). Outsiders can propose edits to a public document ("how about changing it this way?"), and the owner can accept (merge) or reject those proposals — just like collaboration on documents (Git).

Not just documents — publish anything

Tables, spreadsheets, whiteboards, forms, issue trackers, logs, CRM and recordings can go public too (only folders cannot). Publish a table and visitors can search it and press "clone" to take it into their own workspace — as a real table, columns, views (kanban included) and rows intact.

You choose whether sub-pages go with it. Turn it on and everything underneath — grandchildren included — gets its own URL and is listed on the parent page. Turn it off and only the pages that went out because of it close; anything you published separately stays. Closing the parent, moving a sub-page out, or deleting the parent do the same. Moving something INTO a published page does not publish it.

Some things never go out: a table's person, attachment and relation columns, the documents attached to its rows, form responses, recording audio, CRM contacts and deal amounts, and signer names on a signed document. Past 500 rows the page shows what it can and says how many of how many.

A published table is not stuck looking like a table — nine ways to show it

Publish a table and you choose how it is shown. The data is unchanged; only the presentation differs. Table (every column as-is) · Cards (a grid you skim) · Gallery (big tiles — colour stands in when there is no photo) · List (reads like articles: big title, one-line summary) · Board (kanban by status) · Timeline (a vertical run in date order) · Calendar (a month grid) · Summary (count bars plus sum, average and max) · Ranking (largest numbers first).

Each view needs a certain column — calendar and timeline need a date, board needs a select/status, ranking needs a number. On a table without it the option is dimmed and says why. You never pick a view and land on an empty page.

There are six moods too — Clean, Paper, Dark, Vivid, Bento, Brutal. Background, cards, corners and type all move together, so the same table reads as a completely different page. Layout and mood are stored separately, so changing the colour leaves the layout alone. You pick both under Share → Publish to web.

Publishing to the web — what you can set

Share → Publish to web gives the document a stable address. The public page serves the content as of the moment you published — later edits stay private until you press "Republish", so you can keep polishing a draft without it leaking.

A locked page never sends its body to the browser at all — hiding it in the UI would leak everything to anyone who called the address directly. Change the password and anyone already inside is locked out again.

Change proposals — Git-style collaboration for documents

With proposals allowed, the public page grows a "Propose a change" action. An outsider edits and submits; the owner gets a notification and reviews it under "Review N proposals" in the share window, then merges or rejects (rejection reasons reach the author).

Merging combines, it does not overwrite. Rootr takes the version the proposer was looking at as the base and lays only their changes on top of the current document, so anything the owner changed meanwhile survives. Only when both sides touched the same lines does it stop and say "N conflicts" first.

What is a knowledge graph?

When you save a document, Rootr automatically extracts the "important things" and "relationships" inside it in the background. For example, it finds people, teams, services, systems, incidents, and decisions, and creates connections like "this incident happened in that service." A map connected this way, with dots (things) and lines (relationships), is called a "knowledge graph," or in plain terms a "knowledge map." Several scattered documents become one connected picture.

• Mini-map: open a single document and you can immediately see, as a small map, the things that document mentions.
• Exploring the whole map: on the graph screen you can search for a specific thing, see what is connected around it, and follow what paths exist between two things.

Ask — asking "why?" (root-cause analysis)

When you ask the Ask feature a question in everyday language (for example, "why has payment kept failing since last week?"), Rootr searches both the knowledge graph and your documents and gives you an answer with the evidence attached (which sentence of which document it came from). It is especially strong at root-cause analysis (RCA) — tracing "what the cause is." You can ask the same question through the CLI or API ask you learned about earlier.

What is a LOG (data logbook)?

A LOG is a special table that holds records piling up over time. What sets it apart from an ordinary table is that you set "the format of each column" before you put anything in — this column is text, this one is a number, this one is a severity (info/warning/error), this one is a timestamp, and so on. It then filters out odd values that come in and automatically flags values that differ greatly from the norm (outliers). It is great for recording things like server response times, incident events, or job-processing counts.

What is "lineage"?

Lineage (data lineage) is the connection of "where this data came from, and what came from it here." Picture a family tree and it becomes easy. When you use a "relation"-format column in a LOG, one record points to another, and the moment it does, a lineage line is drawn automatically between the two. That way you can later trace, as a picture, "what earlier event was the cause of this incident?"

• How to put data in: it supports on-screen entry, file upload (CSV/Excel), and even real-time sending from a program or sensor.
• Automatic connection: put a value in a relation column and a lineage line appears on its own. There is nothing to manage separately.
• Statistics: you can see summaries like count, average, and maximum, by time and by item.

What is a webhook (change notification)?

A webhook is a feature that "automatically tells another program you have designated whenever something happens in Rootr." For example, "when a document in this folder changes, send a notification to our team chat." It lets things react to change without a person constantly watching.

• Narrowing the scope: instead of the whole workspace, you can limit it to a specific folder or document, or filter by tag (label) so you are only notified about what you want (a parent folder's tags apply inside it too).
• What changed: it is categorized as document / comment / system, and it sends only "the part that changed (the diff)" rather than the entire content, which is safer.
• Signing key: a key that verifies the notification really came from Rootr is issued once, at creation time. Store it on your receiving server.

The issue tracker also updates the screen in real time (SSE) and can connect to outside systems in both directions. If you set the CLI/AI connections you learned earlier to run automatically at set times, you can build automatic flows too, like "when a document changes → the AI appends a summary."

• Using several accounts at once: like a company account and a personal account, you can be logged in to several accounts together and switch between them with a click.
• Plans: a mix of number of people (seats) · storage space · AI usage. AI features can be used up to a set amount of "graph credits" per plan. Check the exact prices and what is included on the Plans page. You can start free for up to 3 people.
• Import: you can bring documents that were elsewhere into a workspace. Notion (an exported ZIP or an integration token) and Confluence Cloud (site address, account email, API token) are supported, and the folder structure, attachments, and links between documents all come across. The token is used for that one import and is never stored.

This is a collection of reference material for people building their own programs. If you only use Rootr through the screen, you can skip this chapter.

• Full REST API specification: a document listing every request you can make in a machine-readable format — /api/api-docs-json.
• GraphQL schema: the full structure of another way to query — /api/graphql/sdl.
• Details of the 152 AI tools: the manual (README) for rootr-cli describes in detail what each tool does.

Common errors and how to fix them

Telling us what is broken or awkward

If something is broken or gets in your way, send it from wherever you are. No login and no API key are needed — it goes through even when your key is wrong. It never counts against your usage limit and spends no credits.

If you use Rootr through an AI agent you do not have to ask it to do this — connected agents are already told to report problems on their own, so when a tool behaves differently from its description or forces a workaround, the agent sends a report itself (rootr_send_feedback). Pick a kind — bug, friction, idea or praise — and identical reports sent within 10 minutes are merged into one.