goji_read_guide_chapterRead one full chapter of GOJI's AI-visibility guide, by number or slug. Use goji_guide_contents first if you do not know which chapter you want.
| Name | Required | Description | Default |
|---|---|---|---|
| chapter | Yes | Chapter number, or its slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It clearly states the tool reads a full chapter, implying a read-only, non-destructive action, and specifies the addressing method. However, it does not describe the output format, potential for large responses, or error behavior for invalid slugs/numbers. This is minimal but adequate for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant information. The first sentence states the action and scope, and the second provides a helpful pointer to the prerequisite tool. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool with no output schema, the description covers the key aspects: what it reads, how to specify the chapter, and when to use the companion tool. The only missing context is what the returned chapter content looks like, but that is not critical for selecting this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter as 'Chapter number, or its slug' with 100% coverage, and the description merely repeats 'by number or slug' without adding examples or constraints. Since schema coverage is high, the description adds no semantic value beyond the schema, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'read' and the resource 'one full chapter of GOJI's AI-visibility guide', and specifies addressing by number or slug. It differentiates from sibling goji_guide_contents by implying that tool is for finding the chapter, and contrasts with goji_read_guide which likely reads the whole guide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use goji_guide_contents first if the chapter is unknown, providing a clear alternative and a concrete when-to-use condition. This gives the agent direct guidance for tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Tools map to distinct content types (FAQ, glossary, guide, chapter, service), and descriptions give clear usage cues. goji_answer_faq and goji_search overlap in content coverage, but their intended use cases ('best for how much/how long' vs 'use first when you don't know the page') reduce ambiguity.
Eight tools use the goji_ prefix with a clear verb_noun structure (answer_faq, browse_glossary, explain_term, get_service, read_guide, read_guide_chapter, start_enquiry). goji_guide_contents is a noun phrase and goji_search is a bare verb, so the pattern is not perfectly uniform.
Nine tools is a reasonable, focused set for a content-retrieval and enquiry server. Each tool covers a distinct access pattern—search, list, read, explain, and contact—without bloat.
The surface covers FAQ lookup, glossary browsing, term explanation, service info, guide TOC and chapter reading, and enquiry submission. Agents can navigate from general search to specific pages and then take a contact action, leaving no dead ends.