Memoket — access your recording transcripts, summaries, and key takeaways over MCP.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.1/5 across 7 of 7 tools scored. Lowest: 3.4/5.
Each tool targets a distinct aspect: metadata, content types (brief, summary, transcript), filtered transcript, listing, and search. No two tools overlap in purpose.
All tools follow a consistent verb_noun pattern using snake_case (get_*, list_*, search_*), making their actions predictable.
Seven tools cover the retrieval scope without being too many or too few; each serves a clear function in the conversation management domain.
The server lacks direct fetchers for several result types from search (e.g., memory_atoms, segments, action_items), creating dead ends for agents that need to retrieve those details.
get_briefA[content_fetch] Per-conversation compact report body for the given conversation_ids using Brief -> Summary -> Standard, where Standard is the first completed non-empty type=0 report.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| brief_ids | No | optional brief ids from search_recordings.brief_ids | |
| conversation_ids | No | recording ids from brief hits |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| result | Yes | Tool-specific result payload; shape varies per tool (object for most; may be null/array/text for some). Intentionally type-unconstrained for strict-validating clients. |
| took_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true and destructiveHint=false, and the description reinforces the read-only nature by describing data retrieval. It adds behavioral context about the fallback logic and report selection, which is beyond the annotations.
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 a single dense sentence, reasonably concise but includes an internal tag '[content_fetch]' that may not be meaningful to an agent. The core logic is front-loaded, but the tag reduces clarity.
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 an output schema exists and annotations are present, the description explains the core algorithm appropriately. However, it omits details on how 'offset' and 'brief_ids' influence results and does not describe the output format, leaving moderate gaps.
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?
With schema description coverage at 67%, two parameters have descriptions while 'offset' lacks one. The description only mentions 'conversation_ids' and does not explain 'offset' or 'brief_ids' beyond what schema provides. This is adequate but not enhanced.
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 it fetches a 'compact report body' per conversation, specifying the fallback hierarchy (Brief->Summary->Standard) and the selection criterion ('first completed non-empty type=0 report'). This distinguishes it from sibling tools like get_summaries or get_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 does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for brief reports but lacks when-not-to-use scenarios or comparisons with sibling tools such as get_conversations or get_summaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_conversationsA[metadata_query] Conversation-level metadata for the given conversation_ids: id, title, started_at, ended_at, duration_seconds, participants, language_code. No transcript, brief, or summary body.
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_ids | No | required, non-empty; opaque recording ids |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| result | Yes | Tool-specific result payload; shape varies per tool (object for most; may be null/array/text for some). Intentionally type-unconstrained for strict-validating clients. |
| took_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds detail on what fields are returned and what is excluded, providing transparency beyond annotations. No contradiction.
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 a single, well-structured sentence listing included fields and explicit exclusions. Efficient, but could be slightly more structured with bullet points or clearer separation.
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 the presence of an output schema (though not shown) and annotations, the description sufficiently covers the tool's purpose and return data. It is complete for the tool's scope.
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 covers 100% of parameters, describing 'conversation_ids' as required and non-empty. The description adds no further semantic value beyond what the schema provides, meeting baseline.
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 returns conversation-level metadata for given IDs, listing specific fields (id, title, etc.) and explicitly excludes transcripts or summaries, distinguishing it from siblings.
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?
While not explicitly stating when to use, the description implies this is for metadata-only needs, and the exclusion of transcripts helps differentiation. The field listing and '[metadata_query]' tag provide clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_summariesA[content_fetch] Per-conversation summary body. With summary_ids, fetch exact summary reports from search_recordings. With conversation_ids only, fetch the latest summary report for each conversation. Paginated (offset).
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| summary_ids | No | optional summary ids from search_recordings.summary_ids | |
| conversation_ids | No | required, non-empty; ids are opaque strings (may be 19-digit snowflake) |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| result | Yes | Tool-specific result payload; shape varies per tool (object for most; may be null/array/text for some). Intentionally type-unconstrained for strict-validating clients. |
| took_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with readOnlyHint=true and destructiveHint=false. It adds pagination (offset) detail not covered by annotations. No contradictions.
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 short, front-loaded with a category tag, and concise: three sentences covering purpose, modes, and pagination. No unnecessary words.
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 there is an output schema, the description covers core behavior (two retrieval modes, pagination). It is complete enough for the agent to understand usage.
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 67%; the description adds context: summary_ids come from search_recordings, conversation_ids are required non-empty and are opaque strings. Offset is mentioned but not detailed. Overall adds meaning beyond the schema.
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 it fetches per-conversation summary body. It distinguishes two modes: fetching exact summaries by summary_ids or latest by conversation_ids. This differentiates it from siblings like get_brief or get_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 explains when to use summary_ids vs conversation_ids, and mentions pagination. It does not explicitly state when not to use it or contrast with siblings, but the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transcriptsA[content_fetch] Verbatim transcript of ONE recording by conversation_id. Paginated (offset / next_offset) — page through for more.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| conversation_id | No | required; opaque id string (may be 19-digit snowflake) |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| result | Yes | Tool-specific result payload; shape varies per tool (object for most; may be null/array/text for some). Intentionally type-unconstrained for strict-validating clients. |
| took_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, confirming safe read. Description adds 'content_fetch' tag, pagination behavior, and that it returns verbatim transcripts. No contradictions.
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?
Two succinct sentences. Every word adds value: tool purpose, pagination indicator, and source tag. 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?
Given output schema exists, description adequately covers return type (verbatim transcript) and pagination. Missing detail on next_offset format but sufficient for 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 50% (only conversation_id described). Description compensates by explaining offset is for pagination ('page through') and conversation_id identifies the recording. Adds key meaning beyond schema.
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 it fetches 'Verbatim transcript of ONE recording by conversation_id'. This distinguishes from siblings like get_transcripts_by_participant which filters by participant.
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 usage for single recording transcript retrieval but lacks explicit guidance on when not to use or alternatives. No context provided for selecting among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transcripts_by_participantB[content_fetch] Transcript lines associated with participant_ids in conversation_ids. Turns participant metadata into transcript evidence for exposed search results.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| participant_ids | No | participant ids from search_recordings.participant_ids | |
| conversation_ids | No | recording ids scoped by participant hits |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| result | Yes | Tool-specific result payload; shape varies per tool (object for most; may be null/array/text for some). Intentionally type-unconstrained for strict-validating clients. |
| took_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about 'exposed search results' but lacks details on pagination, auth, or rate limits.
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?
Two concise sentences with no wasted words, efficiently using a tag for categorization.
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?
While output schema exists, the description does not explain the 'query' or 'limit' parameters or the logical link between the two arrays, leaving gaps.
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?
With 50% schema description coverage, the description fails to clarify the 'limit' and 'query' parameters or the relationship between participant_ids and conversation_ids.
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 it retrieves transcript lines filtered by participant_ids and conversation_ids, which distinguishes it from sibling tools like get_transcripts and search_recordings.
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?
No explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_conversationsA[metadata_query] List recordings by time window / participants. Returns id, title, started_at, ended_at, duration_seconds, participants, language_code (no content). Paginated (count default 100, max 200; offset). order_by ranks within the window. NOTE: participants are speaker labels — placeholders ('Speaker A/B') unless the user tagged them, not necessarily real names.
| Name | Required | Description | Default |
|---|---|---|---|
| desc | No | true = descending (default); false = ascending. | |
| count | No | page size (default 100, max 200) | |
| offset | No | page offset; use the response's next_offset | |
| end_time | No | ISO 8601, filters on started_at | |
| order_by | No | duration_seconds | started_at | action_item_count — server sorts the whole window and returns the top `count`. | |
| start_time | No | ISO 8601, filters on started_at | |
| participant_names | No | Exact participant filter (may return 0 for un-tagged/anonymized people). |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| result | Yes | Tool-specific result payload; shape varies per tool (object for most; may be null/array/text for some). Intentionally type-unconstrained for strict-validating clients. |
| took_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond annotations: pagination limits, ordering behavior, participant name caveat. No contradictions with annotations.
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?
Two focused sentences plus a note; every sentence adds value. Front-loaded with core purpose.
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?
Covers pagination, ordering, participant caveat, and return fields. Output schema handles detailed return structure. Fully meets complexity of 7 parameters.
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 100%, but the description adds meaning for order_by (whole-window sorting) and participant_names (exact filter, potential empty results).
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 'List recordings by time window / participants' and specifies returned metadata fields, distinguishing it from content-focused siblings like get_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?
Provides context on filtering by time/participants, pagination, and a note on speaker labels, but lacks explicit when-not-to-use or alternative sibling references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_recordingsA[search] Unified recording search. Runs bounded searches over transcript lines, topic segments, memory atoms, participant metadata, titles, briefs, summaries, and action items in one call. Returns typed hits plus conversation_ids, line_ids, segment_ids, memory_atom_ids, participant_ids, brief_ids, summary_ids, action_item_ids. Chat execution expands hits into readable evidence automatically; external callers can fetch returned ids where a matching fetcher is advertised.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Required. One phrase for a single concept, or a JSON array string of 2-4 distinct facets. | |
| end_time | No | ISO 8601; filters by recording started_at. | |
| start_time | No | ISO 8601; filters by recording started_at. | |
| search_types | No | Optional lane filter. Omit to search all. Allowed: transcript, segment, memory_atom, participant, title, brief, summary, action_item. | |
| conversation_ids | No | Optional: restrict to these opaque recording ids. |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| result | Yes | Tool-specific result payload; shape varies per tool (object for most; may be null/array/text for some). Intentionally type-unconstrained for strict-validating clients. |
| took_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral context beyond annotations: 'bounded searches' implies limits, and explains automatic expansion in chat. No contradiction with readOnlyHint=true and destructiveHint=false.
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?
Two sentences with no wasted words. Front-loaded with core purpose, then lists return types and execution notes. Highly efficient.
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?
Covers all key aspects: search types, return IDs, execution modes. Could mention pagination or limits explicitly, but overall adequate given the tool's complexity and presence of output schema.
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 100%, so parameters are well-documented. The description adds minimal extra meaning beyond what the schema provides (e.g., 'bounded searches' is not parameter-specific). Baseline 3 applies.
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 performs unified recording search across multiple data types (transcript, topic, memory, participant, etc.) in one call, distinguishing it from sibling tools that retrieve specific record types like get_brief or get_conversations.
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?
Provides clear context that for chat execution hits are expanded automatically, while external callers fetch IDs for advertised fetchers. Does not explicitly state when not to use, but purpose differentiation with siblings is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
