Holos33

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety and determinism are covered without the description. The description adds only the scope of topics served, not whether the content is a static snapshot, whether 'free Early Access' can go stale, or how the waitlist link is presented — no context beyond structured fields.

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?

One compact sentence with no filler, front-loading the price and fair-use topics that are most likely to matter. It reads as a topic list rather than a sentence, which is efficient but slightly less scannable than a stated purpose.

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?

An output schema exists, so return-value explanation isn't needed, and the one optional parameter is fully described in the schema. For a read-only content-fetch tool, the description supplies an adequate topical map of what will come back.

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 single optional 'lang' enum is fully documented in the schema itself, so the description adds nothing about it. Baseline 3 is appropriate when the schema does the heavy lifting.

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 enumerates the exact content the tool returns (price/Early Access status, fair-use limits, eligibility, supported wearables, post-Early-Access plan, waitlist link), which makes the resource recognizable. It lacks a verb and doesn't explicitly separate itself from get_faq or get_overview, which could plausibly cover some of these same topics.

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 statement of when to call this versus get_faq, get_overview, or get_page, even though pricing/eligibility questions are prime FAQ material. The agent must infer from the sibling names alone which tool owns a given question.

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 declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds useful return-shape context (Markdown format, publication date, categories, translated URL), but says nothing about long-article pagination or whether missing articles error, and return values are partly covered by the output schema.

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?

A single compact clause with zero padding, and the most useful information (full text, Markdown format) comes first. It is a noun phrase rather than a directive sentence, which slightly weakens how fast an agent can parse the action being taken.

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 an output schema present and annotations covering safety and idempotency, the description does not need to enumerate return values, and all parameters are schema-documented. What is missing is guidance on the multi-part article workflow and sibling selection, which is the only real gap for a read tool of this complexity.

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% with all three parameters documented, including the nl/en enum for lang and the part-number paging. The description only implicitly touches parameters via 'translated version's URL' (lang) and adds no format, default, or edge-case detail beyond the schema, so baseline 3 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 resource ('one knowledge-base article') and what is returned ('Full text ... as Markdown, with publication date, categories and the translated version's URL'), which distinguishes it from the search_content sibling referenced in the schema. It lacks an explicit action verb and does not name the sibling tools it should be preferred over, so it falls short of full differentiation.

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 statement of when to use this tool rather than search_content, get_page, or get_module. The only routing hint ('Article key (slug) from search_content') lives in the input schema, not the description, so the description itself offers no usage guidance.

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 declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered by structured data. The description adds only the scope of content available (official links and company info), with no note on language behavior, result shape, or whether links are grouped by category.

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?

A single compact sentence with no waste, front-loading the resource ('Company details and official links') followed by the enumerated categories. Slightly weakened by the colon-list format lacking an action verb.

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?

Output schema and annotations mean the description needn't explain return values, and only one parameter exists. However, given the heavy sibling overlap (get_faq, get_partner_info, get_privacy_and_data), the description should clarify boundaries, and it does not, leaving genuine selection ambiguity.

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?

There is a single parameter (lang) with 100% schema description coverage including an enum and default, so the schema carries the semantics. The description says nothing about language selection, leaving it to the schema, which is acceptable at baseline but adds no value.

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 enumerates the content returned (waitlist, demo, partner, contact form, FAQ, legal pages) but never uses a verb like 'retrieve' or 'fetch', reading closer to a content label than an action statement. Worse, several listed items (FAQ, legal pages, partner interest) overlap with sibling tools get_faq, get_privacy_and_data and get_partner_info without explaining how this tool differs from them.

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?

No statement of when to use this tool rather than the siblings, and no exclusion of the overlapping FAQ/legal/partner tools. The agent must infer from the name alone which tool to pick for, say, an FAQ question.

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 declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The sentence about omitting answers that conflict with Early Access terms is genuine added context about curation, but the description says nothing about freshness, scope, or whether the FAQ is static or tenant-specific.

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 short sentences, front-loaded with what the tool returns, followed by a caveat that genuinely earns its place. No 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?

