Memoket — access your recording transcripts, summaries, and key takeaways over MCP.
Scored across 7 tools
Each tool maps to a distinct retrieval action: metadata by ID, metadata listing, transcripts, participant-filtered transcripts, briefs, summaries, and unified search. Even the two report-fetching tools, get_brief and get_summaries, are clearly separated by their descriptions.
All tools follow a consistent snake_case verb_noun pattern: get_*, list_*, and search_recordings. The names are predictable and the resource being operated on is always clear.
Seven tools is a well-scoped size for a recording/conversation retrieval and search server. Each tool earns its place and there is no obvious redundancy.
The surface covers metadata listing/lookup, transcript retrieval, participant-level transcript evidence, brief/summary content, and unified search. A minor gap is that search returns memory-atom, topic-segment, and action-item IDs without dedicated fetchers for those individual report types.
[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.
[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.
[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.
[content_fetch] Verbatim transcript of ONE recording; at most 100 lines / 4000 characters per page. Resume using both next_offset and next_text_offset from the returned item, including within a long line.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| text_offset | No | Character offset inside the first line; use returned next_text_offset, default 0. | |
| 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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the transcript is verbatim, limited to 100 lines/4000 characters per page, and requires resuming with both offsets, including within a long line. This goes beyond the schema and 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 sentences, front-loaded with the core purpose and key constraints. Every clause earns its place: verbatim, single recording, page limits, and the exact resume mechanism. No filler.
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 output schema exists and annotations cover safety, the description is nearly complete. It explains pagination and the tricky text_offset behavior. It could mention what happens at the end of the transcript or how to detect completion, but the output schema likely covers that. The main gap is not explicitly stating when to use this versus get_transcripts_by_participant, but the 'ONE recording' qualifier handles it.
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 67%: conversation_id and text_offset are described in the schema, but offset is not. The description adds meaning by explaining the pagination contract (use both next_offset and next_text_offset) and the 'within a long line' nuance, which clarifies how text_offset behaves. It doesn't fully explain offset's default or relationship, but the pagination guidance compensates.
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 states a specific verb ('get') and resource ('verbatim transcript of ONE recording'), and distinguishes itself from siblings by emphasizing 'verbatim' and 'ONE recording' versus summaries or participant-based retrieval. The '[content_fetch]' tag and pagination details further clarify its role.
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 clearly implies when to use it: when a verbatim transcript of a single recording is needed, and it provides explicit pagination instructions ('Resume using both next_offset and next_text_offset'). It does not explicitly name alternatives or exclusions, but the sibling list and 'verbatim' qualifier make the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[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.
[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 case-insensitive filter on stored tagged participant names. Use when participant-field membership is requested; un-tagged or anonymized people do not match. |
| 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?
Beyond the readOnly/destructive annotations, the description discloses pagination behavior (default and max count, offset), ranking semantics (order_by ranks within the window), and a significant data-quality caveat about participant placeholders. This is substantial behavioral context an agent needs before trusting results.
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?
Three sentences carry the main purpose, returned fields, pagination, ordering, and a critical participant-label caveat with no filler. The statement is front-loaded with purpose and ends with the most important interpretive warning.
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 list tool with no required parameters and an output schema present, the description covers the key operational details: result shape, pagination, sorting, and the participant-name caveat. An agent has enough context to call the tool 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 coverage is 100%, so the baseline is 3, and the description adds useful clarifications: order_by ranks within the window, offset should use the response's next_offset, and participant_names only match stored tagged names, not placeholders. These clarifications go beyond the schema's field-level descriptions.
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 a specific action and resource ('List recordings by time window / participants') and defines the scope as metadata only, listing exact fields and excluding content. It does not explicitly differentiate from the sibling get_conversations or search_recordings, so it misses the top level of distinction.
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 `[metadata_query]` tag and the explicit '(no content)' phrase give a clear context for when this tool is appropriate: metadata-only listing by time window or participants. It does not name alternatives or explicitly state when not to use it, so full when/when-not guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[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.
Persistent, verbatim, searchable memory for AI assistants — one memory across every MCP client.
Personal knowledge graph as an AI memory layer over MCP - read, save, and link your memories.
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
MCP-native notes and memory for ChatGPT, Claude, and other AI tools.
Add one secure layer between your agents and this server.
