Which integrations are available for this server?

Writes Zoom meeting summaries into Obsidian vault notes, matching meeting participants to note files and inserting content chronologically. Provides access to Zoom meeting summaries via AI Companion, including listing, retrieving, and deleting meeting summaries.

How do I use zoom-summaries?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@zoom-summaries write the summary for meeting 96980348286 to my Obsidian note" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

zoom-summaries

by unhuman

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Zoom Meeting Summaries MCP Server

An MCP (Model Context Protocol) server that provides access to Zoom meeting summaries and writes them into an Obsidian vault. Uses Puppeteer-based browser authentication — on first use, a browser window opens for you to sign in to Zoom. Session cookies are saved to ~/.zoom-mcp/cookies.json and reused automatically until they expire.

Configurable for any Zoom organization (e.g., acme.zoom.us, yourcompany.zoom.us).

Prerequisites

Node.js 18+
A Zoom account with AI Companion meeting summaries enabled
An Obsidian vault with 1:1 note files named First Last.md

Related MCP server: Zoom API MCP Server

Setup

npm install
npm run build

Configuration

Variable	Description	Default
`ZOOM_SUBDOMAIN`	Your org's Zoom vanity subdomain (e.g. `acme` for `acme.zoom.us`)	(empty — uses zoom.us)
`OBSIDIAN_VAULT_PATH`	Absolute path to your Obsidian vault root	(required)
`VAULT_SUBFOLDER`	Subfolder within the vault containing 1:1 note folders (e.g. `MyOrg`)	(empty — search directly under vault root)
`ONE_ON_ONE_FOLDERS`	Comma-separated list of folder names holding 1:1 notes	`! One on Ones, ! One on Ones (Other)`
`SHARED_MEETINGS_FOLDER`	(Optional, v1.1.0+) Folder for meetings shared WITH you. If not set, shared meetings are not processed.	(empty)

Usage with Claude Desktop

Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "zoom-summaries": {
      "command": "node",
      "args": ["/absolute/path/to/zoomFetchMCP/build/index.js"],
      "env": {
        "ZOOM_SUBDOMAIN": "acme",
        "OBSIDIAN_VAULT_PATH": "/path/to/your/vault",
        "VAULT_SUBFOLDER": "MyOrg",
        "ONE_ON_ONE_FOLDERS": "! One on Ones,! One on Ones (Other)"
      }
    }
  }
}

Usage with VS Code Copilot (Agent Mode)

Ensure chat.agent.enabled is turned on in VS Code settings. Then add .vscode/mcp.json to your workspace:

{
  "servers": {
    "zoom-summaries": {
      "type": "stdio",
      "command": "node",
      "args": ["/absolute/path/to/zoomFetchMCP/build/index.js"],
      "env": {
        "ZOOM_SUBDOMAIN": "acme",
        "OBSIDIAN_VAULT_PATH": "/path/to/your/vault",
        "VAULT_SUBFOLDER": "MyOrg",
        "ONE_ON_ONE_FOLDERS": "! One on Ones,! One on Ones (Other)"
      }
    }
  }
}

Available Tools

`zoom_login`

Opens a browser window for you to sign into Zoom. Call this first if you get authentication errors. Session cookies are saved to ~/.zoom-mcp/cookies.json for automatic reuse.

`list_meeting_summaries`

List meeting summaries with optional source and date filtering.

Parameter	Type	Description
`source`	string (optional)	`owned` (default) or `shared`
`from`	string (optional)	Start date (e.g. `2025-01-01`)
`to`	string (optional)	End date (e.g. `2025-02-01`)

`get_meeting_summary`

Get the full AI-generated summary for a specific meeting.

Parameter	Type	Description
`meeting_id`	string	The Zoom meeting ID

`write_summary_to_obsidian`

Fetch a Zoom meeting summary and write it into the matching Obsidian 1:1 note. Matches the note file by the first name in the meeting topic (e.g. Amit:Howard → Amit Kumar.md). After a successful write, deletes the summary from Zoom.

Parameter	Type	Description
`meeting_id`	string	The numeric Zoom meeting ID (e.g. `96980348286`)

`write_all_summaries_to_obsidian`

Fetch every Zoom meeting summary and write each one to the matching Obsidian 1:1 note. Skips multi-person meetings (not 1:1s), skips meetings with no matching file, and skips duplicates already present in the note. After each successful write (including duplicates already in the vault), deletes the summary from Zoom.

