Stable Baseline

Get a task by ID with full details, evidence, activity, and the `checklist` array (each item: id, text, due_date, completed_at, plus server-stamped attribution). Returns versionTimestamp; pass it to updateTask to modify. Includes percent_complete for progress tracking. Also returns the work hierarchy: parentItem (the item this one belongs to, such as its epic or story: { id, friendlyId, title, type, status, isTask }, or null), children (the items that belong to it, in status order then by id, at most 200: each with ownerId, ownerTeamId and percentComplete) and childProgress { total, done, closed } over every child (closed counts done, rejected and deferred). Set a parent with parentItemId on updateImprovement or updateTask. Also returns linkedRecords: the database rows it links, each { linkId, databaseId, tableId, rowId, state, label, title, autoId, tableName, databaseName, href } read for you. state ok gives the row's title and a link to it; no_access means you cannot read that row, so no title is given; removed means the row, its table or its database was deleted. Change them with linkedRecords on updateImprovement or updateTask.

Get a single team by ID with profile-enriched member list (display_name, email, avatar_url, role, joined_at). Set `includeMembers=false` to skip the member fan-out and just return team metadata. Read-only.

Read the calling user's preferences. Self-only — no params required. Returns { notifications, grids } where `notifications` is the single notification-preferences row and `grids` is an array of per-grid view rows. Read-only.

Read a whiteboard: its metadata plus a summary of the canvas (element count, element types, and text labels on the board). Pass includeElements=true to also return the full Excalidraw scene ({elements, appState, files}) — needed if you intend to modify it and send it back via updateWhiteboardScene. FOR BEST RESULTS, also call getWhiteboardImage to render the board to an image and actually SEE it: the visual layout (positions, spacing, overlaps, colours, how shapes connect) is far easier to understand from the rendered picture than from the element list, so view it first to truly understand the board and to propose or verify edits accurately.

Get the Stable Baseline whiteboarding guide (Markdown): when to use stencils vs architecture icons vs code/BPMN diagrams vs plain shapes vs real images vs frames/presentations, how to lay out and verify a board, and how to edit a large board safely (patch by id, never replace). Call before authoring a non-trivial whiteboard.

