Hilo Studio

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that results are relevance-ranked ('most relevant') and include URLs, but says nothing about result count, ranking method, or behavior when nothing matches — gaps that matter 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?

A single front-loaded sentence: the input ('given a description of what the user needs') comes first and the return payload second. The three examples are illustrative rather than filler, though they make the sentence noticeably long.

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, the description carries the burden of describing returns and does so by enumerating the four content types and noting URLs are included. What remains unstated is result volume and whether the response is a ranked flat list or grouped by content type — minor for a read-only discovery 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%, so the schema already documents both 'need' and 'lang' including the enum and default. The description reinforces the intent of 'need' with concrete examples but adds no constraint detail (e.g. how long/vague a need can be) beyond what the schema states. 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 a specific verb (find) and the exact resource set returned: Hilo Studio services, case studies, Lab experiments and articles, with URLs. It implicitly separates itself from the get_*/list_* siblings, which retrieve by ID or enumeration, but it never addresses the overlap with hilo_recommend, the one sibling that could plausibly do the same job.

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?

Three concrete input examples ('a 3D configurator for furniture', 'a live 3D map for a winery', 'interactive training for engineers') imply when the tool is appropriate: unstructured descriptions of a user's need. However, there is no explicit when-not guidance, no note on using list_services / list_projects for browsing, and no disambiguation from hilo_recommend.

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=true and openWorldHint=false, so the safety profile is covered. The description adds useful content context by disclosing that the response includes the full text and the FAQ, which is beyond what annotations say. It stops short of noting language behavior or that the article must exist.

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 tight sentence with no filler, front-loading the resource and its payload. It is appropriately short for a simple getter, though it is so terse that it omits any routing or usage context.

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?

There is no output schema, so the description helpfully characterizes the return ('full text ... with its FAQ'). Combined with 100% schema coverage for the two parameters and read-only annotations, an agent has enough to call it correctly; only the sibling routing is left implicit.

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% — both slug and lang are fully documented in the schema, including the enum values and the 'use the user's language' instruction. The description adds no parameter detail, so the baseline of 3 applies since the schema carries the full 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 (get) and resource (blog post/article) and scopes it to a single item ('one blog article'), which implicitly separates it from the sibling hilo_list_blog_posts. It also names the payload ('full text ... with its FAQ'), so the agent knows what it gets. It does not explicitly name the sibling it complements, but the read nature 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?

The description contains no when-to-use or when-not-to-use guidance, and no indication of prerequisites. The only routing hint ('from hilo_list_blog_posts') lives in the slug parameter schema, not in the description. An agent gets no explicit instruction that it must first obtain a slug from the list tool.

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=true and openWorldHint=false, so safety is covered. The description usefully discloses what content sections come back (challenge, idea, stack, 3D models, key facts), which matters since there is no output schema, but says nothing about structure, depth, or behavior for unknown slugs.

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 dense sentence with the resource first and the returned content front-loaded. Every clause adds information; 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?

For a simple two-parameter read tool with annotations and a fully documented schema, the description is nearly sufficient, and enumerating the returned sections substitutes for the missing output schema. It stops short of covering failure behavior or how deep the case study content goes.

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%; the lang enum explicitly instructs use of the user's language and the slug documents its enumerated values. The description adds no parameter meaning 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 names a specific verb+resource ('Full case study of one project') and enumerates the contents (challenge, idea, stack, 3D models, key facts). It implicitly distinguishes itself from the listing sibling by scoping to 'one project', though it never names hilo_list_projects 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?

