Skip to main content
Glama
Sign In

walkie-mcp

by io.github.adamperlis
OverviewDiscussionsAdmin

List recorded meetings as metadata

list_meetings
Read-onlyIdempotent

List the user's synced meetings, newest first, as metadata only — id, title, date, length, and participants, with no notes or transcript. Page by passing each reply's next_cursor back as cursor until next_cursor is null; that walk returns every meeting exactly once.

Use to build an index of the archive. Do not use when you already know what you are looking for (search_meetings) or when you need notes/transcript for one id (get_meeting).

Does not create, edit, or delete meetings. This is metadata only — it will not return what was said.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_meetings"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax rows to return. Default 50, cap 200.
cursorNoContinue listing: pass the previous reply's next_cursor unchanged.
offsetNoSkip this many meetings. Prefer cursor, which cannot skip or repeat a meeting when one syncs or is deleted while you page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / cursor
      Added value: +{
+  "description": "Continue listing: pass the previous reply's next_cursor unchanged.",
+  "type": "string"
+}
    • changedInput schema / properties / offset / description
      Previous value: -"Skip this many meetings (use with returned total)."New value: +"Skip this many meetings. Prefer cursor, which cannot skip or repeat a meeting when one syncs or is deleted while you page."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: the cursor walk returns every meeting exactly once, and the response is metadata only with no notes or transcript. It also states it does not create, edit, or delete, reinforcing the safety profile rather than contradicting it.

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?

Front-loaded with the core action and return shape, then pagination, then routing guidance. Slightly redundant in repeating 'metadata only' twice, but the repetition serves the critical disambiguation from transcript-bearing siblings.

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?

With no output schema, the description still enumerates the returned fields and the next_cursor field needed to page, and it covers the mutation and content boundaries. An agent has everything required to call and iterate this tool correctly.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains the next_cursor-to-cursor loop and the exactly-once guarantee, which the schema alone does not convey. It does not restate the limit cap or offset semantics, leaving those to 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?

States a specific verb and resource (list the user's synced meetings) plus ordering (newest first) and exact returned fields (id, title, date, length, participants). It explicitly excludes notes/transcript, which separates it cleanly from get_meeting and search_meetings.

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?

Gives an explicit positive case (build an index of the archive) and two explicit negative cases with named alternatives: search_meetings when you know what you want, get_meeting when you need notes/transcript for one id. Nothing is left to inference.

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

All walkie-mcp toolsInspect
Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources