goji

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

With no annotations, the description carries the full burden for behavioral disclosure. It discloses the scope (public answers only), the exact number of answers (61), and the pages covered. It does not detail the output format (e.g., snippet vs full text) or behavior on no matches, but the provided context is meaningful for an agent.

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, front-loaded with the verb 'Search.' Each sentence adds value: the action, the corpus scope, and the ideal use case. No unnecessary verbiage.

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 parameter and no output schema, the description provides adequate context about what it searches, what content is covered, and when to use it. It does not explain the return format, but the simplicity of the tool makes this a minor 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 single 'question' parameter is fully explained in the schema with examples ('cost', 'how long', 'guarantee'), and schema coverage is 100%. The description adds related topics (pricing, timelines) that align with the parameter, but it does not add significant new semantic 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 specifies the action ('Search the questions GOJI has already answered publicly') and the resource (published answers), with concrete examples of topics. It distinguishes from sibling tools by emphasizing the specific corpus (61 answers across home, service, and specialism pages) and the types of questions it answers.

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 states when to use the tool: 'Best tool for "how much", "how long" and "do we need" questions.' This provides clear contextual guidance. It does not explicitly name alternative tools or provide exclusion criteria, but the usage examples are strong enough to guide an agent.

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 full behavioral burden. It signals a safe read operation through 'List' and 'browse', and discloses the return content ('each short definition as well as the name') and the optional category filtering. It does not mention ordering, pagination, or lack of side effects, but these are minor for a simple glossary listing.

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 short sentences that front-load the verb and resource, then provide scope and filter behavior. Every clause adds useful information without repetition or filler.

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?

This is a low-complexity tool with one optional parameter and no output schema. The description adequately explains what will be returned (term name plus short definition) and how to limit results by category, which is enough for an agent to invoke it correctly. The lack of an output schema is mitigated by the explicit return-content description.

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 already fully documents the only parameter, 'category', with an enum of five values and the instruction 'Omit for the full A–Z index'. Schema coverage is 100%, so the description does not need to add parameter syntax. It reinforces the filter behavior but does not add meaning 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 starts with the specific verb 'List' and names the exact resource, 'GOJI's plain-English glossary', with added scope (104 terms across five named categories). This clearly distinguishes it from the sibling tool goji_explain_term, which is for explaining a single term rather than browsing the full list.

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 clearly implies when to use the tool: to browse or filter the glossary. It explains the category filter and the result content. However, it does not explicitly tell the agent to use goji_explain_term for a single-term definition, so it gives clear context but no explicit exclusions or alternatives.

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 available, the description carries the full burden. It discloses that the explanation includes why it matters, how it works, and what to do, that coverage is limited to 104 terms, and that acronyms or full names are accepted. This is fairly transparent, though it doesn't specify behavior for unknown terms or edge cases.

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, information-dense sentence that immediately states the purpose, target domains, output components, coverage count, and accepted input formats. Every clause adds value, and there is no wasted wording.

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 a single parameter and no output schema, the description is highly complete. It explains what the tool does, what the output covers, and the input constraints. The coverage limitation (104 terms) is stated, which is a key contextual detail. No significant gaps remain.

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 'term' parameter, so baseline is 3. The description adds value by specifying that the term can be an acronym or full name and gives concrete examples ('AEO' or 'answer engine optimisation'), which goes beyond the schema's simple 'The term to explain'.

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 'Explain' with a clear resource (marketing/SEO/AEO/web/branding term) and specifies the output format ('plain English, with why it matters, how it works and what to do about it'). It distinguishes itself from siblings like goji_search or goji_browse_glossary by focusing on term definitions rather than browsing or general 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 gives clear context for when to use this tool: to explain a term in GOJI's plain-English style. It also provides format guidance (accepts acronym or full name) and explicitly notes coverage of 104 terms. However, it doesn't explicitly contrast with sibling tools or state when not to use it, 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?

There are no annotations to indicate safety or read/write behavior. The description's only behavioral note—'Omit the slug for all five'—is ambiguous and unexplained, potentially confusing the agent. Without annotations, the description should clarify what the tool does, but it leaves key operational details vague.

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 at two sentences, but the second sentence is cryptic and likely to confuse. The first sentence is front-loaded and informative, but the unclear instruction detracts from overall clarity and structure.

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 no output schema and no annotations, the description should cover what the tool returns and any invocation quirks. It does describe the scope of content (five services, coverage, client questions) but fails to explain the 'omit the slug' instruction or the return format, leaving the agent with significant ambiguity for a 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?