An output schema exists, so return values need not be explained, and the two params are schema-documented. The only real gap is routing guidance against the many sibling content getters, which keeps it short of a 5.

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 both parameters (lang enum, topic filter) are fully documented in the schema. The description adds no semantics beyond that, so the baseline 3 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 names the resource precisely ('Frequently asked questions and answers'), so an agent immediately knows it returns curated Q&A content. It does not, however, differentiate itself from topical siblings like get_privacy_and_data or get_contact_and_links, which likely also surface FAQ-style 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?

There is no guidance on when to call this instead of search_content or the topic-specific getters. The only usage-adjacent signal is the schema's optional topic filter, which the description never references.

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 declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds that output is Markdown and bundles related articles, which is useful, but says nothing about unknown-module behavior, rate limits, or fallback when a key doesn't resolve.

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?

A single front-loaded sentence with zero filler; the resource and the payload shape arrive first. Nothing in it needs trimming.

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 an output schema, full param documentation, and annotations present, the description only needs to frame the payload, which it does. Language handling and module-not-found behavior are the remaining gaps, but they are minor given the surrounding structured data.

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%, so both parameters — including the lang enum and the get-from-list_modules hint — are fully documented in the schema. The description adds no parameter-level meaning, which is the expected baseline here.

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?

States a specific resource (one module) and what it returns (full Markdown text plus related knowledge-base articles). It reads clearly as the single-item counterpart to list_modules, though it never names a sibling explicitly.

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?

No indication of when to call this versus list_modules, get_article, or search_content. The only routing hint (module key comes from list_modules) lives in the schema, not the description, so an agent gets no guidance from the prose itself.

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 declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered structurally. The description adds no behavioral context such as response size, caching, or language fallback; it only restates content scope, which the schema and output schema largely carry.

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, no filler; the content enumeration comes first and the routing cue ("Start here") is placed last where it lands as an action. Slightly list-heavy but every listed item adds discriminating information.

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?

An output schema exists and rich annotations are present, so the description needn't explain return values or safety. It fully covers the tool's scope and entry-point role, with only the when-not-to-use guidance left unspecified.

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?

There is a single optional lang parameter with an enum and 100% schema description coverage, so the schema fully documents it. The description contributes nothing about language behavior or default resolution, leaving baseline semantics to 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 enumerates exactly what the tool returns (what Holos33 is, launch status, audience fit, company, six modules, official links), which clearly separates it from get_faq, get_module, and get_article. The verb is implicit rather than stated, but the resource scope is 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?

"Start here" gives a usable entry-point cue, implying this should be called before the more granular sibling tools. However, it names no alternatives or exclusions, so the agent must infer when get_page or list_modules would be the better call.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context — and it does: output format is Markdown, and long pages are split into parts, which is a real behavioral trait an agent must handle. It stops short of saying how many parts exist or how to know the total before calling.

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 short sentences, zero waste, with the primary fact (full page as Markdown) front-loaded and the pagination caveat second. Nothing needs to be trimmed.

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 an output schema present and full parameter coverage, the description needs only enough context to call correctly. It covers format and pagination, but leaves open how many parts a long page has, whether invalid page keys error or return empty, and whether page keys are case-sensitive — minor but real gaps.

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 baseline is 3, but the description adds meaning beyond the schema by explaining why a part parameter exists at all ('Long pages come in parts'). The page key and language parameters remain explained only by 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?

States a specific verb and resource — the full text of one holos33.com page returned as Markdown — and adds scope ('including legal and privacy pages'). It does not name a sibling, though the site-scoped 'one page full text' framing implicitly separates it from search_content and the narrow get_faq/get_privacy_and_data slices.

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 'full text of one page' framing implies bulk page retrieval, but there is no explicit when-to-use or when-not-to-use guidance and no reference to the similar siblings (get_article, get_faq, get_privacy_and_data) that overlap in content. Usage must be inferred.

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 declare readOnly, idempotent, non-destructive and closed-world, so the safety profile needs no restating. The description adds that the response is pitched per audience and includes next-step routes (demo, partner interest), which is useful context, but it says nothing about localization behavior via the lang parameter or the shape of the returned content.

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?

