Use a Docs MCP Server to Turn Meeting Notes into a Project Brief

A Docs MCP server gives an AI assistant tools for reading and writing documents. To turn meeting notes into a useful project brief, the assistant needs more than a connection: it must find the right source, distinguish decisions from open questions, show you a draft and verify what it saved.

This tutorial follows that sequence in AppStruct Docs. You will use a fictional meeting about a service-request pilot, create a separate practice brief and optionally update one action's status. The source notes stay intact. This is an educational exercise with expected checks, not a customer case study or a claim about time saved.

Prepare the fictional meeting notes

Download the meeting-notes practice fixture. Open AppStruct Docs, create a document called Meeting notes — DEMO-BRIEF-001 — practice, and paste the file's text into its body. The download is plain text; this exercise does not depend on a file-import feature.

The meeting agrees to a request form, team list and detail view with a status update. It chooses a web pilot and leaves a mobile app store release outside the scope. It does not agree on a budget, data store or launch date.

The two fictional actions are deliberately different:

Reopen the document to check that its text was saved before connecting the assistant. Use a document owned by the same AppStruct account as your API key. Documents shared with that account are not part of the Docs API-key view.

Connect the Docs MCP server with the access you need

Follow the Docs MCP connection guide to reach the Docs API-key settings and configure a compatible client. The Docs endpoint is:

https://api.appstruct.cloud/v1/docs/mcp

It uses Streamable HTTP with an Authorization: Bearer YOUR_APPSTRUCT_DOCS_API_KEY header. Replace the placeholder in your client's local connection settings with your own key.

A docs:read key supports locating and reading the notes. Creating the brief needs docs:write too. For this complete exercise, use both scopes; the optional find-and-replace also requires both. After a scope change, refresh your client's tool discovery or reconnect so it sees the tools available to that key.

The tools used below have these names:

This surface works with words. It does not give the assistant tools for changing fonts, images, page setup or comments. New content is plain text: sending HTML or Markdown does not create a formatted layout. Apply headings or other visual formatting in the editor after checking the content.

Find and read the source before drafting

Begin with a read-only request:

List documents and find “Meeting notes — DEMO-BRIEF-001 — practice”. Show matching document IDs and titles before selecting one. Read the chosen document in full. Do not create or change any document yet.

list_documents returns titles and IDs, rather than document bodies. If there are several matches, choose the exact practice document. Keep that source ID separate from the new brief's ID later in the exercise.

If you remember a phrase instead of a title, search_documents is another starting point. For example, its arguments can be:

{
  "query": "DEMO-BRIEF-001",
  "limit": 5
}

Search matches a case-insensitive substring in titles and text. It checks at most the 40 most recently edited documents and can also stop at its character budget. A response that says the scan was limited is not proof that a document does not exist. Raising the result limit does not expand the search scan; use the paginated document list to locate an older source, then read it by ID.

For the selected source, get_document takes:

{
  "document_id": "YOUR_SOURCE_DOCUMENT_ID"
}

Replace the placeholder with the discovered ID. Long documents are returned in pages of up to 20,000 characters; follow the response's next start value until you have the needed text. This fixture is short enough for one page.

Check the read result against the source in Docs. Both action IDs, their owners and the explicit unknowns should be present. The text says the meeting did not approve a customer launch; a project brief must preserve that distinction.

Review the proposed project brief

Now ask for a draft in the conversation, before saving it:

Using only this source, propose a short project brief with a goal, agreed scope, out-of-scope work, decisions, actions, open questions and an acceptance check. Keep the action IDs, owners and due dates exactly as written. Mark missing information as “Not agreed”; do not invent a budget, technology choice, deadline or launch approval. Show the complete proposed text and wait for my review before creating a separate document. Leave the source notes unchanged.

Use the following checks to review the proposal:

A polished sentence can still change the meaning of a decision. Reject a draft that turns “Not agreed” into a date, labels an action complete or says access controls are already configured. Those facts are absent from the notes.

For the optional update below, keep each action as one plain-text line in the brief, exactly as it appears in the downloaded fixture. The rest of the brief can use short section labels and paragraphs.

Create a separate document and read it back

Once you have reviewed the complete text, ask the assistant to create one document titled Project brief — DEMO-BRIEF-001 — practice with that agreed body. Tell it to return the new document ID and read the saved brief with get_document.

create_document accepts title and optional text. Its argument structure is:

{
  "title": "Project brief — DEMO-BRIEF-001 — practice",
  "text": "YOUR_REVIEWED_PLAIN_TEXT_BRIEF"
}

The body value is a placeholder for your reviewed draft. Each newline becomes a paragraph; do not send the placeholder as the document's actual text. Creation returns an ID, not the full saved body, so the read-back is a separate check.

Compare the saved brief with the review table above, then open it in Docs. Read the source notes again and confirm they still contain the original meeting text. You should now have two independent documents: the source notes and the reviewed practice brief. Creating the brief does not establish a live link or keep the two synchronized.

If creation times out, list and inspect documents before retrying. A second create_document call can create a second document; a missing response does not show whether the first write completed.

Optionally verify one exact update

For a second practice task, simulate starting DEMO-A1 by changing only its status in the brief. This is a fictional update for the exercise, not evidence that a real task began.

Read the brief again first. Confirm that the following complete line appears exactly once, then show the proposed replacement before writing:

DEMO-A1 | Owner: Example A | Task: Draft the form fields | Due: 2026-11-10 | Status: Not started

After reviewing the change, the replace_all_text arguments are:

{
  "document_id": "YOUR_BRIEF_DOCUMENT_ID",
  "find": "DEMO-A1 | Owner: Example A | Task: Draft the form fields | Due: 2026-11-10 | Status: Not started",
  "replace": "DEMO-A1 | Owner: Example A | Task: Draft the form fields | Due: 2026-11-10 | Status: In progress",
  "match_case": true
}

Use the new brief's ID, not the source ID. This tool replaces every match in the selected document, so matching only “Not started” would also change DEMO-A2. An omitted or empty replacement deletes the matched text; include the full intended replacement.

Expect the response to report one occurrence changed. Read the brief again and check that DEMO-A1 now says In progress, DEMO-A2 still says Not started, and the due dates and open questions are unchanged. Re-read the source to verify that its DEMO-A1 status remains Not started.

If zero occurrences changed, inspect the current text instead of claiming success or broadening the match. The MCP server has no undo tool. It also offers insert_text, whose positions refer to the current document's 1-based text indexes; old indexes become stale after an edit. This exercise uses an exact line replacement to keep the intended change inspectable.

Diagnose an incomplete result

The Docs API reference describes the related REST operations, while the current OpenAPI document lists the MCP tools. Read the tools actually exposed by your connection rather than assuming every account or key has the same write access.

Choose the next workflow

The result of this exercise is a brief you can trace to its source: decisions remain decisions, unknowns stay visible and one saved change has been checked against neighboring content. Reuse that sequence for an internal handoff or a project kickoff with its own review criteria.

For structured rows and statuses, try the separate Sheets MCP service-request tracker. Moving actions from a brief into a workbook is another reviewed task; this tutorial does not automatically connect Docs and Sheets.

Explore AppStruct Workspace for the document and spreadsheet tools. If you want to build the form, saved records and team views described in the fictional brief, continue with App Builder and the service-request app guide.