The schema has no descriptions and coverage is 0%, so the description must compensate. It lists the five services with clarifying names (e.g., 'Search + AI Visibility (SEO and AEO)'), which helps map to the enum values. However, it does not explicitly state that the 'service' parameter takes these values or explain the relationship between the list and the parameter.

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 explains that the tool provides an overview of GOJI's five service areas and the questions clients ask about each. This differentiates it from sibling tools like FAQ or glossary lookups, though the action verb ('get', 'return') is implied rather than explicit.

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 implies this tool is for exploring GOJI's services, but it does not explicitly state when to use it over alternatives, nor does it mention when not to use it. There is no comparison to sibling tools like goji_answer_faq or goji_explain_term, leaving the decision to the agent.

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 present, so the description carries the burden of explaining behavior. It clearly states the tool provides a table of contents (a read-only overview) rather than full chapter text, and it gives context about the guide's topic. It does not detail return format, but for a simple table-of-contents tool this is sufficient.

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 core fact (table of contents), then adds the guide's purpose and a pointer to the sibling chapter-reading tool. No wasted 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 no-parameter, no-output-schema tool, the description fully explains what the content is and how to proceed to read chapters. It is self-contained and complements the sibling tool list well.

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 zero parameters and the schema defines no properties. The description adds no parameter-level detail because none is needed; the baseline of 4 for parameter-free tools applies.

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 returning the table of contents for 'Be the Answer', a specific 14-chapter guide. It also distinguishes itself from the sibling tool goji_read_guide_chapter by explicitly directing users there 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?

The description provides an explicit alternative: 'Use goji_read_guide_chapter to read one.' This tells users when to use this tool (to see the table of contents/overview) and when to use another tool (to read an actual 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?

With no annotations provided, the description carries full responsibility. It discloses a useful behavior: 'Omit the slug to list them' indicates an optional parameter and a list-all behavior. However, it does not describe the return format or any other behavioral traits like pagination or response length, leaving some transparency gaps.

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, front-loaded with the core function, and uses only two sentences. It includes essential guide examples and the optional-slug behavior without any fluff, earning 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?

Given the simplicity (1 optional param, no output schema, no annotations), the description is nearly complete. It explains the tool's purpose, lists the guides, and conveys the listing behavior. The only missing piece is an explicit statement of the return value format, but 'Read' implies the guide content.

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 has a single 'guide' parameter with enum values but no descriptions (0% schema coverage). The tool description compensates by naming all seven guides semantically (e.g., 'What does branding cost?' maps to 'branding-cost', 'headless CMS' maps to 'headless-cms-guide') and clarifies the optional/'omit' behavior. This significantly adds meaning beyond the bare slug list.

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's function: 'Read one of GOJI's seven practical guides.' It specifies the resource type (long-form guides) and the scope (seven guides), listing concrete topics like 'How much does a website cost in Australia?' This distinguishes it from siblings such as goji_read_guide_chapter and goji_guide_contents by focusing on full guides.

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: reading a full guide versus a chapter, and the option to 'Omit the slug to list them' acts as a usage hint. It does not explicitly name alternatives or state when not to use this tool, but the context is clear enough relative to 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?

No annotations are provided, so the description must convey side effects and expectations. The verb 'Read' implies a non-mutating safe operation, but the description does not disclose what the response looks like or any error behavior. It adds some context (by number or slug) but is not rich on behavioral traits.

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, each earning its place: the first states the function and scope, the second provides a practical prerequisite. No filler or 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 read tool with one parameter, the description is largely sufficient. It names the resource, specifies the parameter format, and points to a related tool for discovery. The absence of an output schema is acceptable given the simplicity, but a note on return format would make it more complete.

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%, so the parameter 'chapter' is already well-documented. The description repeats 'by number (1–14) or slug' but does not add new semantic meaning beyond the schema, such as slug format 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 states 'Read one full chapter of GOJI's AI-visibility guide' with a specific verb and resource. It also distinguishes this tool from siblings like goji_guide_contents (listing chapters) and goji_read_guide (likely whole guide) by specifying 'one full chapter'.

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 gives an explicit alternative: 'Use goji_guide_contents first if you do not know which chapter you want.' This provides clear guidance for a common scenario, though it does not explicitly contrast with goji_read_guide for whole-guide reads.

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.