goji_searchSearch GOJI's published material — the plain-English glossary, the AI-visibility guide "Be the Answer", insight articles and long-form guides. Use this first when you don't already know which GOJI page answers the question. Returns titles, summaries and URLs to cite.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | What to look for, e.g. "AEO", "website cost", "rebrand" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It explains that the tool searches and returns titles, summaries, and URLs, which conveys a read-only, non-destructive behavior. It does not mention rate limits or pagination, but for a search tool this level of transparency is adequate and goes beyond a bare statement of purpose.
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, front-loaded with the primary action, and every phrase adds value: scope of search, usage timing, and return format. No filler or repetition.
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 search tool with no output schema, the description tells the agent what to expect (titles, summaries, URLs), when to use it (first when uncertain), and what it covers. This, combined with the schema, gives a complete picture for correct invocation and expectation setting.
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 covers 50% of parameters: 'query' has a description with examples, while 'limit' has no description but has default/min/max constraints. The tool description adds no parameter-specific information, so it does not compensate for the missing limit description. The schema alone is sufficient for basic understanding, but the description could have added context about how limit affects results (e.g., result ordering).
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 searches GOJI's published material, enumerates the content types (glossary, Be the Answer, articles, guides), and distinguishes itself from siblings by noting to use it first when uncertain. It uses a specific verb ('Search') and resource, making the purpose unambiguous.
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 says 'Use this first when you don't already know which GOJI page answers the question.' This provides a clear when-to-use directive and implicitly defines when not to use it (when you already know the specific page), serving as a strong entry-point guideline among the sibling tools.
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.