Skip to main content
Glama

voicememos_markers

Extracts sentences tagged with spoken marker words (e.g., "Idea:") from voice memos, with optional date-range, label, and result-limit filters.

Instructions

Sentences the user tagged by starting them with a spoken marker word (e.g. "Idea: ...").

Args: since: only memos recorded on or after this date (YYYY-MM-DD). until: only memos recorded on or before this date (YYYY-MM-DD). label: only this marker label. limit: maximum number of markers returned.

Input Schema

NameRequiredDescriptionDefault
labelNo
limitNo
sinceNo
untilNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.6

TDQS

B3.1/5.0
Behavior2/5

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

No annotations exist, so the description carries the full behavioral burden, yet it never states that this is a read-only operation, whether results are ordered, how pagination beyond the limit behaves, or what the output records look like. The marker concept is explained, which is useful, but core behavioral traits are absent.

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

Conciseness4/5

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

The core definition is front-loaded in a single sentence with a concrete example, followed by a tightly formatted Args list. No wasted sentences, though the concept sentence could state the retrieval action more explicitly.

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?

With no output schema and no annotations, the description should say more about the return shape, ordering, and pagination. It explains what markers are and how to filter, which is adequate minimum context for a simple query, but not complete.

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?

Schema description coverage is 0%, so the description must compensate, and it does define all four parameters with useful meaning: since/until bounds with YYYY-MM-DD format, label as a filter, and limit as maximum markers returned. The default limit of 50 is not stated, and case-sensitivity of label is unspecified, keeping it from a 5.

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

Purpose4/5

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

The description clearly identifies the resource: sentences the user tagged with a spoken marker word, with an illustrative example. It distinguishes itself from siblings like voicememos_list or voicememos_search by being specifically about tagged markers, though the retrieval verb is only implied rather than stated.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus voicememos_list, voicememos_search, or voicememos_read. The agent must infer from the name and the marker concept alone. No prerequisites or exclusions are stated.

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