Fieldwerk

Your best thinking often happens right in the AI chat thread — a sharp answer, a plan taking shape, a draft that's nearly there.

But that work is easily lost in long threads, and it's tricky to untangle a complex idea or bring other people in. Copy-pasting out to another system is laborious, and it disconnects the work from your AI.

MCP connector

Server URL: https://mcp.fieldwerk.ai/mcp
Login: OAuth
Protocol: MCP 2025-03-26
Instructions: Reading memos works through share links without sign-in, but creating or editing anything requires the user's Fieldwerk account, connected over OAuth. If a tool answers with an authentication challenge, call the tool: it returns whether the user is connected and, when they are not, a link for them to sign in and authorise. Give that link to the user, ask them to approve access, then retry. Many MCP clients also open the authorisation page automatically on the first call that needs it. Memos can be ARCHIVED: read-only, hidden from list/search tools unless you pass include_archived: true, and openable only by the workspace's members while archived. always reports archived_at (null = live); any write to an archived memo returns memo_archived. Use / to change the state (edit access required), and with keep_archived when restoring from trash.
STANDING INSTRUCTIONS: a workspace, a collection in it, and a notebook inside that can each carry STANDING INSTRUCTIONS written by their author — how that container is meant to be used, what belongs in it, the conventions to follow when working in it. They are a brief to follow, not a description to summarise, and they layer: the workspace's preamble applies everywhere in it, a collection's applies to everything in that collection, a notebook's to that notebook. , and flag which have them (has_instructions: true) and return the text with include_instructions: true; and return one container in full, layers above included (workspace_instructions, collection_instructions). Writes that target a container ( with collections, , , with collection) echo its instructions back on the response, so read them there if you did not read them first. Read them BEFORE you create, edit or file anything in that container, and follow them. Every read shows instructions_updated_at / instructions_updated_by. Write them with / / (or at creation with / ): instructions replaces the whole text, append_instructions adds a rule without resending the rest, patch_instructions applies a unified diff. The author owns this text: rewrite it only when the user asks you to, and prefer append or patch over a wholesale replace so nothing is dropped unseen.
FINDING BY PROPERTY: to find memos by their properties across a workspace's collections in one call ("assigned to me, review due by today"), use , not one listing call per collection. Name the workspace, and give every clause a layer: "frontmatter" for the memo's own front matter, "collection" for a collection property (matched by name in every collection that defines it), or "both". "@me" means the connected account. Pass dates yourself as YYYY-MM-DD. Each result says which collection and layer matched, so write changes back with on that same layer.
ARTIFACTS: to revise an HTML artifact (in a memo, or a file in a collection or notebook), call on its asset rather than uploading a new one: the link and embed stay the same, earlier versions are kept, and note records what changed. lists each embedded artifact's asset, block id and version count.
CONCURRENCY MODEL (how version and base_version relate): a memo carries a single integer version that returns. It increments by exactly 1 on every write that changes the memo's BODY or its front-matter FIELDS, from any surface: MCP and REST writes, AND a browser editor flushing typed changes (those land as a realtime-sourced bump). Comment, reaction, assignment, and collection-membership activity do NOT touch version (they are separate from the body), so a version that jumped between two reads means the body or fields actually changed in between, not that someone commented. base_version is OPTIONAL: pass the version you last read and the write is gated by optimistic concurrency against the current row. If the memo moved since your read, the server first attempts a line-level 3-way merge of your change onto the current body, using the body you read as the base: when the intervening edit touched non-overlapping lines (e.g. a different section), your write LANDS cleanly merged on top of it, and version reflects the current head, not your stale base. Only a genuine same-region overlap is REJECTED with a conflict (409-equivalent) carrying current_markdown, current_version, and a severity (minor = 1 or 2 versions behind, same author; major = 3+ behind OR a different author wrote since). OMIT base_version only when you explicitly intend a last-writer-wins overwrite of whatever is there now. There is no separate lock taken; the CAS is the whole mechanism, so two writes that both omit base_version simply apply in arrival order. Most write tools also accept confirm_overwrite_changes: <current_version> as the escape hatch to force a major conflict through once you've surfaced it to the user (must match the current_version from the rejection; a new conflict lands a new number to re-confirm against).