Parameter	Type	Description
`from`	string (optional)	Start date filter (e.g. `2026-01-01`)
`to`	string (optional)	End date filter (e.g. `2026-02-23`)

Obsidian Integration

File matching

The tool looks for a vault note to write each summary into using this priority:

Exact attendee name match — a file named First Last.md matching an attendee
Topic first-name prefix — file whose name starts with the first name from the topic (e.g. Amit from Amit:Howard), preferring solo files over shared ones (Amit Kumar.md over Amit Kumar + Bob.md)
Word-boundary search — broader name search as fallback

Multi-person meetings (3+ participants, or Name1:Name2:Name3 topic format) are skipped — only 1:1s are written.

Note format

Summaries are inserted in the vault's tab-indented style, newest-first:

If the date already has manual notes: Zoom content is appended below the existing notes for that day (with a blank line separator), without repeating the date header. Starts with \tZoom AI Summary.
If the date is new: A standalone YYYY-MM-DD - Zoom AI Summary section is inserted at the correct chronological position.

Caches

All caches are in-memory only and scoped to a single run. They exist solely to avoid fetching the same meeting twice within one execution (e.g. a meeting whose attendees were resolved in the attendee phase need not be re-fetched in the summary phase). No cache data is ever written to disk. ~/.zoom-mcp/ only holds cookies.json (session) and optionally config.json (vault path).

Dry-Run / Live Script

zoom-meetings-to-obsidian.mjs is a standalone Node.js script for previewing and applying changes.

# Dry-run: copies vault files to /tmp/obsidian-preview and applies mutations there
node zoom-meetings-to-obsidian.mjs

# Write to real vault (no deletion)
node zoom-meetings-to-obsidian.mjs --update

# Write to real vault and delete summaries from Zoom
node zoom-meetings-to-obsidian.mjs --update --delete

# Add --debug to any command for verbose diagnostics (page elements, network requests, etc.)
node zoom-meetings-to-obsidian.mjs --update --delete --debug

--delete without --update is an error.

Output includes:

A table of every meeting: topic, target file, and insert/duplicate/skip status
A Would delete from Zoom list (dry-run) or live deletion results (--do-it)

Inspect dry-run results in /tmp/obsidian-preview before running with --do-it.

How It Works

On first use (or when cookies expire), calling zoom_login opens a real browser window
You sign in to Zoom normally (SSO, password, etc. — any method works)
Session cookies are saved to ~/.zoom-mcp/cookies.json
Subsequent calls use a headless browser with saved cookies to scrape the summaries page
Meeting summaries are written into Obsidian notes using chronological insertion
After writing, the summary is deleted from Zoom's AI Companion summary list
If cookies expire, call zoom_login again

Development

npm run build  # Compile TypeScript → build/
npm run dev    # Watch mode (tsc --watch)
npm start      # Run the MCP server (stdio transport)

Version Bumping Checklist

Before committing code changes, bump the version in ALL THREE files:

package.json (main package)
ObsidianPlugin/package.json (plugin package)
ObsidianPlugin/manifest.json (must stay in sync with plugin package.json)

Use semantic versioning:

PATCH (x.y.Z) — bug fixes and small improvements
MINOR (x.Y.z) — new features or settings
MAJOR (X.y.z) — breaking changes

Example workflow:

# 1. Make code changes
# 2. Bump version in all three files (e.g., 1.2.10 → 1.2.11)
# 3. Rebuild
npm run build
# 4. Commit code + version bump together
git add .
git commit -m "fix/feat/docs: description here"

⚠️ Never commit code changes without updating all three version numbers. If they diverge, the build output version won't match what Obsidian displays to users.

Related docs:

See ObsidianPlugin/CLAUDE.md for detailed versioning requirements and consequences of version mismatch

Available Tools

5 tools

get_meeting_summaryA

Get the full AI-generated summary for a specific Zoom meeting.

ParametersJSON Schema

