MCP for Meeting Workflows, Explained Without the Hype

MCP for Meeting Workflows, Explained Without the Hype

Model Context Protocol gives an AI application a standard way to discover data and invoke tools. In a meeting workflow, that can connect conversation context to Linear, a CRM, a calendar, or a knowledge base. MCP describes capability. It does not establish trust, business authority, or permission for a particular action.

A concrete example

A customer mentions a software defect. The meeting assistant proposes a Linear ticket.

To do that safely, the system must identify the relevant statement, find the approved Linear tool, map the user's workspace and schema, prepare the complete ticket, show the proposed write, obtain authority, execute with a narrow credential, and confirm the returned record.

sequenceDiagram
    participant U as User
    participant A as Meeting agent
    participant S as MCP server
    participant L as Linear
    A->>S: List approved tools
    S-->>A: Schemas and descriptions
    A->>U: Preview ticket and source
    U-->>A: Approve exact write
    A->>S: Call create-ticket tool
    S->>L: Scoped API request
    L-->>S: Record ID and result
    S-->>A: Structured result
    A->>U: Verified ticket or error

The protocol standardizes the middle. The host, server, external system, and organization still own the controls around it.

Resources, prompts, and tools are different

The current MCP server documentation describes three important server capabilities.

Resources expose data or context, such as a meeting record or project document. Prompts offer reusable message templates or workflows. Tools expose schema-defined operations that a model can request.

A resource read can still disclose sensitive data. A prompt can contain untrusted instructions. A tool can change an external system. The categories help the client reason about behavior, but none is inherently safe.

The November 2025 MCP specification uses JSON Schema for protocol structures and defines authorization for HTTP transports. Local standard-input and output servers use different credential patterns.

Discovery is not authorization

Michael Daugherty explains in E108 that a connected agent can explore how a person's Airtable or Obsidian system is organized. That can reduce configuration work because the system may infer which table tracks electronics or which folder holds a project.

Inference should produce a proposed mapping, not hidden permission.

The same table name can mean different things. A row may be an inventory record, tax record, insurance schedule, or personal reminder. Deleting it because a meeting mentioned discarding a laptop could destroy evidence that must remain.

Show the discovered source, inferred meaning, proposed operation, and affected record. Let the owner confirm the mapping before the first write.

Treat the server as software with privileges

A local MCP server is a program running on the user's computer. A remote server is a service receiving requests and often credentials. Review either one as software, not as a harmless connector label.

Official MCP security guidance requires clear consent before one-click local server installation, including the exact command that will run. It also addresses OAuth consent, redirect validation, and confused-deputy attacks.

For HTTP transports, the current authorization guidance recommends separating access by tool or capability and validating required scopes at the resource server.

Verify the publisher, source, package integrity, update path, dependencies, command, network destinations, filesystem access, credentials, and every exposed tool.

Tool descriptions are untrusted input

An agent reads tool names, descriptions, schemas, and results to decide what to do. A malicious or compromised server can place instructions inside those fields.

OWASP's MCP security guidance describes tool poisoning, cross-server escalation, over-scoped tokens, confused-deputy behavior, and data exfiltration. It recommends least privilege, strict schemas, approved servers, sandboxing, explicit confirmation, and logging.

Do not rely on a system prompt to stop a tool that has backend permission. Enforce restrictions in code and at the external service.

Structured results help, but schema validation does not prove that the underlying content is honest. Keep untrusted tool output separate from system instructions and consequential decisions.

Credentials need a narrow audience

Use a separate credential for each server and intended service. Bind the token to the correct audience where the authorization system supports it. Request the smallest scope and shortest useful lifetime.

A meeting assistant that reads project names should not receive organization-administrator access. A ticket-creation tool should not inherit repository deletion or billing privileges.

Never pass a broad user token through another server as a shortcut. The current MCP authorization specification prohibits token passthrough and requires resource audience handling for protected HTTP servers.

Preview the real tool call

Approval should include the complete parameters.

For an email, show recipients, subject, body, attachments, and sending identity. For a ticket, show workspace, project, owner, labels, description, and source. For a note update, show the file or record and the exact change.

Ask again when the destination, operation, tool definition, scope, or consequence changes.

Low-risk recurring operations can use a standing policy, but the policy needs limits, exceptions, audit, and revocation.

Log and verify the outcome

Record the source meeting, user or service identity, server and tool version, requested parameters, approval, execution time, returned identifier, final state, and correction.

NIST's agent identity and authorization work highlights auditing, non-repudiation, delegated authority, and human authorization as core design questions.

Read the created or updated record back. A successful protocol response is not enough when the external business state matters.

Inventory before connecting

Create a matrix of every server, resource, prompt, tool, credential, scope, destination, data class, write effect, approval rule, log, and recovery method.

Start read-only. Add one reversible write after the mapping and source boundaries are understood. Test with non-sensitive data and a designated workspace.

Do not begin with email sending, production changes, payments, account deletion, employee evaluation, or customer commitments.

MCP is useful because it makes the boundary inspectable

MCP can replace bespoke integration glue with a common capability interface. That is valuable for meeting systems because the useful context and canonical work often live in different tools.

The protocol does not remove the hard parts. Trust the server only after review. Scope the credential. Treat meeting statements as evidence, not authority. Preview consequential calls. Verify the result. Preserve recovery.

Read [[How to Turn Meetings Into Actions Without Losing Control]], [[What Is an AI Chief of Staff]], and [[Michael Daugherty on Building Quill Into an AI Chief of Staff|Michael Daugherty on Quill]] next.

AI assisted with research organization and drafting. Dalton Anderson remains responsible for the analysis and publication decision.