goji

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

With no annotations, the description must carry the full burden of behavioral disclosure. It adds useful context about what content is searched (e.g., home page, pricing page, insight articles), but it does not describe the output format, whether it returns full answers or just snippets, or any limitations such as missing answers. This is a moderate gap for a search 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 three sentences, each serving a clear purpose: first states the main function with examples, second details the range of sources, third gives usage guidance. There is no redundancy or fluff, and it is front-loaded with the action verb 'Search'.

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 search tool, the description covers the key aspects: what it does, what content it searches, and when to use it. However, since there is no output schema and no annotations, it does not explain the return value or any caveats, leaving a small completeness gap.

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 fully describes the single 'question' parameter with examples, achieving 100% coverage. The description goes further by listing domain-specific topics (e.g., pricing, timelines, 'what AEO is') that help the agent formulate a meaningful query, adding value beyond the schema's generic examples.

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 tool as a search over GOJI's published answers, with a specific verb ('Search') and resource ('questions GOJI has already answered publicly'). It provides examples of question types and explicitly limits the search to published pages, which differentiates it from a general search tool, though it does not name sibling tools directly.

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 offers clear usage guidance by stating it is the 'best tool for' common question types like 'how much', 'how long', and 'do we need'. It implies when to use this tool over others but does not provide explicit exclusions or name alternative tools, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full disclosure burden. It does state the output shape ('each short definition as well as the name') and the non-mutating verb 'List' implies a read-only operation. It doesn't cover ordering guarantees, behavior for categories with no terms, or how the listed items connect to goji_explain_term, but for a simple browse tool the disclosed behavior is adequate.

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 tight sentences with the verb front-loaded; both sentences earn their place. The category list slightly duplicates the schema enum and the title overlaps with the first clause, but the overall structure is compact and readable.

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 low-complexity tool with one optional parameter and no output schema, the description covers scope, filtering behavior, and return contents. The only real gaps are minor: whether A–Z ordering applies to filtered results and how the list relates to the sibling explain-term 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 coverage is 100% and the parameter carries its own description ('Omit for the full A–Z index'), so the baseline is 3. The description adds a little meaning by stating what filtered output contains (short definitions plus names), but it mostly reiterates what the schema enum already communicates.

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 uses a specific verb ('List') and a clear resource (GOJI's plain-English glossary terms), and names all five category scopes plus the output content. It conveys the browse-and-list function distinctly from the sibling goji_explain_term, though it never explicitly names that contrast, which keeps it one step short of a 5.

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 only usage guidance is implied: browse all terms or filter by category. With a closely-related sibling like goji_explain_term (presumably for explaining a single term) and goji_search available, the description gives no explicit when-to-use guidance, no exclusions, and no pointer to the alternative that handles one-term lookups.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful details about input handling (accepts acronym or full name) and the style of output (plain English with why/how/action), but it does not disclose the return format (e.g., plain text vs. structured) or behavior for unknown terms. This is a moderate disclosure, lacking some specifics.

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 concise: two sentences that front-load the core purpose ('Explain a marketing... term') and then add essential details about coverage and input flexibility. Every sentence earns its place, with 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 single-parameter tool with no output schema, the description covers the key aspects: what it explains, the scope (glossary), input variations, and the structure of the content (why/how/action). It indirectly implies the return content through 'explain... with why it matters, how it works and what to do'. It lacks an explicit statement of return format or error handling, but overall it is sufficiently complete for this simple 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 coverage is 100% (the parameter 'term' is described), so the baseline is 3. The description adds meaning by specifying the domain (marketing, SEO, AEO, web, branding) and mentioning that acronyms or full names are accepted, which goes beyond the schema's simple 'The term to explain'. This added semantic context justifies a 4.

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 explains marketing, SEO, AEO, web, or branding terms in plain English, with specific components (why it matters, how it works, what to do). This is a specific verb+resource combination that distinguishes it from siblings like goji_browse_glossary or goji_search, which focus on browsing or searching rather than explaining a single term.

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 provides clear context: it covers every term in GOJI's plain-English glossary and accepts acronyms or full names, telling users when this tool is appropriate. It does not explicitly mention when not to use it or name alternatives, but the purpose is well-scoped and distinct from siblings, so it meets the 'clear context, no exclusions' bar.

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

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.

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

No annotations are provided, so the description must disclose behavioral traits. It does not state that this is a read-only operation, whether any input is needed, or what the output format will be. The description focuses on the guide's content rather than the tool's behavior, leaving the agent to infer that it simply returns the table of contents.

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 relatively concise and front-loaded with the core purpose ('The table of contents...'). The additional clause about the guide's topics is useful but slightly verbose. The second sentence provides actionable guidance without redundancy.

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 zero-input tool, the description gives enough context about the guide's focus and points to the next step. However, without an output schema, it does not explicitly explain what the tool returns (e.g., a list of chapters, links, or plain text). This leaves minor ambiguity for the agent.

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 tool has no parameters, and the schema coverage is 100% (empty schema). Per the rubric, a 4 is baseline for zero-parameter tools. The description adds context about the resource but no parameter details are needed.

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 tool as providing the table of contents for a specific guide ('Be the Answer'), with a substantive summary of the guide's content. It distinguishes itself from sibling tools by referencing goji_read_guide_chapter for reading chapters.

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?

Explicitly tells the agent to use goji_read_guide_chapter to read a chapter, making the usage context (browse ToC first, then read) clear. This provides an alternative and a when-to-use directive.

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

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.

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.

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.

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

Annotations already indicate a non-read-only action, but the description adds meaningful context: it sends a real enquiry to a specific inbox, requires consent, and warns against inventing details. It provides more behavioral depth than the annotations alone, though it doesn't describe post-send behavior (e.g., confirmation message to user).

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 front-loaded with the core purpose, then transitions to conditions and caveats. Every sentence carries essential information with no filler. Despite being two sentences, it balances completeness with brevity.

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 real-world action tool with 8 parameters and no output schema, the description covers prerequisites, missing-data handling, and confirmation steps. It lacks explicit details on the tool's return value or what happens after sending, but given the exceptional usage guidance, it is nearly complete. Sibling context also makes it clear this is the only action 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 63%, and the description mentions name, email, and 'what they need' (message), but does not clarify optional parameters like budget, company, or timeline. The requirements around asking for missing details and confirming email add some value, but the description mostly reinforces existing schema descriptions rather than adding substantial new semantics.

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 ('send'), the resource ('a real enquiry to GOJI's studio inbox in Melbourne'), and the action's real-world nature. This distinguishes it sharply from sibling tools, which are all informational (FAQ, glossary, guides, search).

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 provides explicit preconditions: the person must have explicitly asked to be put in touch and given their email. It also gives exclusions ('do not call it speculatively') and practical steps (ask for missing details, confirm the email). This is model guidance for when to use the tool.

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