Render a whiteboard to a raster IMAGE so you can SEE it and confirm your edits look right, then iterate — like taking a screenshot. Returns the rendered board as a viewable image attached to the result (always raster: a JPEG light variant and/or a PNG dark variant; there is no vector/SVG output, so for a vector export of a single diagram use getDiagramImage). Pass elementIds to render only specific shapes (e.g. to inspect one section/slide), region:{x,y,width,height} to capture an exact scene-coordinate window (e.g. the user's viewport), theme:'light' for the fastest single-variant render, or background to set the canvas colour. Unchanged boards return instantly from a content-keyed cache. Call this after addWhiteboardElements/updateWhiteboardScene to check layout, overlaps, labels and alignment before continuing.

Read a single workspace by id. Auth via the standard workspace-access ladder (credential org match + workspace scope + per-resource read permission). Returns the workspace's full record. Read-only.

Grant a team read/write/admin access to a workspace. Idempotent. Team and workspace must be in the same organisation.

Load a CSV, TSV or Excel file into a table: an existing table, or a new one (newTable) whose fields are made from the file's columns. For a small amount of data pass csv (text with a header row) and the rows are added at once. For a file, pass fileName (and sizeBytes): you get an uploadUrl; send the file's bytes there with an HTTP PUT, then call again with the importId, and again with each importId the answer returns, until status is done. Columns match fields by name; mapping renames or skips columns; createFields adds a text field for each column that matches no field. dryRun checks the file and the columns without adding anything. The organisation's plan limits the size of one import. getDatabaseGuide topic importing.

Insert a new diagram into a document. Call listDiagramTypes to find your type, then getDiagramTypeGuide for DSL syntax before writing diagramCode. The diagramCode is COMPILE-CHECKED BY RENDERING at write time: broken DSL is rejected with the renderer's error (fix and retry), and valid DSL is rendered + thumbnailed immediately so the document displays instantly everywhere. The response tells you what happened: diagram.renderStatus ('rendered' | 'pending_render' with renderError when the renderer was unavailable), plus fresh optimistic-lock tokens — document.versionTimestamp and diagram.versionTimestamp — so you can keep editing without re-reading. Always set prompt (and ideally nlDescription) to describe what the diagram shows. To SEE the result inline set returnImage:true, or call getDiagramImage afterwards; if it is wrong or ugly, correct it with updateDiagramInDocument (provide the full updated diagramCode).

Insert an image into a document (max 10MB). Provide imageBase64, imageBinary, or imageUrl. For large files, call createImageUploadSession first then use the returned assetUrl. nlDescription AND caption are both REQUIRED, not optional polish: they are what makes the image findable in search and what lets an agent decide whether this picture belongs on a slide or in an answer, since neither can see the pixels from a filename. Write them about what the image SHOWS.

Insert (or re-render in place) a real DIAGRAM (BPMN, Diagrams-as-Code / any DSL: mermaid, d2, plantuml, graphviz, …) on a whiteboard as an editable SB diagram element. Provide documentId, diagramType (call listDiagramTypes / getDiagramTypeGuide), and source (the DSL). The diagram is rendered to an image stored like a pasted image, and its editable source is kept in a sidecar so it stays a live, re-openable diagram (double-click on the canvas opens the BPMN / code / AI editor). Options: caption (label beneath it), width/height to size it (auto width caps at 480px; an explicit width may go up to 1200px), and x/y or align ('left'|'center'|'right') to place it (defaults to the right of existing content). Pass updateElementId to UPDATE an existing embedded diagram in place — re-render + replace its image and DSL while keeping the same element id and board position (used to live-edit a diagram as it evolves); if that id is not on the board yet it is created carrying that id. After inserting, call getWhiteboardImage to see it and verify it rendered correctly (fix the source and re-insert if it is wrong). For a plain picture (not a diagram) use insertWhiteboardImage; to generate a diagram image WITHOUT inserting use renderDiagram.

Insert a real IMAGE (photo, screenshot, logo, picture) into a whiteboard — the storage-backed equivalent of insertImageInDocument. Provide the image as imageUrl (fetched and re-hosted), imageBase64, or imageBinary; for large files call createImageUploadSession(documentId) first then pass the returned assetUrl as imageUrl. The bytes are stored in the document-images bucket and the scene only holds a reference (never base64), exactly like pasted images. Options: caption (a text label placed + grouped beneath the image), width/height in px to RESIZE (if only one is given the other follows a 4:3 ratio; ~360px wide if neither), and placement via x/y (top-left) OR align ('left'|'center'|'right', positioned just below existing content) — omit both to auto-place to the right of the current content. After inserting, call getWhiteboardImage to verify. To move or resize the image later, patch its element via updateWhiteboardScene (mode:'patch' with {id, x, y, width, height}). For curated software-architecture ICONS (AWS/Docker/etc.) use addWhiteboardElements with an {type:'image', iconPath} spec instead.

Invite a person by email to the credential's organisation. Auth: org id must match the credential AND credential must hold can_manage_members. Rate limit 10/h. Returns invitation_id, expiry, and a seat-billing-impact summary. Email-existence is opaque: the response shape never reveals whether the email is already a member, already invited, or new. Use when the user asks to invite a teammate, friend, colleague, or new user to their organisation, or to onboard someone.

Linked-mentions rail: every edge whose dst matches the named entity.

Check how well a set of kg_search results is backed by the knowledge graph before you answer from them. Pass the chunk ids kg_search returned. Each chunk gets a bucket: authored-grounded (backed by links people authored), extracted-high-conf or extracted-low-conf (backed by links inferred from text, with high or low confidence), or no-support (nothing in the graph backs it). Also returns the overall distribution, dominant_bucket, recommend_refusal and a short agent_summary. Use it to decide whether to answer confidently, add a caveat, or decline. It only reads stored information: no AI call is made, so it is quick and adds no cost.

Fetch a KG entity by id or name, with the entities directly connected to it. The response also carries `datedFacts`: what holds now about the entity by default, what held on a day with asOf, or the whole history with history:true, each fact with its dates, how it ended if it has, and the sources that state it.

Fetch the wiki page written for a community (a group of closely related entities in the knowledge graph), in CDMD markdown. Pass its slug or the communityId.

List the communities the knowledge graph has found in an organisation's content (optionally for one project). A community is a group of closely related entities; each comes with its id, title, summary and entity count.

Find other sources that share entities with the given source.

Check whether Knowledge Graph is in-scope for a given target.

FIND an artefact by its name, friendly id or uuid with artefactMetadataOnly:true. This works in every organisation, with or without the knowledge graph. Without that flag the tool ANSWERS questions from inside the content (facts, themes, relationships) through the knowledge modes below, which need the organisation's knowledge graph switched on: where it is off, those calls are refused with a message saying so. The knowledge modes will not reliably find a thing by its title. FIND (artefactMetadataOnly:true): matches title, friendly id and uuid, never document content, across documents, whiteboards, plans, tasks, improvements, compliance frameworks, databases and database rows that the caller can open and the organisation has switched on. Ignores `mode`. Narrow it with artefactTypes, projectId or workspaceId; page with offset. Returns { artefacts: [{ result_type, id, friendly_id, title, snippet, document_id, project_id, href }], total }. To search inside document bodies use listDocuments (full-content grep). KNOWLEDGE MODES (need the knowledge graph; pass projectId or workspaceId). PICK THE MODE THAT FITS THE QUERY: • mode='local' (default): for SPECIFIC factual questions ("what does section 15 say about deposits?", "who is the Chief Counsel?"). Searches individual passages of the content by wording and by meaning. Returns precise excerpts with citations. • mode='global': for THEMATIC / OVERVIEW / SUMMARY questions ("what are the main themes", "give me an overview of the project", "what topics does this cover"). Returns summaries of the communities (groups of closely related entities) found in the content, plus curated wiki pages. Far better than 'local' for big-picture queries, because each summary already draws on many passages. ALWAYS PREFER over 'local' when the user asks for themes / summary / overview / topic landscape. • mode='graph': for RELATIONSHIP questions ("what's connected to entity X?", "who cites Section 5?"). Returns the entities connected to the one you name, and how they are related; depth sets how many links to follow. Pass query OR srcEntityId. • mode='path': for CONNECTION questions ("how does X relate to Y?"). Returns up to five of the shortest chains of relationships between two entities, each step saying how it relates to the one before, with a one-line summary; or, when there is none, a message saying why. Pass srcEntityId AND dstEntityId (both in the same project); depth is the most steps a chain may have. • mode='multihop': for MULTI-HOP discovery ("what's relevant to X, even indirectly?"). Starts from the entities closest to the query and follows their relationships outwards, giving more weight to links people authored than to links inferred from text. Best when 'local' returns too few results and the answer means following several relationships in a row. Quick decision tree: - User wants to FIND a named artefact ("the GTM plan", "DOC-123", a uuid) → artefactMetadataOnly:true - User asks for an overview/summary/themes → 'global' - User asks a specific question with a clear answer → 'local' - User asks 'how is X connected to Y' → 'path' (with both entity IDs) - User asks 'what's near entity X' → 'graph' (with srcEntityId) - 'local' returned nothing useful and the question is broad → retry with 'multihop' DATED FACTS: a knowledge-mode response also carries `datedFacts` for the entities the query names: what holds now by default, what held on a day with asOf, or the whole history with history:true, each fact with its dates, how it ended if it has, and its sources. Prefer them for "who owns X now", "what was X in March", "when did X change". RECORDS: where tables of the organisation's databases are in the knowledge graph, a knowledge-mode response also carries `records`: the database records the query names (by name, code, email or another identifier) and the records linked from the improvements and tasks in the results, each read live as the caller may see it, with the fields chosen for its table (its facts, dates and times in timeZone) and its connections. For exact counts, totals or filters over a table, ask the table itself (queryDatabaseRows).

Suggest up to six sample questions to ask the knowledge graph: three standard ones built around the most-mentioned entities, and up to three drawn from the main topics of the content. Optionally for one project.

List the organisation agents you may use: named agents your organisation defined, each with its own scoped credential, a mandate and an approval level in `behaviour`: `confirm` (the default) proposes every change for approval, `confirm_destructive` edits without asking but proposes anything destructive, `autonomous` acts without asking inside its access. `allowAllTools` is true when the agent may use every tool agents are allowed, including tools added later, rather than a fixed list. Returns `myRole` (`owner`, `manage` or `use`) per agent, and `ai`: the kind of work it runs on (everyday or thinking, which owners and admins choose) and whether that runs on the organisation's own AI, on Stable Baseline's AI, or is stopped. Ask one with askAgent, hand it work with delegateToAgent, follow a job with getAgentRun, decide a proposed action with approveAgentAction.

List and search the full Stable Baseline icon library, including 3,850 library icons. The AWS, Azure, GCP, Development, Essentials and other categories stay intact; library icons join matching categories, with specific Oracle Cloud, Kubernetes, Networking and General categories for the rest. The same logical name is shown once. iconKey is the exact icon string for a platform default diagram (type 'default'; e.g. {icon:'aws-account'}); iconKeys lists every exact key for that logical icon, and iconKeyUrl is its SVG. Results without an iconKey are not available in platform default diagrams. Use d2IconPath for compact relative D2 source (e.g. icon-library/azure-function-apps.svg); the renderer expands storage URLs. Existing iconPath values remain relative whiteboard paths; library-only icons supply iconUrl for a whiteboard imageUrl.

Server-side searchable, paginated list of the USERS and TEAMS that can be assigned as the owner of an improvement or task in a project, and the canonical source for resolving a person's user_id when @-mentioning them in a document. Users are the people who may be assigned work in the project: active members of its organisation who can open the project (organisation owners and admins, the workspace's owner and members, and people with a direct or team share on the project or its workspace, unless a share denies them). Teams are the project's organisation's teams, listed for a caller who is an active member of it. Returns two arrays: `users` (with user_id, display_name, email, avatar_url, has_explicit_permission for a direct share on the project) and `teams` (with team_id, name, member_count, has_explicit_permission for a share on the project). Use BEFORE: (1) updateImprovement/updateTask when you need an `owner_id` (kind='user') or `owner_team_id` (kind='team'); (2) inserting a `<!-- REFERENCE: {"type":"user","id":"…","label":"…"} -->` mention in document content via createDocument / editDocument / findAndReplaceTextInDocument. Supports `query` for a case-insensitive search on names and emails (users) or team names (teams). Pass `kind='user'` or `kind='team'` to scope to a single section, or 'all' (default) for both. Pagination via limit (1-100, default 20) and offset.

