Skip to main content
Glama

Browse Ludo docs

getDocs
Read-onlyIdempotent

Browse or read Ludo's own documentation in full - how to choose a sprite animation mode, when to use Generate Before / Generate After, how margins behave, which model suits a job, and each generator's known limitations. To answer a specific question, call searchDocs first: it returns just the sections that match. Use getDocs to see what documentation exists, or to read a whole document or named sections. This is the same documentation the Ludo web app shows its users, so it occasionally describes buttons rather than parameters; the substance applies to the API and MCP surfaces just the same. To browse, call it with NO parameters to get a table of contents - every document with its id, label and section titles, and no bodies - then call it again with doc (and optionally sections) to read only what you need. Fetching a whole document can return tens of thousands of characters, so prefer naming the sections, using titles copied from the table of contents. Section titles match ignoring case, spacing and punctuation: when only some requested titles exist you receive those sections plus unmatched_sections and available_sections, and when none exist (or doc is unknown) the call returns 400 listing the valid values so you can retry once. This is a free discovery endpoint: it does not charge credits and does not queue a job.

Input Schema

NameRequiredDescriptionDefault
docNoWhich document to read, by id (the table of contents returned by the no-parameter call lists them). Omit to receive the table of contents.
sectionsNoSection titles to return from `doc`, copied from the table of contents (an array of titles; over plain REST, a comma-separated string, where a title that itself contains a comma is still matched whole). Matching ignores case, spacing and punctuation; titles that match nothing are reported back in `unmatched_sections` rather than guessed at. Only valid together with `doc`. Omit to return every section of the document.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / doc / enum
      Previous value: -[
      -  "assistant",
      -  "game-ideator",
      -  "image-generator",
      -  "project",
      -  "account",
      -  "faq",
      -  "3d-generator",
      -  "video-generator",
      -  "sprite-generator",
      -  "audio-generator",
      -  "api-mcp",
      -  "game-asset-generation",
      -  "directional-sprites"
      -]New value: +[
      +  "assistant",
      +  "game-ideator",
      +  "image-generator",
      +  "project",
      +  "account",
      +  "faq",
      +  "3d-generator",
      +  "video-generator",
      +  "sprite-generator",
      +  "audio-generator",
      +  "api-mcp",
      +  "game-asset-generation",
      +  "directional-sprites",
      +  "asset-toolbox"
      +]
  2. Changed1 schema field changed
    • changedInput schema / properties / doc / enum
      Previous value: -[
      -  "assistant",
      -  "game-ideator",
      -  "image-generator",
      -  "project",
      -  "account",
      -  "faq",
      -  "3d-generator",
      -  "video-generator",
      -  "sprite-generator",
      -  "audio-generator",
      -  "api-mcp",
      -  "game-asset-generation"
      -]New value: +[
      +  "assistant",
      +  "game-ideator",
      +  "image-generator",
      +  "project",
      +  "account",
      +  "faq",
      +  "3d-generator",
      +  "video-generator",
      +  "sprite-generator",
      +  "audio-generator",
      +  "api-mcp",
      +  "game-asset-generation",
      +  "directional-sprites"
      +]
  3. Changed1 schema field changed
    • changedInput schema / properties / sections / description
      Previous value: -"Comma-separated section titles to return from `doc`, matched case-insensitively against that document's section titles. Only valid together with `doc`. Omit to return every section of the document."New value: +"Section titles to return from `doc`, copied from the table of contents (an array of titles; over plain REST, a comma-separated string, where a title that itself contains a comma is still matched whole). Matching ignores case, spacing and punctuation; titles that match nothing are reported back in `unmatched_sections` rather than guessed at. Only valid together with `doc`. Omit to return every section of the document."
  4. Added

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 behavior, and the description adds substantial context beyond them: no credit charge, no job queuing, possible 400 with valid values, unmatched_sections/available_sections reporting, and a warning that whole documents can be tens of thousands of characters. It also flags that the docs sometimes describe UI buttons rather than parameters.

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 purpose and the searchDocs alternative are front-loaded, and nearly every sentence carries operational value (TOC flow, size warning, error behavior, credits). It is long for a two-parameter tool and repeats a little of what the schema already states, but the length is justified by the behavioral detail.

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 nonetheless explains the TOC return shape, partial-section matching results, and error behavior. For a read-only discovery endpoint with two optional parameters, an agent has everything needed to call it correctly and recover from bad input.

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: omitting `doc` returns a table of contents, `sections` is only valid with `doc`, matching ignores case/spacing/punctuation, and REST accepts a comma-separated string. Some of this repeats the schema's own descriptions, keeping it short of a 5.

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 ('browse or read Ludo's own documentation in full') and enumerates the kinds of content covered, then explicitly contrasts itself with the sibling searchDocs tool. An agent can distinguish the two without opening either schema.

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?

Explicitly says to call searchDocs first for a specific question and to use getDocs to see what documentation exists or read whole documents/sections. It also names the exact no-parameter TOC flow and the follow-up call pattern, leaving nothing to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.