tamlil-mcp
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@tamlil-mcpsummarize last week's bilingual meeting"
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.
Tamlil is a macOS menu-bar app that records your Zoom and Slack calls and turns them into clean, speaker-labeled transcripts — even when the conversation switches between Hebrew and English in the middle of a sentence. It starts recording on its own when a call begins, and the transcript is waiting for you the moment you hang up. Everything stays on your Mac; all that ever leaves it is the transcription request — the call audio plus a short recognition hint (meeting title, attendee names, learned terms) — and Tamlil deletes the upload from the provider as soon as the transcript comes back.
Why Tamlil
It records itself. Join a Zoom call or a Slack huddle and Tamlil starts capturing; hang up and the transcript builds automatically. Nothing to launch, click, or remember to turn on.
Built for Hebrew and English together. Most transcribers make you pick one language per meeting. Tamlil keeps up with real bilingual speech, tagging each word's language, so a sentence that starts in Hebrew and ends in English comes out right.
Every speaker labeled — and playable. Your side and the other side are separated and named, and the finished recording plays back inline with a waveform, so you can jump to any line and hear exactly what was said.
Correct it as you read; it remembers. Tamlil flags the words it was unsure of right in the transcript. Fix one and it learns the term for every future meeting, so your names, products, and jargon stop coming back wrong.
Private by default. Recordings, transcripts, and your learned vocabulary live only on your Mac. Your API key sits in the Keychain, never in a file. After each meeting Tamlil deletes both the audio and the transcript from the provider, so nothing lingers off your device.
Answers from your AI assistant. A read-only connector lets Claude Code or Codex read your finished meetings and answer questions or draft summaries.
Related MCP server: Meetings MCP Server
A look inside
Install
One command. You need macOS 15 (Sequoia) or later on an Apple-Silicon Mac and
the Xcode Command Line Tools 16 or later (xcode-select --install; the build
needs their Swift 6 toolchain); the installer handles everything else.
curl -fsSL https://raw.githubusercontent.com/Steven17D/tamlil/main/scripts/install.sh | zshIt clones Tamlil, builds and installs the app, puts the transcript connector on your PATH, asks for your Soniox API key (from console.soniox.com), and launches. The first time a call records, macOS asks you to approve Microphone and System Audio Recording — say yes. Re-running the command updates an existing install. Optional meeting titles from Google Calendar need a one-time OAuth-client setup first — see Google Calendar setup.
git clone https://github.com/Steven17D/tamlil.git
cd tamlil
uv sync # Python deps (install uv from astral.sh/uv)
make app # build Tamlil.app
rm -rf /Applications/Tamlil.app && cp -R Tamlil/dist/Tamlil.app /Applications/
defaults write dev.dashevsky.tamlil repoPath "$PWD"
scripts/launch-agent.sh restart # launch under crash supervision
# store your Soniox key in the Keychain (never in a file)
security add-generic-password -s tamlil-soniox -a soniox -w "<KEY>" -UTo read meetings from an AI agent, also put the connector on your PATH:
uv tool install --force . then
claude mcp add tamlil --scope user -- "$HOME/.local/bin/tamlil-mcp".
Updating. Click Check for updates in the menu, or re-run the install command — Tamlil pulls the latest, rebuilds from source, and relaunches.
How it works
Join a call. When a call app (Zoom, or a Slack call or huddle) starts using your microphone, Tamlil records two local tracks: your mic and the meeting's system audio.
Hang up. Recording stops with the call, and transcription runs automatically on the finished recording.
Read the transcript. The two tracks are transcribed, merged and speaker-labeled, cleaned of mic echo, and rewritten through your learned vocabulary. The finished transcript appears in the menu-bar app and is saved under
~/Recordings/Tamlil/.Ask an agent (optional). Claude Code or Codex reads finished meetings over the read-only connector and writes its own summaries.
For how the menu-bar app, pipeline, transcription, lexicon, connector, and Google Calendar fit together, see the architecture overview.
Privacy and data handling
Tamlil records real meeting audio, so it is worth being precise about what
leaves your machine and what does not. The transcription provider is
Soniox; the facts below are grounded in Soniox's published
Terms of Service and Privacy Policy (both last updated 2026-06-29).
docs/soniox-data-processing.md has the full write-up and sources.
What is captured. Two local audio tracks per meeting: your microphone (
raw/mic.wav) and the meeting app's system audio (raw/system.wav). Recording starts automatically when a call app begins capturing your mic.What leaves your machine. Traffic to two services, nothing else. The two audio tracks are uploaded to Soniox's async speech-to-text API (default endpoint
api.soniox.com), and each request carries a recognition hint — the meeting title, attendee names, and learned lexicon terms — so Soniox spells them correctly. If you connect Google Calendar, meeting titles and attendee names are read from it. The read-only connector serves agents locally and sends nothing anywhere.Training and secondary use. Soniox commits, in its binding Terms of Service and again in its Privacy Policy, that it does not use customer content to "train, fine-tune, evaluate, benchmark, or improve" its models or services, and that it does not sell it. This is the default; no opt-in is required.
Retention. The async API is Soniox's storage service: uploaded audio and the resulting transcript are stored server-side with no automatic deletion, so cleanup is the caller's responsibility. After each run the pipeline deletes the stored transcription, which also removes the uploaded audio file, so under normal operation neither the audio nor the transcript text is retained by Soniox. (Deletion is best-effort: a failure is logged and does not fail the run. For a single-file
tamlil-transcriberun,--keep-remoteskips it.)Data residency. Because the pipeline calls the default
api.soniox.com, audio and transcripts are processed and stored in the United States, unless a regional Soniox project (EU or Japan) was explicitly requested and configured.Legal basis. Usage is governed by Soniox's self-serve, click-through Terms of Service plus Privacy Policy. A data-processing agreement and a HIPAA BAA are available through the Soniox Console but are not automatic — unless one has been accepted for the account, neither is in force.
Calendar scope. Roster lookup is read-only and optional. It requests the single scope
https://www.googleapis.com/auth/calendar.events.readonlyand reads only meeting titles and attendee names. The per-user refresh token lives in your macOS Keychain (tamlil-google); without it, meetings still record and transcribe, just without titles or attendee names.Local storage. Recordings, transcripts, and the learned lexicon stay on your Mac — recordings under
~/Recordings/Tamlil/<recording-id>/, the learned dictionary at the repo root. The Soniox API key lives in the Keychain (tamlil-soniox), never in a file. The connector opens the recording database read-only.Deletion. To delete a recording locally, remove its directory under
~/Recordings/Tamlil/. On Soniox, both the uploaded audio and the stored transcription are removed automatically after each run, so nothing needs to be deleted there by hand under normal operation.
To report a security issue, see SECURITY.md.
Recording consent
Tamlil records your microphone and the meeting app's system audio together, so every participant's voice is captured. Recording a conversation is regulated by wiretap and eavesdropping laws that turn on who agreed to be recorded, and those laws differ by jurisdiction.
You are responsible for obtaining consent. Tamlil is a local tool that records on your behalf. The person running it — not the project's author and not the software — is responsible for obtaining whatever consent the law requires from everyone on the call, and for doing so before recording starts.
All-party versus one-party. Jurisdictions differ on how many participants must consent. In one-party jurisdictions (much of the United States) your own consent is enough. In all-party jurisdictions — often called two-party — every participant must consent: California requires the consent of all parties to a confidential communication (Penal Code section 632), and the EU generally requires a lawful basis and the participants' consent under the GDPR and national law. A call that crosses borders can leave you bound by the strictest rule that applies to anyone on it.
Not legal advice. The above is general information, not legal advice, and it is not exhaustive. Consent rules vary by country, state, and context and they change over time. Check the law in your own jurisdiction and in each participant's, and get your own legal advice, before you record.
For developers
Tamlil is two halves that share a recording database: a SwiftUI menu-bar app in
Tamlil/ and a Python transcription pipeline in src/tamlil/ (run through
uv). The commands below assume the checkout the installer creates at
$HOME/Library/Application Support/Tamlil/repo; substitute your own path if you
cloned elsewhere.
REPO="$HOME/Library/Application Support/Tamlil/repo"
cd "$REPO"Run the pipeline by hand
uv run tamlil-pipeline ~/Recordings/Tamlil/<recording-id>The mic track is labeled with your macOS first name; override with --me-name.
Transcribe a single file with uv run tamlil-transcribe path/to/audio.wav. If a
run fails, the audio is preserved under raw/ — fix the cause (usually the
Soniox key or balance) and re-run; --skip-transcribe reuses an existing merge
and only redoes the cheap local stages.
The pipeline, in order: look up the meeting roster and build recognition
context; optionally denoise the mic track; transcribe both tracks concurrently;
merge by timestamp with per-track speaker labels; suppress mic echo from the
system track; apply learned lexicon rewrites; save clarification cards from
low-confidence spans; and write final/transcript.{json,md}.
Read meetings from an AI agent
The connector (an MCP server) is read-only over the recording database and
transcript files, exposing list_meetings, get_meeting, get_transcript, and
search_transcripts. The installer registers it with Claude Code for you; to
add it by hand:
claude mcp add tamlil -- uv run --project "$REPO" tamlil-mcpFor Codex (~/.codex/config.toml), point it at an absolute path:
[mcp_servers.tamlil]
command = "uv"
args = ["run", "--project", "/Users/<you>/Library/Application Support/Tamlil/repo", "tamlil-mcp"]It honors TAMLIL_DB_PATH / TAMLIL_RECORDINGS_ROOT overrides and never
writes — the database is opened read-only.
Recording storage
Each recording is a directory under ~/Recordings/Tamlil/<recording-id>/:
raw/ holds the captured mic.wav and system.wav; work/ holds pipeline
intermediates (denoised audio, per-track transcripts, the merged draft, the echo
report); final/ holds transcript.json and transcript.md; logs/ holds the
pipeline log. transcript.json keeps segment text, speaker diarization, language
IDs, word timings and confidence, low-confidence spans, and the echo report.
Google Calendar setup (bring your own OAuth client)
The calendar feature — meeting titles and attendee names, also fed to the recognizer as context — is optional and stays off until you register your own Google OAuth client and point Tamlil at it (Tamlil ships none of its own). It's a five-minute, one-time setup: see docs/google-calendar-setup.md.
Source-first delivery
Tamlil is built and installed from source, not shipped as a notarized binary. Two consequences are deliberate:
Ad-hoc code signing.
Tamlil/build.shsigns the app withcodesign --sign -(no Developer ID, no notarization). Because you build it yourself, macOS runs it without a Gatekeeper detour, and the microphone and system-audio permission grants — keyed to the bundle id — survive every rebuild as long as the signature stays consistent.Pull-and-rebuild updater. Check for updates runs
scripts/update.sh, which pulls the latest source into your checkout, rebuilds, reinstalls, and relaunches. There is no Sparkle feed or separate update channel to trust; the source you can read is the source that runs.
Because the app runs from your checkout, its repo path is a first-run setting (Settings → Pipeline → tamlil repo); the installer sets it for you.
Troubleshooting
No permission prompts / silent recordings — check Tamlil is enabled under System Settings → Privacy & Security → Microphone and System Audio Recording, then relaunch. Grants are keyed to the bundle id and need re-approval if it ever changes.
swift buildfails immediately — install or update the Command Line Tools withxcode-select --install; the build needs CLT 16+ (Swift 6).swift testis not supported (the package defines no test target); usemake test-swift, which runs the app's built-in self-check.Pipeline error on a meeting — the audio is preserved under
raw/; re-runuv run tamlil-pipeline <dir>after fixing the cause (usually the Soniox key or balance).Empty roster / no meeting titles — run
uv run tamlil-authto connect your Google account; see the Google Calendar setup above.
Contributing and stack
See CONTRIBUTING.md. The stack: uv (Python 3.12), Soniox
stt-async-v5, requests, numpy, static-ffmpeg, SwiftUI, and SQLite.
License
Apache-2.0 — see LICENSE. Bundled third-party components are credited in NOTICE and THIRD_PARTY_LICENSES.
Available Tools
4 toolsget_meetingA
Full metadata for one meeting: roster, named speakers, transcript availability, and pending clarification count.
| Name | Required | Description | Default |
|---|---|---|---|
| meeting_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read operation on meeting metadata and enumerates the included data, but it does not disclose error behavior, permissions, or return format. This is acceptable for a simple get, but leaves some room for improvement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the core purpose, and every word adds value. It is extremely concise without losing important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description adequately scopes the result by listing key metadata components. It omits potential error cases or exact return shape, but given the simplicity, it is fairly complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation of meeting_id beyond its name. Since the tool has one parameter and the description does not compensate for the lack of schema descriptions, the agent must infer the intended meaning from the parameter name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full metadata for one meeting, listing specific components (roster, named speakers, transcript availability, pending clarification count). This distinguishes it from siblings like list_meetings and get_transcript, which have clearly different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on what this tool returns, implying it should be used when detailed metadata for a specific meeting is needed. It does not explicitly mention alternatives or when not to use it, but the focus on 'one meeting' differentiates it from list_meetings and get_transcript.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transcriptA
The meeting transcript, with resolved speaker names and clock timestamps.
By default this does NOT return the transcript text — a long meeting would
flood your context. It returns metadata plus `path`: a rendered transcript
file you should open with your own file tools, reading only the ranges you
need. To pull lines inline instead (e.g. no filesystem access), pass `limit`
(and optional `offset`) to get that slice of segment lines directly.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| meeting_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses that by default it does NOT return the transcript text, returns a `path` to a rendered file, and warns about context flooding. It also clarifies the inline alternative, providing essential behavioral expectations beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence provides value: the first states the core output, the second explains the default and the reasoning, the third explains the inline alternative. Well-structured in two readable paragraphs with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with 3 parameters and no output schema, the description covers the essential behavior, default vs. inline modes, and the file path usage. It could be more explicit about when to prefer search_transcripts, but given the sibling list, the description is sufficiently complete for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does: `limit` and `offset` are explained as controlling a slice of segment lines, and `meeting_id` is implied via 'meeting transcript'. The distinction between default (no text) and passing `limit` clarifies the meaning of the parameter effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'the meeting transcript, with resolved speaker names and clock timestamps' and distinguishes itself by describing its default behavior (metadata plus path, not text). The lack of an explicit verb like 'retrieves' is compensated by the tool name and the detailed description of what is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use the default mode (avoid flooding context) versus when to pass `limit`/`offset` for inline text (e.g., no filesystem access). This gives clear usage context, though it does not explicitly name sibling tools like search_transcripts as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_meetingsA
List recorded meetings, newest first.
from_date/to_date are inclusive ISO dates (YYYY-MM-DD); app filters on the
meeting app name (case-insensitive substring, e.g. "zoom").
| Name | Required | Description | Default |
|---|---|---|---|
| app | No | ||
| limit | No | ||
| to_date | No | ||
| from_date | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context like 'newest first' sorting, inclusive date boundaries, and case-insensitive substring matching for the app filter. However, it does not mention pagination behavior, what happens when filters are omitted, or any permissions needed, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs. The first sentence states the primary purpose, and the second paragraph details parameter behavior. There is no redundant information or filler; every sentence contributes to understanding how the tool works.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values. It adequately covers the core behavior (listing recorded meetings with optional date and app filters, sorted newest first). The only minor gap is the lack of explicit mention of the limit parameter's behavior, but the schema provides a default, making the tool usable without further detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameter descriptions, so the description must compensate. It adds meaning for three of the four parameters: from_date/to_date are described as inclusive ISO dates, and app is described as a case-insensitive substring. The 'limit' parameter is left entirely to the schema, but its meaning is obvious from its name and default value, so the description covers most parameter semantics effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List recorded meetings, newest first,' which clearly states the action (list) and resource (recorded meetings). It also distinguishes itself from siblings like get_meeting (which retrieves a specific meeting) and get_transcript (which retrieves a transcript) by focusing on the list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the filtering semantics (from_date/to_date inclusive, app as case-insensitive substring) and implies usage for listing meetings with optional filters. However, it does not explicitly state when to use this tool vs alternatives (e.g., search_transcripts) or mention any exclusions or prerequisites, so the guidance is implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_transcriptsA
Search all transcripts for a phrase (case-insensitive). Returns matching meetings, newest first, with the matching transcript lines as excerpts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and provides meaningful behavioral details: case-insensitive matching, newest-first ordering, and inclusion of matching transcript lines as excerpts. It does not cover limit behavior or edge cases, but the core behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no filler, immediately stating the action and key return characteristics. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with an output schema, the description covers purpose, scope, sorting, and excerpt behavior. It does not need to explain return structure since the output schema exists, though limit behavior is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate but only implicitly covers 'query'. It does not explain the 'limit' parameter's meaning or effect, leaving a gap in parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies a unique action ('Search all transcripts for a phrase') with scope, case-insensitivity, and return format. It distinguishes from sibling tools (list/get) by focusing on search across all transcripts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for finding content within transcripts, clearly distinct from listing or retrieving specific meetings. However, it does not explicitly mention exclusions or alternative tools when other actions would be more appropriate.
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. Dates show when Glama detected each change.
4 tool updates
v1.0.0- First observed
get_meeting - First observed
get_transcript - First observed
list_meetings - First observed
search_transcripts
TDQS
Each tool has a clearly distinct role: list_meetings filters and lists, get_meeting fetches metadata for one meeting, get_transcript retrieves transcript content, and search_transcripts finds phrases across transcripts. No two tools overlap in purpose.
All tool names follow a consistent verb_noun pattern with lowercase and underscores: list_meetings, get_meeting, get_transcript, search_transcripts. The naming is uniformly readable and predictable.
With 4 tools, the server is well-scoped for a meeting/transcript archive. Each tool covers a core operation, and the count is neither too sparse nor excessive.
The server provides a complete read-only lifecycle: list meetings, get metadata, get transcript, and search content. There are no obvious dead ends for the stated purpose of retrieving meeting recordings and transcripts.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
- RecordXOAuthio.recordx
Read-only access to your RecordX meetings: search transcripts, summaries, action items.
Search and read your Laxis meeting transcripts, AI summaries, and participants from Claude.
Search meetings, export summaries and transcripts, and manage recordings from any AI tool.
- PithflowOAuthcom.pithflow
Read-only access to your own Pithflow meeting notes, transcripts, dictionary and usage.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables access to Fireflies.ai meeting transcripts with capabilities to retrieve, search, filter, and generate AI-powered summaries of meeting content through the Fireflies API.41721MIT
- AlicenseNot gradedqualityFmaintenanceProvides read-only access to Google Drive meeting transcripts and Google Calendar events, enabling AI assistants to search, analyze, and retrieve meeting insights.3653MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to search and retrieve meeting transcripts from Otter.ai, supporting full-text search, speaker identification, and transcript retrieval.5MIT
- AlicenseAqualityDmaintenanceEnables AI assistants to query local Migas meeting transcripts, including searching, listing meetings, and retrieving speaker contributions, all read-only.515MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Steven17D/tamlil'
If you have feedback or need assistance with the MCP directory API, please join our Discord server