Name	Required	Description	Default
`meeting_id`	Yes	The Zoom meeting ID

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states it gets a summary but does not clarify output format, authentication requirements, potential errors, or whether zoom_login is a prerequisite. This is a significant gap for a tool with no structured safety hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It directly states the action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter getter, the description is reasonably complete in purpose. However, it lacks guidance on workflow context (e.g., requires zoom_login, how to interpret the summary, or relation to sibling write tools). No output schema exists, so the description could have added return-value context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single parameter meeting_id, so the schema already documents it. The description adds no extra meaning beyond the schema, which matches the baseline of 3 for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and resource ('full AI-generated summary for a specific Zoom meeting'), clearly distinguishing it from siblings like list_meeting_summaries. The scope is precise and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when you have a specific meeting_id and want the summary, but it does not explicitly state when to use it over sibling tools like list_meeting_summaries or write_summary_to_obsidian. No alternatives or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_meeting_summariesA

List Zoom meeting summaries. Optionally filter by date range and source (owned or shared).

ParametersJSON Schema

Name	Required	Description	Default
`to`	No	End date (e.g. 2025-02-01)
`from`	No	Start date (e.g. 2025-01-01)
`source`	No	'owned' for your meetings, 'shared' for meetings shared with you	owned

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It clearly conveys a read-only listing operation via 'List', but doesn't discuss response format, pagination, or potential side effects. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences that front-load the core function and then add filter options. No wasted words; perfectly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with optional filters, the description covers the essential behavior. Since there is no output schema, the implied return of summaries is sufficient, though mentioning the return format would make it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains each parameter. The description's mention of 'date range' and 'source' adds no additional semantics beyond restating the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('List Zoom meeting summaries') and clearly indicates the optional filters. It distinguishes from siblings like get_meeting_summary and write_summary_to_obsidian by focusing on listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (when you need to list summaries) and provides filter options. It doesn't explicitly name alternatives or exclusions, but the context is clear. A 5 would require explicit when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

write_all_summaries_to_obsidianA

Fetch every Zoom meeting summary (owned and shared) and write each one to the matching Obsidian note. Skips meetings with no matching file and skips duplicates. Shared meetings are never deleted from Zoom.

ParametersJSON Schema

Name	Required	Description	Default
`to`	No	Optional end date filter (e.g. '2026-02-23')
`from`	No	Optional start date filter (e.g. '2026-01-01')

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so the description carries the burden. It discloses that meetings without a matching file are skipped, duplicates are skipped, and shared meetings are never deleted from Zoom. However, it doesn't clarify whether existing Obsidian notes are overwritten or appended, nor what happens to owned meetings, leaving some side effects undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no waste; the first gives the main action, the second adds key exclusions. Efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so return behavior is not disclosed, but the description covers the core behavior and edge cases. It could mention how notes are matched or the effect of date filters, so it's not fully complete, but it's adequate for a bulk operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters have complete descriptions in the schema (coverage 100%), so the baseline is 3. The description doesn't add any extra meaning to the date filters; it just mentions 'every' which could conflict with the existence of filters. Thus, no additional value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches every Zoom meeting summary and writes each to a matching Obsidian note, with explicit skips. It distinguishes from sibling write_summary_to_obsidian by emphasizing bulk 'every' and from list_meeting_summaries by including the write action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies bulk use ('every') but doesn't explicitly state when to use this instead of write_summary_to_obsidian or when to avoid it. No alternatives or exclusions provided. Usage is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

write_summary_to_obsidianA

Fetch a Zoom meeting summary and append it to the matching person's note in the Obsidian vault. Finds the file by matching the first name in the meeting topic (e.g. 'Amit:Howard' → Amit Kumar.md).

ParametersJSON Schema

Name	Required	Description	Default
`meeting_id`	Yes	The numeric Zoom meeting ID (e.g. '96980348286')

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose side effects, but it only says 'append' without clarifying reversibility, required permissions, or what happens if no matching note exists. The matching logic is a helpful behavioral detail, but the tool's mutation aspect and potential failure modes are not addressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the primary action, and includes a concrete example. Every word adds value, with no redundant phrasing or unnecessary details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core functionality and matching rule, but given the absence of an output schema and annotations, it omits key context such as prerequisites (e.g., zoom_login), error behavior if no matching note exists, and how the summary is formatted. It is adequate but not fully complete for a tool with side effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides a full description for the single parameter meeting_id ('The numeric Zoom meeting ID'), reaching 100% coverage. The description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches a Zoom meeting summary and appends it to a person's note in Obsidian. It includes the specific matching logic ('matching the first name in the meeting topic') and gives an example, which differentiates it from siblings like get_meeting_summary (which only fetches) and write_all_summaries_to_obsidian (which writes all).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does but does not explicitly say when to use it versus alternatives. The behavior is implied as a single-meeting operation, but there is no direct mention that write_all_summaries_to_obsidian should be used for bulk processing or that get_meeting_summary should be used if only fetching is needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

