Skip to main content
Glama

eurorack

by com.eurorackref

Fetch Manual Chunk

get_manual_chunk
Read-onlyIdempotent

Read one manual chunk by id to ground your answer in the manufacturer's documentation — the drill-in partner to get_module's manual_outline. Use it when a claim (voltage range, behavior, calibration step) benefits from the source's own account.

Read the chunk, then answer in your own words and point the user to the source (audit_url) to verify. Paraphrase the substance; do not paste the chunk back as your reply. Quote verbatim only when the exact wording is load-bearing for a specific contested detail, and then only a short phrase. Citation style is SKILL.md §8 (cite-and-point, don't reproduce).

text is capped (~800 chars): enough to ground an answer, not to reproduce the manual. If truncated:true, a " […]" marks the cut and the full passage is at audit_url — send the user there for the rest rather than stitching chunks together to rebuild it.

When to call:

  • You have a chunk_id from get_module's manual_outline that looks relevant to the question.

  • You're writing an answer with specific technical claims and want the source's account to ground (and, if needed, briefly cite) it.

  • The user asked a prose-shaped question ("what does the manual say about X?") — read the chunk, then explain it in your own words with a link to verify.

Prefer get_manual_chunk over search_manual when:

  • You already have the chunk_id from get_module's manual_outline.

  • You want exactly one chunk, not a ranked list.

Returns: { "chunk_id": number, "source_id": number, "source_type": string, // "manual" | "product_page" | "firmware_notes" "source_title": string | null, "heading_path": string | null, // e.g. "Calibration > Tuning Procedure" "text": string, // chunk text, capped ~800 chars; paraphrase, don't paste "truncated": boolean, // true if text was trimmed; full passage at audit_url "audit_url": string // human-readable audit page for the source }

Errors:

  • "Manual chunk not found: " if the chunk_id doesn't exist.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chunk_idYesChunk id from manual_outline[].chunk_id or a search_manual result.

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, the description discloses the 800-char cap, truncation flag with audit_url fallback, and instructs to paraphrase and cite rather than paste. It also documents the error message. This adds substantial behavioral context without contradicting annotations.

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?

Structured with sections (When to call, Prefer, Returns, Errors), bold key rules, and no filler. Each sentence carries intent; the length is justified by the need to prevent manual reproduction.

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?

Covers returns (inline JSON shape), error condition, truncation behavior, and citation policy. With no output schema, the description compensates fully.

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?

Single param chunk_id is described in schema with source info; the description reinforces its provenance from manual_outline[].chunk_id and when to use it. It adds purpose and context beyond the schema's one-line description, though the schema already covers the source.

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+resource: 'Read one manual chunk by id' and frames it as the 'drill-in partner to get_module's manual_outline'. It clearly distinguishes this tool from search_manual and get_module.

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?

Explicit 'When to call' list and a 'Prefer get_manual_chunk over search_manual when' section, naming alternatives and exact conditions. This is textbook usage guidance.

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

All eurorack toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation4/5

Each tool targets a distinct resource/action: get_module(s) for specs, search_modules for filtered queries, resolve_modules for name mapping, find_compatible_with for per-module relations, reachable_pairings/techniques for rack-level analysis. Minor overlap between get_module/get_modules and the relationship tools (find_compatible_with vs reachable_pairings) could cause misselection, but descriptions clarify scope.

Naming Consistency3/5

Mostly verb_noun snake_case (get_, search_, find_, resolve_, visualize_, report_, lookup_), but three tools break the pattern: rack_redundancy, reachable_pairings, reachable_techniques use noun/adjective phrases without a verb. The get_* cluster is consistent but the overall set mixes conventions.

Tool Count4/5

17 tools is slightly above the ideal 3-15 range but justified by the server's broad scope: module specs, search, manuals, relationships, rack analysis, visualization, and feedback. Each tool has a clear role; the count is reasonable for the domain's complexity.

Completeness5/5

The surface covers the full read-only Eurorack knowledge workflow: module lookup (get_module, search_modules, resolve_modules), manual prose (get_manual_chunk, search_manual), concepts (lookup_concept), techniques (search_techniques, find_role_realizations), compatibility (find_compatible_with, reachable_pairings), rack analysis (reachable_techniques, rack_redundancy), visualization, and provenance (get_source). report_gap even enables self-improvement. No obvious missing operations.

Resources