Tools

Reads data35

Changes data78

Deletes or can't be undone13

Skills

None in the store listings or on the server

MCP connector

Server URL

https://mcp.fieldwerk.ai/mcp

OAuth

Protocol

MCP 2025-03-26

Instructions

Reading memos works through share links without sign-in, but creating or editing anything requires the user's Fieldwerk account, connected over OAuth. If a tool answers with an authentication challenge, call the tool: it returns whether the user is connected and, when they are not, a link for them to sign in and authorise. Give that link to the user, ask them to approve access, then retry. Many MCP clients also open the authorisation page automatically on the first call that needs it. Memos can be ARCHIVED: read-only, hidden from list/search tools unless you pass include_archived: true, and openable only by the workspace's members while archived. always reports archived_at (null = live); any write to an archived memo returns memo_archived. Use / to change the state (edit access required), and with keep_archived when restoring from trash.

STANDING INSTRUCTIONS: a workspace, a collection in it, and a notebook inside that can each carry STANDING INSTRUCTIONS written by their author — how that container is meant to be used, what belongs in it, the conventions to follow when working in it. They are a brief to follow, not a description to summarise, and they layer: the workspace's preamble applies everywhere in it, a collection's applies to everything in that collection, a notebook's to that notebook. , and flag which have them (has_instructions: true) and return the text with include_instructions: true; and return one container in full, layers above included (workspace_instructions, collection_instructions). Writes that target a container ( with collections, , , with collection) echo its instructions back on the response, so read them there if you did not read them first. Read them BEFORE you create, edit or file anything in that container, and follow them. Every read shows instructions_updated_at / instructions_updated_by. Write them with / / (or at creation with / ): instructions replaces the whole text, append_instructions adds a rule without resending the rest, patch_instructions applies a unified diff. The author owns this text: rewrite it only when the user asks you to, and prefer append or patch over a wholesale replace so nothing is dropped unseen.

FINDING BY PROPERTY: to find memos by their properties across a workspace's collections in one call ("assigned to me, review due by today"), use , not one listing call per collection. Name the workspace, and give every clause a layer: "frontmatter" for the memo's own front matter, "collection" for a collection property (matched by name in every collection that defines it), or "both". "@me" means the connected account. Pass dates yourself as YYYY-MM-DD. Each result says which collection and layer matched, so write changes back with on that same layer.

ARTIFACTS: to revise an HTML artifact (in a memo, or a file in a collection or notebook), call on its asset rather than uploading a new one: the link and embed stay the same, earlier versions are kept, and note records what changed. lists each embedded artifact's asset, block id and version count.

CONCURRENCY MODEL (how version and base_version relate): a memo carries a single integer version that returns. It increments by exactly 1 on every write that changes the memo's BODY or its front-matter FIELDS, from any surface: MCP and REST writes, AND a browser editor flushing typed changes (those land as a realtime-sourced bump). Comment, reaction, assignment, and collection-membership activity do NOT touch version (they are separate from the body), so a version that jumped between two reads means the body or fields actually changed in between, not that someone commented. base_version is OPTIONAL: pass the version you last read and the write is gated by optimistic concurrency against the current row. If the memo moved since your read, the server first attempts a line-level 3-way merge of your change onto the current body, using the body you read as the base: when the intervening edit touched non-overlapping lines (e.g. a different section), your write LANDS cleanly merged on top of it, and version reflects the current head, not your stale base. Only a genuine same-region overlap is REJECTED with a conflict (409-equivalent) carrying current_markdown, current_version, and a severity (minor = 1 or 2 versions behind, same author; major = 3+ behind OR a different author wrote since). OMIT base_version only when you explicitly intend a last-writer-wins overwrite of whatever is there now. There is no separate lock taken; the CAS is the whole mechanism, so two writes that both omit base_version simply apply in arrival order. Most write tools also accept confirm_overwrite_changes: <current_version> as the escape hatch to force a major conflict through once you've surfaced it to the user (must match the current_version from the rejection; a new conflict lands a new number to re-confirm against).

Tools