zoom_loginA

Open a browser window to log into Zoom. Call this first if you get authentication errors. Saves session cookies for reuse.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses key side effects: opens a browser window and saves session cookies for reuse. However, it does not mention user interaction requirements or whether the window closes automatically, which would add completeness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no wasted words. The key information is front-loaded: what it does, when to use, and the cookie-saving behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, parameterless login tool, the description covers the action, the trigger condition, and the persistence effect. No output schema is needed, and the tool is fully specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema coverage is 100% (empty). The description adds no parameter details, but none are needed. Baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Open a browser window to log into Zoom.' This is a specific verb and resource, and it is distinct from sibling tools that focus on meeting summaries and Obsidian writing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs when to use: 'Call this first if you get authentication errors.' This provides a clear trigger condition and implies precedence over other tools, even without naming alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv1.2.8Aug 12, 2026
- First observedget_meeting_summary
- First observedlist_meeting_summaries
- First observedwrite_all_summaries_to_obsidian
- First observedwrite_summary_to_obsidian
- First observedzoom_login

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-08-12 10:00 across 5 tools

Disambiguation5/5

Each tool has a distinct purpose: authentication, listing summaries, retrieving a single summary, writing one summary to Obsidian, and writing all summaries. There is no overlap or ambiguity between the tools.

Naming Consistency5/5

Tool names follow a consistent verb_noun pattern: list_meeting_summaries, get_meeting_summary, write_summary_to_obsidian, write_all_summaries_to_obsidian. 'zoom_login' is slightly different but still clear and predictable.

Tool Count5/5

Five tools is well-scoped for the server's purpose of retrieving Zoom meeting summaries and exporting them to Obsidian. Each tool earns its place and the count is ideal.

Completeness4/5

The tool set covers the full workflow: login, list, get, write one, write all. Missing are any delete/update operations on summaries, but that may be outside the intended scope. Minor gap in lacking a way to fetch a summary by meeting ID directly, but workable.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

zoom-meetingsOAuth
io.github.zoom
Zoom Meetings server for meeting search, recordings, transcripts, summaries, and meeting assets.
Communication Workplace & Productivity
2
sunub-obsidian-mcp-server
ai.smithery
Search your Obsidian vault to quickly find notes by title or keyword, summarize related content, a…
Note Taking Search Text Summarization
22
note1.ai AOAuth
ai.note1
Search meetings, export summaries and transcripts, and manage recordings from any AI tool.
Search Note Taking Communication
1
Hint-Services-obsidian-github-mcp
ai.smithery
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Note Taking Version Control File Systems
29

Related MCP Servers

Zoom API MCP Server
Communication Developer Tools
heesookiim
F
license
Not graded
quality
D
maintenance
Enables interaction with Zoom services through the Zoom API. Provides access to meeting management, user administration, and other Zoom platform features through natural language commands.
Updated a year ago (2025-08-13 19:14 UTC)
-
Zoom API MCP Server
Communication Developer Tools App Automation
ag2-mcp-servers
F
license
Not graded
quality
D
maintenance
Enables interaction with Zoom services through the Zoom API. Provides access to Zoom's functionality for meeting management, user operations, and platform features through natural language.
Updated a year ago (2025-08-18 19:17 UTC)
-
academic-workflow-mcp
Research & Data Note Taking
wuruiqi
A
license
A
quality
B
maintenance
Connects Zotero and Obsidian for an AI-assisted academic reading workflow, enabling paper fetching, structured note creation, highlight syncing, and review management.
Updated 3 months ago (2026-06-28 05:22 UTC)
10
MIT
zoom-mcp
Communication Search Text Summarization
aronroyca
A
license
Not graded
quality
D
maintenance
Provides AI agents with structured access to Zoom recorded meetings, enabling search, summarization, and action item extraction.
Updated 5 months ago (2026-04-10 16:20 UTC)
2 npm
BSD 2-Clause "Simplified"