Usage is only implied: an agent infers it should call this when it wants detail on a single project, and the slug's enumerated values point back to hilo_list_projects. There is no explicit when-to-use/when-not or routing to an alternative such as hilo_find_relevant_work.

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=true and openWorldHint=false, so the safety profile is covered. The description adds genuine value by disclosing what the returned write-up contains (what it is, demo usage, what it explores), but says nothing about permissions, caching, or error behavior on an unknown slug.

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 padding, front-loaded with the artifact being retrieved. It is efficient, though the trailing clause list reads slightly like a colon-list enumeration rather than a tight statement.

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 only two parameters, the description's sketch of the return content plus annotations' safety hints are close to sufficient for a simple read tool. It does not explain how to recover from a nonexistent slug, 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?

Schema description coverage is 100% and both parameters are documented in the schema, including the enum for lang and the slug's provenance. The description adds no parameter meaning beyond the schema, so the baseline of 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?

States a specific verb-and-resource pair ('full write-up of one Lab experiment') and enumerates the content it covers (what it is, how to use the demo, what it explores). The 'one' vs. the sibling hilo_list_lab_experiments makes the singular/plural distinction inferable, though it is never named 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?

There is no when-to-use or when-not-to-use guidance in the description. Sequencing is only hinted at indirectly by the schema's slug description ('from hilo_list_lab_experiments'), which the description does not surface or reinforce.

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 establish this is a safe read (readOnlyHint=true, openWorldHint=false), and the description adds substantive context: prices are in EUR, VAT is excluded, and the response covers inclusions, timeline, and custom-work pricing. It stops short of noting freshness/currency of the prices or that no auth is required.

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 enumerating exactly what the tool returns, with no filler. Everything stated 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?

There is no output schema, so the description must preview return content, and it does so concretely (packages, starting prices in EUR excl. VAT, inclusions, timeline, custom work). Slightly more on price currency/freshness or response format would make it fully self-sufficient.

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?

With schema description coverage at 100% and a single well-documented enum parameter (lang), the schema carries the full burden of explaining that the answer language follows the user's language. The description adds no additional parameter meaning, 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 a specific resource (Hilo Studio's packages with starting prices, inclusions, timeline, plus custom-work pricing), so an agent can tell what it returns. It does not explicitly contrast itself with siblings like hilo_get_service or hilo_list_services, which could plausibly cover similar ground.

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 when-to-use guidance, no prerequisites, and no routing to alternatives (e.g., hilo_request_quote for a tailored price). The agent must infer the trigger (a user asking about pricing) purely from the content list.

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=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing what the response contains (description, process, price, case studies, FAQ), which matters since there is no output schema. It does not mention lookup failures for an unknown slug, keeping it short of a 5.

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, and the resource identity is front-loaded before the payload enumeration.

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, describing the returned payload is exactly what is needed, and the description does that. The only gap is behavioral edge cases (missing/invalid slug) for what is otherwise a simple two-parameter read 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%: both slug and lang are documented in the schema, including the enumeration of valid slugs and the language default. The description adds nothing about parameters, 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?

