goji_get_serviceThe four things GOJI does — Search + AI Visibility (SEO and AEO), Websites, AI Builds, and Brand — what each one covers, and the questions clients ask about it. Omit the slug for all of them.
| Name | Required | Description | Default |
|---|---|---|---|
| service | No | Service slug, e.g. "website-development". Omit to list every service line. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does disclose that omitting the slug returns all service lines and that each entry covers client questions. It does not describe output format or explicitly state that the operation is read-only, but for a simple content lookup the gaps are modest.
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 a single compact sentence with the main subject front-loaded. The trailing instruction is slightly awkward but does not waste words.
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 tool with one optional parameter and no output schema, the description gives enough content and parameter behavior for an agent to call it correctly. It lacks explicit output shape and sibling routing, but these are not critical for this simple retrieval 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?
Schema description coverage is 100%, and the schema already documents the service slug and the omit-to-list-all behavior. The description's 'Omit the slug for all of them' reinforces that behavior but adds no new information about valid slugs or output.
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 identifies the resource—the four things GOJI does—and enumerates its contents: Search + AI Visibility, Websites, AI Builds, and Brand, along with client questions. It is specific enough to invoke, though it lacks an explicit verb like 'list' or 'retrieve' and does not contrast with sibling tools.
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?
There is no guidance on when to use this tool versus alternatives like goji_read_guide, goji_answer_faq, or goji_guide_contents. The only operational hint is 'Omit the slug for all of them', which concerns the parameter rather than tool selection.
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.