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, the description must carry the behavioral disclosure. It indicates that the tool returns a list of terms with short definitions and supports filtering, but it does not explicitly state that the operation is read-only, nor does it mention any pagination or ordering behavior. This is adequate but minimal.

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, tightly written sentence split into two clauses. It front-loads the primary action and includes no filler or redundant detail.

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 tool with one optional parameter and no output schema, the description gives a reasonable picture of the response (term name and short definition). However, it lacks explicit detail on return format or ordering, and without annotations, it does not cover all possible context an agent might need.

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 provides complete coverage of the single 'category' parameter, including an enum and a note to omit for the full A–Z index. The description repeats the category names but adds little beyond what the schema states, so it does not significantly enhance parameter understanding.

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's function with the verb 'List' and specifies the resource ('GOJI's plain-English glossary') and scope ('every term, across categories'). This implicitly distinguishes it from the sibling goji_explain_term, which would explain a single term rather than list all.

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 for when to use the tool (browsing the full glossary) and explains the optional filtering by category. However, it does not explicitly mention alternatives or exclusions, such as using goji_explain_term for a specific term, so it falls 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 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?

The description adds useful content context (the five services, client questions) and the response convention to omit slugs. However, with no annotations, it does not address safety, permissions, or return format beyond the content summary, leaving the full burden on the description.

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 that packs a lot of information, including the service list and an output instruction. It is not front-loaded with a verb, but it is efficient and avoids 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?

With one optional parameter and no output schema, the description adequately conveys what the tool covers, but it could be more explicit about the return format and how it differs from the guide-related tools. It is sufficient for a simple retrieval, but not comprehensive.

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 fully describes the 'service' parameter with an example slug and default behavior when omitted. The description adds the list of service names, which helps the agent understand possible slug values, but this is marginal given the schema's already high coverage.

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 lists the five service categories and says 'what each one covers, and the questions clients ask about it,' making clear the tool provides an overview of GOJI's services. However, it lacks an explicit verb like 'returns' or 'lists,' so the action is implied rather than stated, and it doesn't distinguish from 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 the sibling tools, such as goji_explain_term for term explanations or goji_read_guide for guide content. The only instruction is 'Omit the slug for all of them,' which is about response formatting, not 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.