Skip to main content
Glama
Sign In
Foldline

Foldline

by alireza12t
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Read a guide

read_guide
Read-only

Reads Foldline library guides and returns only the requested section, or a table of contents when no section is specified.

Instructions

Reads one of the library guides. Without a section it returns the table of contents only, so you can ask for just the part you need. Guides: agents (how to direct and produce a film), director (story, sound, rhythm, camera, checks), technique (page contract, voice, music, mix), my-styles (making a style your own), tools (every command and flag), instruments (sampled instruments), readme, notice (licences).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "guide": "<guide>"
    },
    "name": "read_guide"
  }
}

Input Schema

NameRequiredDescriptionDefault
fullNoReturn the whole guide. Long; prefer a section.
guideYes
sectionNoHeading text (or part of it) to return, with its subsections.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: the no-section call degrades to a TOC-only response rather than the full document, which prevents an agent from expecting complete content on a bare call. It does not mention output format (markdown, headings, size limits), leaving a modest gap.

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?

Two sentences, front-loaded with the core action and the TOC behavior before the guide catalog. The guide enumeration is long but each gloss disambiguates a real enum value, so it earns its space. Slightly denser than necessary but no wasted framing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only documentation tool with no output schema, the description covers what is returned (TOC by default, a section with its subsections on request) and which guides exist. What an agent still cannot infer is the response format and how large a 'full' read might be beyond the schema's caution that it is long.

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?

With 67% schema coverage, the description meaningfully supplements the enum by explaining what each guide contains ('director (story, sound, rhythm, camera, checks)', 'tools (every command and flag)'), which the schema only lists as bare values. It also reinforces the TOC-versus-section behavior of the optional parameters, though the exact section-matching rule is left to the schema's 'Heading text (or part of it)' note.

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 opens with a specific verb and resource ('Reads one of the library guides') and immediately enumerates the eight valid guides with a short gloss for each, so an agent knows exactly what content domain this covers. This clearly separates it from sibling tools like check_reading or get_style, which operate on user content rather than static documentation.

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?

It gives a concrete workflow hint: calling without a section returns only the table of contents, 'so you can ask for just the part you need.' That effectively tells the agent to do a two-step TOC-then-section read. It stops short of explicit when-not-to-use guidance or naming an alternative tool for related lookups.

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