List an organisation's BRAND KITS (palette/fonts/logo), newest first. Use a returned `id` as brandKitId for a design call or setDefaultBrandKit. Auth: can_admin_org.

List credit-purchase history for an organisation, newest first. Status, credits purchased, bonus, amount paid in AUD cents, completion timestamp. Stripe IDs stripped.

List the kinds of visual a database dashboard can hold: cards and KPIs, gauges, bar, column, line, area and combo charts, pie and donut, treemap, funnel, waterfall, scatter, heat map, table, matrix, slicer, text and image. Each comes with what it is for and what it needs. Next: getDashboardVisualGuide for one type's wells, settings and a worked example, then saveDatabaseDashboard.

List the databases you can use, with their tables and row counts. A database holds tables of rows, like a workbook holds sheets, and lives in a project, a workspace or the whole organisation. Pass projectId to see what a project can use (its own databases plus its workspace's and the organisation's), workspaceId for a workspace (its own plus the organisation's), or organisationId (or nothing) for every database in the organisation that you can read, wherever it lives. query finds databases by name or friendly id (such as DB-12) and tables by name. trashed lists databases in the trash that you manage. Organisation owners and admins: changes lists who changed what in every database, newest first. Next: getDatabase for a database's fields, then queryDatabaseRows to ask questions of a table. getDatabaseGuide explains every database tool by topic (overview first).

List supported diagram types (renderers such as default, mermaid, plantuml, bpmn and d2; 'default' is the platform default renderer). Pass `query` to search by name OR intent (keyword + semantic): e.g. 'circuit diagram', 'wiring harness', 'timing waveform', 'network topology', 'database schema', 'BPMN process'. Each type lists supportedDiagrams: the diagram families it draws (BPMN process, ERD, flowchart, C4, system architecture and more), each with its defaultRenderer. A query that names a family also returns matchedDiagramFamilies. Use a family's defaultRenderer as the type unless you need another renderer's own format (for example BPMN 2.0 XML). Use the returned `type` field with getDiagramTypeGuide (DSL instructions + example) and insertDiagramInDocument / renderDiagram.

List version history for a document. Returns timestamps, creator, change summary, and content. HOW IT CHANGED: give changedSince (a period such as this_week, or a date) for the versions saved in that time, each with who saved it by name and when in words; add compare:true for the difference, worked out from the text: the lines added and removed between the document as it stood before that time and now, each with the heading it sits under. compare:true without changedSince sets a version (versionNumber, else the newest) against the one before it.

List AND grep documents in a project, workspace, or folder. `query` does a full-content search across each document's body (not just the title) and returns the matching lines — like grep across your docs. Each returned document includes `contentMatches: [{line, text, context?}]` and `matchCount`; the `text` is anchor-ready (paste it straight into editDocument's oldText). Use isRegex:true for regular-expression search (e.g. "TODO\(.*\)", "ACME-\d+"), caseSensitive for exact case, and contextLines for surrounding lines (grep -C). versionTimestamp is returned per document so you can edit straight from the results without a getDocument round-trip. Also supports date filtering. SCOPE HONESTY — read this before concluding something is absent: only documents that actually matched are returned (a document is never listed with matchCount 0 just because it was in scope), and the `grep` block reports `scannedDocuments` against `totalDocumentsInScope`. When `truncated` is true the search covered only part of the scope, so an absence is NOT proof; repeat with `scanOffset` set to the returned `nextScanOffset` until that field is gone, and union the results. A document too large to read is returned with `contentSearchSkipped: true` and NO matchCount, because its body was never searched. WHAT CHANGED: give changedSince (a period such as this_week, or a date) to list only the documents added or edited in that time, newest change first, each with change: added or edited, when (in words, in the person's time zone), by whom (a person's name, and the agent's key when one did it) and the versions saved meanwhile. With no projectId, workspaceId or folderId it covers your whole organisation. Only documents the caller may open are listed. For how one changed, call listDocumentVersions with the same changedSince and compare:true. Not with query.

List folders in a project. Use parentId for nested folders. For full tree, use getProjectHierarchy instead.

List improvement categories for a project. Returns tree and flat list.

List AND grep improvements in a project. `query` searches the title, friendlyId and problem statement, not just the title (substring by default; set isRegex:true for a regular expression, caseSensitive:true for exact case). Supports filtering by status, type, priority, and by parentItemId for an item's children in the work hierarchy (an epic's stories, say). For ranked semantic + text search use searchImprovements. Every item carries its versionTimestamp, ready for updateImprovement, so one call here supplies the tokens for a whole batch of updates (fields ["id", "friendlyId", "versionTimestamp"] returns just those), and its parentItem: the item it belongs to in the work hierarchy ({ id, friendlyId, title, type, status, isTask }, or null). Each item also carries linkedRecords, the database rows it links (as getImprovement describes them); filter by them with hasLinkedRecords, linkedRecordIds and linkedTableIds. projectId is required unless changedSince is given. WHAT CHANGED: give changedSince (a period such as this_week, or a date) to list only the improvements and tasks added or changed in that time, newest change first, each with change: what happened, when (in words, in the person's time zone), by whom (a person's name, and the agent's key when one did it), and what happened to each in that time in words (status and field changes, comments, evidence). With no project named it covers a workspace (workspaceId) or your whole organisation. Only what the caller may open is listed. With changedSince the filters are status, type, priority, source, categoryId and query.

List organisation invitations. Auth: org id must match the credential's organisation AND the credential must hold the can_manage_members capability. Status defaults to 'pending'. Pass 'all' to disable filtering.

List invoices for an organisation, newest first. Returns hosted Stripe invoice URLs and PDF links. Stripe IDs are stripped.

List members of an organisation, enriched with email + display name. Auth: org id must match the credential's organisation. Returns paginated list, default limit 50 / max 200.

List organisations you have access to. Supports query filtering by name/slug.

List saved payment methods for an organisation. Returns masked card metadata only (brand, last4, exp month/year, default flag). NEVER returns full card numbers, CVCs, or any Stripe IDs.

List phases for a plan ordered by position. Each phase carries its own versionTimestamp, ready for updatePlanPhase.

List AND grep plans in a project. `query` searches the title, friendlyId and description, not just the title (substring by default; set isRegex:true for a regular expression, caseSensitive:true for exact case). Supports filtering by status and priority. projectId is required unless changedSince is given. WHAT CHANGED: give changedSince (a period such as this_week, or a date) to list only the plans added or changed in that time, newest change first, each with change: what happened, when (in words, in the person's time zone), by whom (a person's name, and the agent's key when one did it), and what happened to each in that time in words (status and field changes, comments). With no project named it covers a workspace (workspaceId) or your whole organisation. Only what the caller may open is listed. A plan's tasks are work items: listImprovements with the same changedSince lists them.

List projects in a workspace. Supports query filtering by project name.

List explicit permission grants on a resource (workspace/project/folder/document/improvement/plan), including principal type (user|team), level (none|read|write|admin), and 3-state overrides for documents/improvements/plans/whiteboards. Read-only. Use when the user asks 'who can see this', 'who has access', 'what permissions are set on this', or to audit existing access on a resource. Also lists who a database or one of its tables is shared with (resource_type database or db_table, needs admin on the database) and who a single row is shared with (db_row, for the row's owner or an admin); a table and a row also name database_id, a row also table_id.

List FS/SS/FF task-dependency edges in a plan (the Gantt arrows). Scope by planId, projectId, or itemId. `direction`: 'predecessors' | 'successors' | 'both' (default, only with itemId).

List AND grep tasks in a plan. `query` searches the title, friendlyId and description, not just the title (substring by default; set isRegex:true for a regular expression, caseSensitive:true for exact case). Supports filtering by status, priority, phaseId and parentItemId (a story's tasks in the work hierarchy, say). Every task carries its versionTimestamp, ready for updateTask, so one call here supplies the tokens for a whole batch of updates, its parent_item_id and parentItem (the item it belongs to in the work hierarchy, or null), and linkedRecords, the database rows it links (as getTask describes them); filter by them with hasLinkedRecords, linkedRecordIds and linkedTableIds.

List teams in an organisation, with optional search filter and an `includeMembers` flag that returns each team's members in the same call. Supply EITHER organizationId OR workspaceId (the workspace's parent org is resolved automatically). Use this when the user asks about teams generically (e.g. 'show me my teams') or before assigning a team via updateImprovement(owner_team_id=…). Read-only.

Search the built-in library of structural whiteboard stencils — ready-made hand-drawn graphics: flowchart/UML/ER/BPMN symbols, scrum columns, org-chart nodes, gantt, lo-fi/UX wireframe widgets (buttons, forms, tables, alerts, navs), charts, device frames, stick figures. A stencil is a MINI-WHITEBOARD (a collection of elements), NOT a single shape. Each result returns: `key`, `title` (a real human name e.g. 'Alerts', not an index), `kind` ('symbol' | 'template'), `labels` (the TEXT it actually contains — its real content, e.g. an Alerts template's variant messages), `size` ({w,h} px), `summary`, `pack`, `category`; plus the full pack/category lists. The two kinds are used DIFFERENTLY: • SYMBOL = one atomic labelled node (flowchart Process/Decision, BPMN task, org node). Place + label + connect: addWhiteboardElements({type:'stencil', stencilKey, id:'n1', text:'Review', width, height}) — the text auto-fits its single slot and an arrow's start/end {id:'n1'} binds to it like any shape. A few symbols are text-less FRAMES (e.g. a UML class box = rectangle + divider line): place create-only, then use the placement result's `children` (shapes + x/y/w/h) and `groupId` to add type:'text' specs INTO the regions — pass that groupId so the text is one unit with the frame. • TEMPLATE = a multi-component layout (Alerts, Forms, Tables, Charts, device frames). Place the WHOLE thing: addWhiteboardElements({type:'stencil', stencilKey, x, y, width?, height?}); the placement RESULT returns `stencils[].children` (each child's id + text + colour + position x/y/w/h, so you can group children into rows/sections) so you then keep / retext / recolour / DELETE specific parts via updateWhiteboardScene (e.g. delete the info + error rows to keep only the green success alert). Do NOT pass a single `text` to a template — read its `labels` to see its parts, then edit them by id. To make several similar items, build one then duplicateWhiteboardElements({groupId, dx}) to stamp consistent copies (like copy-paste in the UI). SEARCH TIPS: prefer BROAD single words ('decision','alert','form','phone','process'); content words match the embedded `labels` too (searching 'success' finds the Alerts template). If nothing exact matches, results auto-broaden (broadened:true); pass pack/category to browse. For cloud/architecture ICONS (AWS/Azure/GCP/Docker/Kubernetes/databases) use listArchitectureIcons; for a sticky/post-it use addWhiteboardElements({type:'sticky'}), not a stencil.

List AND grep the whiteboards in a project (hidden whiteboard-kind documents). `query` searches the title and friendlyId (substring by default; set isRegex:true for a regular expression, caseSensitive:true for exact case). This is the tool to find a board by name — listDocuments deliberately excludes whiteboards. Returns documentId, diagramId, title and timestamps for each. projectId is required unless changedSince is given. WHAT CHANGED: give changedSince (a period such as this_week, or a date) to list only the boards added or changed in that time, newest change first, each with change: what happened, when (in words, in the person's time zone), by whom (a person's name, and the agent's key when one did it). With no project named it covers a workspace (workspaceId) or your whole organisation. Only what the caller may open is listed.