Skip to main content
Glama

getDocs

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

TableJSON 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 / 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."
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and executes excellently. It discloses the read-only and free nature ('does not charge credits and does not queue a job'), the exact response structure for the no-parameter call, partial-match behavior via 'unmatched_sections' and 'available_sections', the 400 error with valid values for retries, the case/spacing/punctuation-insensitive matching semantics, and the size warning about tens of thousands of characters.

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 long but dense, with every sentence earning its place: what the tool does, sibling differentiation, a content-parity caveat, the browse workflow, a size warning, matching/error semantics, and cost behavior. It is front-loaded with purpose before details, and the structure flows logically from overview to edge cases.

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?

There is no output schema and no annotations, so the description must explain return values, cost, and failure modes on its own — and it does. It covers the TOC structure (id, label, section titles, no bodies), partial and total failure responses, how to retry once, and the fact that this endpoint costs nothing and queues no job. An agent has everything needed to invoke it correctly across all edge cases.

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 genuinely useful semantics beyond the schema: that the no-parameter call returns a table of contents listing document ids, that sections should be copied from that TOC, that sections is only valid together with doc, and the REST comma-separated string caveat. It also explains the fallback behavior when titles don't match, which the schema does not address.

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 states a specific verb and resource: 'Browse or read Ludo's own documentation in full' and enumerates concrete use cases. It explicitly distinguishes itself from the sibling searchDocs by contrasting behaviors ('To answer a specific question, call searchDocs first' vs 'Use getDocs to see what documentation exists, or to read a whole document or named sections').

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?

The description gives explicit when-to-use guidance, naming the alternative tool and the condition that selects it: 'To answer a specific question, call searchDocs first'. It also provides a concrete invocation workflow (call with NO parameters for the table of contents, then re-call with doc/sections) and a practical rule about preferring named sections over whole-document fetches.

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.