States a specific verb and resource: 'Full detail of one service', and enumerates the fields returned (what it is, how it is done, price, case studies, FAQ). It is clearly the single-item counterpart to hilo_list_services, though the description itself does not name that sibling (the schema's slug description does).

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?

Usage is only implied: an agent infers this is the tool to call when it needs detail on a specific service. There is no explicit when-to-use versus alternatives (e.g. 'call after hilo_list_services to drill into one result' or 'use hilo_get_pricing for pricing alone').

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=true and openWorldHint=false, so the safety profile is covered. The description adds 'newest first' ordering, which is useful context, but says nothing about result count, pagination, or whether the full list is returned at once.

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 front-loaded sentence with the resource first and ordering trailing; no waste. The parenthetical topic list is mildly promotional but does help route topical queries.

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-only list with one optional param this is nearly sufficient, but with no output schema the agent still cannot tell how many posts come back, whether there is pagination, or what fields each item carries.

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 enum parameter ($lang) is fully documented with default and guidance, so the schema carries the burden. The description does not mention the language parameter at all, so a baseline 3 is appropriate.

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 (Hilo Studio's blog articles) plus topic scope and ordering ('newest first'), so an agent can tell it apart from the singular hilo_get_blog_post sibling. It never explicitly says 'list all' or contrasts itself with the getter, leaving that distinction to be inferred from the name.

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?

Usage is implied — browse the blog index, then presumably fetch a single post with hilo_get_blog_post — but no sentence says when to use this versus alternatives or what conditions favor it. 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 already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful content context — that each experiment has a live demo and spans WebGL, shaders, AR, and courses — but says nothing about result count, ordering, or whether demos are external links. No contradiction with annotations.

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, front-loaded with the resource name, with no wasted words. It reads slightly like marketing copy ('push interactive 3D') rather than operational instruction, but the structure is efficient.

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-parameter, read-only list tool with no output schema, the description covers what the collection contains but not what a caller receives (fields, count, pagination) or how it differs from the sibling getter. Adequate but with clear 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 description coverage is 100% for the single 'lang' enum parameter, which already explains the 'en'/'es' values and the instruction to use the user's language. The description adds nothing about language handling, 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 explains what Hilo Studio's Lab experiments are (WebGL, shaders, AR demos) but never states the verb the tool actually performs — it never says it returns a list of experiments. The name and title carry that meaning; the description itself is descriptive of the domain rather than the operation, and it does not distinguish itself from the sibling hilo_get_lab_experiment.

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 guidance on when to call this versus hilo_get_lab_experiment (single experiment) or hilo_find_relevant_work. There is no mention of prerequisites, expected context, or exclusions. The agent must infer usage entirely from the name.

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=true and openWorldHint=false, so the safe-read profile is covered. The description adds useful value by disclosing the return shape (sector, type, services, live URL, case-study URL), which matters since there is no output schema. It says nothing about pagination, ordering, or volume of projects returned.

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 filler, and the subject (the portfolio) is front-loaded. It is a noun fragment rather than a sentence, which slightly weakens the framing of the action.

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-required-parameter, read-only listing tool with no output schema, the description is nearly sufficient -- it effectively substitutes for the missing output schema by naming the returned fields. Only the absence of any routing guidance against its many siblings leaves a 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?

Schema description coverage is 100% -- the single lang enum parameter is fully documented in the schema, including its default and the instruction to match the user's language. The description contributes nothing about parameters, 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 identifies the resource clearly ("Portfolio of Hilo Studio" projects) and enumerates the fields each entry carries, so an agent knows what it gets back. However, the verb is only implied -- it never explicitly says it lists all projects nor distinguishes this from siblings like hilo_find_relevant_work or hilo_studio_overview.

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 when-to-use guidance and no reference to any alternative. With eleven siblings including hilo_find_relevant_work (project lookup) and hilo_studio_overview, the agent gets no help deciding when to call this one instead.

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=true and openWorldHint=false, so the safety profile is settled. The description adds useful scope context by naming the fields returned per service, but says nothing about result size, ordering, or whether the list is paginated or cached.

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 filler. The resource scope and return contents lead, and the sibling routing is placed last where it belongs.

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 read-only, zero-required-parameter list tool with no output schema, the description supplies the two things an agent most needs: what comes back (summary, starting price, URL) and where to go for depth (hilo_get_service). Nothing material 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% and the single lang parameter is fully documented in the schema, including the enum values and the 'use the user's language' instruction. The description adds nothing about the parameter, 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?

States a specific verb and resource ('All services Hilo Studio offers') and immediately enumerates what each entry contains (summary, starting price, URL). The final clause distinguishes it from the sibling hilo_get_service, so an agent can separate list vs. detail without opening either schema.

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 names the alternative ('Use hilo_get_service for the full detail of one') and states the condition that selects it. The boundary between browsing the catalog and drilling into a single service is unambiguous.

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?

readOnlyHint=true is consistent with the flow described, and the description adds behavior beyond the annotations: it discloses the return payload (next question with options, or recommendation + starting price + timing + related case) and states 'no personal data needed', which reassures on privacy. It stops short of describing idempotency or how partial-answer state is handled across calls.

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?

Front-loaded with the core identity in the first clause, then call semantics, then return shape, then interaction rules — a sensible order. It is a dense run-on paragraph with some agent-behavior instructions that could be tightened, but no sentence is 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?

With no output schema, the description carries the burden of describing returns and does so explicitly across both states (question-in-progress vs. completed recommendation). Combined with 100% schema coverage and read-only annotations, an agent has everything needed to invoke and continue the flow correctly.

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 real meaning: the parameters are a cumulative record of answers given so far, all optional, and price_fit is a second-turn parameter only relevant after a price is shown. It also flags the objective→situation option dependency, though that detail is largely duplicated from 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 states a concrete resource and mechanism: a three-question guided-contact flow (goal, blocker, timing) that returns the next question or a recommendation bundle. It implicitly but clearly separates itself from siblings like hilo_get_pricing and hilo_get_case_study by bundling price plus a related case into a single personalized answer, and from hilo_request_quote by being read-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?

It gives explicit call semantics ('Call it with whatever the user has answered so far', all optional) and sequencing rules (ask ONE question at a time, optionally follow with price_fit). What it lacks is any exclusion or named alternative — it never says when not to use this versus hilo_request_quote or hilo_get_pricing.

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 flag a non-read-only, open-world, non-idempotent write. The description adds real context beyond them: the enquiry reaches the team by email, the reply window is 24 h, the user receives a confirmation email, and an explicit consent precondition exists. It stops short of stating rate limits, failure/partial-failure behavior, or whether the submission can be recalled.

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 what the tool does and immediately followed by the hard precondition. No filler, and the most safety-critical instruction (explicit confirmation) is given last-sentence prominence.

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 13-parameter outbound write with no output schema, the description covers the essentials: consent, data sourcing, and the observable outcome (email + confirmation). It does not say what the tool returns on success/failure or how to proceed if the user has only partially answered the questionnaire, which would round out completeness.

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 the schema already documents all 13 parameters including enum meanings and the const-true constraint on user_confirmed. The description only reinforces that name and email must come from the user; it adds no format or interaction detail (e.g. how objective/situation enums pair with hilo_recommend) beyond what the schema and annotations supply.

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 ('Sends a project enquiry to Hilo Studio') plus the delivery channel (email to the team). This clearly distinguishes it from the sibling read tools (list/get/find/recommend), which all retrieve information rather than submit it.

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 gates invocation: 'ONLY call this after the user has explicitly confirmed' and 'has given their name and email', plus an exclusion ('Never invent contact details'). An agent knows both the precondition and the failure mode without reading the schema.

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 readOnlyHint=true and openWorldHint=false already declared, the safety profile is covered by annotations. The description adds the useful fact that this is a broad static-info retrieval, but says nothing about response shape, caching, or whether the answer is canned vs. assembled.

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 scope comes first and the call-first instruction is front-loaded last as the actionable cue. 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 zero-required-param overview tool with annotations covering safety and no output schema, the enumerated coverage list effectively stands in for a return-value description. Only minor gaps remain, such as whether the overview can be narrowed by topic.

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 lang parameter already documents its enum and the 'use the user's language' rule, so the schema carries the burden. The description does not mention lang at all, adding no meaning beyond structured data — 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 (Hilo Studio) and enumerates the exact content covered — what it does, location, languages, how it works, awards, contact. That is far more specific than a tautology, but it never explicitly contrasts itself with siblings like hilo_get_service or hilo_get_pricing, so an agent must infer the boundary.

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?

'Call this first for general questions' is an explicit routing rule that tells the agent when this tool wins over the more specific get_/list_ siblings. It stops short of stating when NOT to use it (e.g. for a single service or post), so it is clear context without explicit exclusions.

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