Skip to main content
Glama
Sign In
LingoChunk MCP

LingoChunk MCP

by lingochunk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List library

list_library

List ready-to-study episodes from your submissions and followed collections, ordered newest first.

Instructions

List the user's ready-to-study episodes (their own submissions plus collections they follow), newest first. Cursor-paginated. Use the returned submission ids with get_transcript / get_audio_url / get_audio_clip.

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_library"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
cursorNoOpaque cursor from a previous page's next_cursor.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description covers pagination behavior and the contents of the list (submissions and collections). It does not mention auth or rate limits, but provides sufficient behavioral context for a listing operation.

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

Conciseness5/5

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

The description is two sentences, front-loaded with the main purpose. Every sentence adds value without redundancy.

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?

No output schema is provided, and the description does not specify the return structure (e.g., contains submissions, next_cursor). It implies the output includes submission IDs, but more detail would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (only cursor has a description). The description mentions cursor-pagination but does not explain limit or cursor format beyond what the schema states. It partially compensates but could be more detailed.

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?

The description clearly states the verb (list), resource (ready-to-study episodes), and scope (user's own submissions plus collections they follow, newest first). It also mentions cursor-pagination, distinguishing it from retrieval tools like get_transcript.

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

Usage Guidelines4/5

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

The description tells the user to use returned submission IDs with related tools (get_transcript, get_audio_url, get_audio_clip). It does not explicitly contrast with list_decks but the context implies different resources.

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

Deploy Server

Other Tools