A single efficient sentence with no filler, and the audience scope arrives before the call-to-action clause. It reads slightly like marketing copy rather than a tool contract, but nothing is wasted.

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 an output schema present and annotations covering the safety profile, the description only needs to establish what content is returned and for whom, which it does. The remaining gap is a clear boundary against get_overview and get_access_and_pricing, which would be the difference between a 4 and a 5.

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% with enums for both parameters, so the schema does the heavy lifting and a 3 is the baseline. The description's audience list (coaches and therapists, organisations, research partners, investors) maps onto the enum values but blurs 'professionals' into coaches/therapists, and it never mentions that content language is selectable.

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 conveys that the tool returns audience-targeted content about what Holos33 offers plus next-step calls to action (demo, partner interest). However it is phrased as content copy rather than stating a verb+resource ('returns partner/offering information for a given audience'), and the name 'get_partner_info' is narrower than the four audiences covered, so the purpose is only loosely pinned down.

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 statement of when to use this tool versus siblings such as get_overview, get_access_and_pricing, get_faq, or get_page, even though these overlap substantially with 'what Holos33 offers'. The only implied guidance is the audience dimension, and no exclusions or prerequisites are given.

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 provide a strong safety profile (readOnlyHint: true, destructiveHint: false). The description does not contradict these but primarily adds content scope (GDPR, sub-processor register) rather than technical behavioral traits beyond the baseline security signals.

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 single sentence is highly dense and maximally efficient, providing all necessary context regarding scope and content without unnecessary fluff.

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?

The definition is complete. The description defines the content, the schema defines the input constraints, and the annotations define the behavior/safety, leaving no functional gaps 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?

Since schema description coverage is 100%, the description does not need to compensate for parameter details. It provides no additional meaning for the 'lang' parameter beyond its function in dictating content scope, meeting the baseline 3.

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 is exceptionally clear, specifying the topic (privacy and data handling) and listing key elements (GDPR, controller, links) that distinguish it from general retrieval tools like get_article.

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 specificity of the tool (privacy policies) implies clear usage scenarios, and since there are no direct functional alternatives for this topic, the implied guidance is very strong.

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 declare readOnly, idempotent, closed-world, and non-destructive, so the safety profile is fully covered elsewhere. The description adds that each item has a summary and URL, but that overlaps with the output schema; it discloses nothing new about behavior such as ordering or localization handling.

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?

One compact sentence with zero filler, front-loading the resource and then what each entry contains. Nothing could be removed without losing information.

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?

An output schema exists, so return values need no explanation, and annotations cover safety; the description is nearly sufficient. The only gap is that it doesn't note the fixed six-module scope or how output is affected by the language parameter.

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 single optional 'lang' parameter has a documented enum, so the schema does the work. The description neither mentions the language parameter nor explains that the returned summaries/URLs follow it, adding no value beyond the schema — the baseline 3.

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 names the resource (the six wellbeing modules) and enumerates them, plus says what each entry carries (one-line summary and URL). It is clear what a caller gets back, though the verb ('list') is only implied by the tool name, and the distinction from the sibling get_module is left implicit.

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 explicit 'use this when...' or named alternative, but the phrase 'one-line summary' implies an index/overview tool, which an agent can reasonably contrast with get_module for detail. The guidance is inferable rather than stated.

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 declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds that results are summaries (titles/summaries/URLs) rather than full text, which is useful, but the output schema already documents the return shape, so the added value is 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?

Two sentences, zero filler, with the corpus scope front-loaded and the follow-up tools named second. Every clause 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 search tool with a full output schema, complete parameter documentation and rich annotations, the description supplies the corpus scope and the retrieval workflow. It leaves ranking behavior, language fallback and result-cap expectations unstated, but nothing an agent needs to call it correctly is missing.

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%, so query, lang, limit and types are all already documented in the schema. The description only echoes the content-type dimension and says nothing about language selection, result limits, or query syntax beyond keywords — baseline 3 applies when the schema carries the burden.

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?

States a specific verb ('keyword search') and resource (Holos33 knowledge-base articles, modules, site pages, FAQ), enumerating the full content corpus. It also distinguishes itself from the get_article / get_module / get_page siblings by positioning itself as the discovery step that returns summaries only.

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 routes the agent: use this to find content, then use get_article/get_module/get_page for full text. That is a clear use-then-follow-up flow. It does not state when to skip search entirely (e.g. direct get_faq or get_overview lookups for known items), which is the only missing piece.

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