goji_read_guideRead one of GOJI's practical long-form guides. Includes published Australian pricing: "How much does a website cost in Australia?" and "What does branding cost?". Also covers AEO, headless CMS, engagement models, first AI builds and website relaunches. Omit the slug to list them.
| Name | Required | Description | Default |
|---|---|---|---|
| guide | No | Guide slug, e.g. "website-cost-australia". Omit to list every guide. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the optional slug behavior and lists guide topics, but it does not describe the return format (e.g., full guide content vs. list of titles) or any other behavioral details. This is minimal but not misleading.
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?
Two sentences, front-loaded with the primary action. The second sentence compresses content examples and listing behavior without waste.
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 one-optional-param read tool, the description is nearly complete: it states the action, gives examples, and explains the listing mode. It lacks an explicit statement of return value, but for a read tool this is implicitly the guide content. Sibling differentiation is absent, but that is handled in usage guidelines.
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 schema already explains the only parameter 'guide' with an example and the omit-to-list behavior, achieving 100% coverage. The description merely repeats 'Omit the slug to list them' and provides example guide titles, adding no new parameter detail beyond the schema.
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 tool reads GOJI's long-form guides with a specific verb+resource, and provides example guide titles. It does not explicitly differentiate from sibling tools like goji_read_guide_chapter or goji_guide_contents, though the 'long-form guide' phrasing implies the scope.
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?
It provides clear usage context: use to read a long-form guide, and 'Omit the slug to list them' instructs on listing all guides. However, it does not mention when to prefer sibling tools such as goji_guide_contents for contents or goji_read_guide_chapter for a chapter.
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.