star365 HQ

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 the meaningful extra that no authentication is required, which annotations do not express, though it omits any caching or data-freshness notes.

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 line, front-loaded with the resource and metric, plus a bilingual restatement. The duplication is mild, but the sentence earns its place and stays tight.

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 params, no output schema, and annotations covering the safety profile, the definition supplies what an agent needs: what the funnel returns and that no auth is required. It could be slightly richer with temporal or channel-scope hints, but it is largely 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?

There are zero parameters, so the baseline is 4. The description correctly implies no inputs are needed by framing the tool as a plain funnel readout.

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 (acquisition funnel) and the exact metrics returned (clicks and signup conversion per channel). The Korean translation reinforces the same meaning without adding noise.

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 when-to-use or when-not-to-use guidance and no named alternatives among the many sibling tools. Usage is only implied by the funnel framing, leaving the agent to infer where it fits versus related member/fleet/status 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 declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses the date-omission default (today in shop timezone) and the critical constraint that only returned starts_at/staff_id values may be passed to booking_reserve (invented times rejected).

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 front-loaded English portion is tight and well ordered, but the entire message is restated in Korean, which doubles the length for an agent that reads a single language. The redundancy keeps this from being maximally concise.

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?

No output schema exists, but the description partially compensates by noting the returned fields (starts_at, staff_id) that must be forwarded. Combined with the required-parameter rule and date default, an agent has enough to call and chain the tool 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 description coverage is 100%, so all five parameters are already documented, including the date default and service sourcing. The description largely restates this (service required, date default) rather than adding new syntax or constraints, so it sits at the baseline.

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 ('List bookable time slots') and even names the underlying action (action=booking.availability). It is clearly distinguishable from booking_menu (source of service id) and booking_reserve (consumer of the output).

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?

Gives an explicit workflow: obtain 'service' from booking_menu first, then call this tool, then pass the results to booking_reserve. Both the prerequisite and the downstream consumer are named, so the agent knows exactly where this fits.

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 and destructiveHint=false, so the safety profile is covered. The description adds 'no money moves' and the internal action name, which are mildly useful, but it does not describe return shape or any access constraints.

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 behavior and then the routing rule in a compact form. The bilingual duplication and the internal action= token add minor noise but no real bloat.

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 listing tool with full schema coverage and no output schema, the description covers what is returned (services and staff) and when to divert to booking_reserve. It stops short of describing the item structure returned, but the essentials are present.

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 only two parameters (slug, agent_id), both documented in-schema. The description adds no syntax, format, or constraint detail beyond what the schema already provides, 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 ('List what can be booked at a shop') with the scope of what is returned (services and staff). It further distinguishes itself from siblings by naming booking_reserve and the class-session flow, so an agent can route without opening other schemas.

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: appointment-kind services go to booking_reserve, class-kind to a separate group flow. That is clear when-to-use guidance. However the class alternative is never named, leaving that branch to inference.

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 only say it is not read-only and not destructive; the description adds the consequential facts: no money moves, but a REAL appointment is placed and the person's name and phone are handed to the shop, and no confirmation SMS is sent from this path. These are precisely the side effects and user-communication constraints an agent cannot infer from 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?

Front-loaded with the highest-stakes fact (a real appointment is placed) and the hard precondition. The bilingual English/Korean duplication roughly doubles the length, which is defensible for a bilingual context but is redundancy for a single-language reader.

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 mutation tool with no output schema, the description covers preconditions, side effects, and communication caveats thoroughly. Its one gap is that it never indicates what the call returns (e.g., a reservation/booking id) for follow-up, which matters for an irreducible write operation.

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 baseline is 3, but the description goes beyond the schema by explaining the semantic gate on user_confirmed (only set true after confirmation) and the provenance requirement for starts_at and staff (values from booking_availability, unchanged). It adds real meaning rather than restating 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 ('Create a real reservation') and even names the underlying action (action=booking.reserve). It is clearly distinguishable from siblings like booking_availability and booking_menu, which are read/lookup tools. An agent knows exactly what this tool does without opening the 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?

It supplies the key precondition (only call with user_confirmed=true after the person confirmed date, time, staff and service) and ties two parameters to an upstream sibling ('starts_at and staff MUST be values returned by booking_availability'). It does not explicitly route the agent to the alternative tool for merely checking slots, so the when-not story is implied 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 destructiveHint=false and openWorldHint=false; the description adds risk framing ('low risk, action=commerce.quote'), the guarantee that no business transaction is committed and no money moves, and the exact return payload. There is a mild tension between 'nothing is written' and readOnlyHint=false — a quote record is in fact created server-side — but this is a wording nuance rather than a material contradiction.

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: the capability and its safety profile come first, then the checkout handoff. Sentences are tight in English, though the full bilingual restatement roughly doubles the text without adding information for an English-reading agent.

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 correctly carries the return contract (quote_id/quote_hash, live stock and price snapshot) and the downstream usage rule. Combined with annotations covering the safety profile and a fully documented schema, an agent has everything needed to call this tool and use its result.

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 all five parameters (items, shop_id, agent_id, payment_mode, idempotency_key) are documented in the schema, so the baseline is 3. The description mentions quote_id/quote_hash but those are outputs, not inputs, and it adds no further semantics for idempotency_key, payment_mode, or shop_id inference beyond what the schema already states.

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 (build a cart quote) plus the exact scope (snapshot of live stock and price) and the returned identifiers quote_id/quote_hash. It explicitly distinguishes itself from the sibling commerce_checkout by naming it as the next step for payment, so an agent can route 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?

Gives an explicit when-to-use (to obtain a quote before paying) and names the alternative with the condition that selects it: 'To pay, pass the returned quote_id and quote_hash to commerce_checkout unchanged.' The handoff contract between the two tools is spelled out, including that the values must not be altered.

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?

Goes well beyond the annotations: it discloses the approval-queue fallback, that the server recomputes quote_id/quote_hash and rejects mismatches, and the no-retry/dedup rule on timeout. These are behavioral traits an agent could not infer from readOnlyHint/idempotentHint alone.

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?

Every sentence is load-bearing and the highest-severity warning (HIGH RISK, confirmation) is front-loaded. The Korean mirror text roughly doubles the length, which is a convention but costs some density.

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 high-risk mutation with no output schema, the description covers confirmation gating, the approval-queue branch, tamper rejection, and duplicate-order avoidance on timeout. Nothing an agent needs to invoke it safely 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 coverage is 100%, so the schema baseline is 3, but the description adds real meaning: quote_hash is a tamper guard the server recomputes, user_confirmed gates the write vs. approval queue, and idempotency_key replays the first result. This enriches the semantics of the most consequential parameters beyond the schema text.

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 ('Create an order') and immediately characterizes the risk class ('HIGH RISK, action=commerce.order'). It implicitly but clearly separates itself from commerce_build_cart (source of the quote) and commerce_order_status (post-timeout polling).

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 says when not to call it ('Do not call it without explicit confirmation from the user'), what happens with user_confirmed=false (approval queue), and names the alternative action on timeout (query commerce_order_status with the same idempotency_key). Prerequisites (quote_id/quote_hash from commerce_build_cart) are also 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 genuinely new behavioral context: this is a post-timeout reconciliation/confirmation read that reports existence, amount, and state, which is what an agent needs to decide whether to retry a checkout.

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 action and its purpose, then the timeout guidance, then a Korean mirror of the same content. The bilingual duplication is redundant for a single-language agent but the sentences themselves are tight and every English sentence 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 carries the return-value burden and does so: it names the three things the call confirms (created or not, amount, state). Combined with 100% parameter coverage, an agent has everything needed to call and interpret this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds lookup semantics the schema does not: resolution works via either order_id or idempotency_key. Minor tension exists because the description implies either key suffices while the schema marks order_id required, but the added lookup meaning is real.

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 ('Check order status') and enumerates exactly what it resolves: whether an order was created, for how much, and in what state. The '(read, action=commerce.order_status)' tag plus the explicit contrast with re-ordering makes it distinguishable from commerce_checkout and commerce_build_cart.

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?

Gives a concrete trigger condition: 'Use this instead of re-ordering when an order request timed out.' That is a real when-to-use rule pointing at the alternative behavior (re-ordering). It does not name a sibling tool or state any when-not case, so it falls short of full routing 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, and destructiveHint=false, so the safety profile is largely covered. The description adds value beyond that by stating no money moves and that the call executes as action=commerce.search through the Guardrail, plus the rejection rule for empty inputs. It stops short of describing rate limits or result ordering.

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 and short, with the core constraint stated early. The bilingual repetition (English then Korean) doubles the text for the same content, which is mildly wasteful, but the whole description is still compact and every sentence carries a rule.

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 an 8-parameter read-only search with no output schema, the description covers the operation, the Guardrail routing, and the key input constraint. It omits any hint of return shape or pagination behavior (cursor is only explained in the schema), which is a minor gap rather than a blocking one.

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 baseline is 3. The description adds a genuine constraint the schema does not express — the schema lists required: [] but the description enforces at-least-one of q or category — which is meaningful semantics beyond the structured fields.

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 ('Search shop products or browse a category') and clarifies the dual mode of operation. An agent can immediately distinguish this from siblings like commerce_build_cart, commerce_checkout, or commerce_order_status without opening any 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?

Gives an explicit precondition: at least one of q or category must be supplied, and category-only browsing is allowed while both-empty is rejected. It does not, however, route the agent toward or away from any sibling tool for adjacent tasks such as building a cart after searching.

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 (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds real value beyond them by disclosing data provenance and boundaries: content comes from missions with source=wrs-auto, and internal guidance/infrastructure details are deliberately excluded. It still says nothing about freshness, pagination, or volume, so it is not 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?

Scope is front-loaded and the content list is compact. The bilingual restatement of the exclusion clause is mild redundancy, but each clause still carries meaning for its audience. No wasted framing 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?

With no input parameters and no output schema, the description carries the burden of conveying what comes back, and it does so concretely (policy items plus wrs-auto learnings) while bounding the scope. An agent knows enough to invoke it correctly; a brief hint about recency or output shape would make it 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. No parameters are undocumented.

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 ('company memory, public scope') and enumerates the content returned: publishing/wording policy (disclaimers, no-overclaim rule, political-content approval gate) and auto-accumulated learnings. An agent can tell this is a read of a curated memory store rather than a general search. It lacks an explicit verb ('retrieve'/'read') and does not distinguish itself from any named sibling, keeping it below a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No statement of when to call this versus alternatives such as members_north_star, hq_health, or server_status. The only routing hint is the negative scope ('internal guidance and infrastructure details are not included'), which tells the agent what it will NOT get but not what situation warrants invoking it.

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds what data is aggregated, but it does not disclose behavioral details such as data freshness, auth requirements, or caching behavior.

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 main description is a single front-loaded sentence with no filler, followed by a short bilingual title. It is dense with useful data categories but remains appropriately sized for a no-parameter status tool.

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 input parameters, the description carries the burden of explaining what is returned, and it does so by listing crew definitions and specific run aggregates. It lacks exact output structure or time-range scope, but is largely complete for an informational status endpoint.

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 takes zero parameters, so there is no parameter semantics to explain. Per the scoring guidance, zero parameters establish a baseline of 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource (WRS multi-agent crew status) and enumerates two clear data families: crew definitions and real run aggregates. It is more than a restatement of the name, but it does not differentiate itself from any sibling tool.

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 when-to-use guidance, no conditions, and no alternatives named among the many sibling tools. Usage is only implied by the status-reporting nature of the 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful scope context (fixed fleet of six named servers, no parameters), but says nothing about return contents or freshness.

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 English portion is a single front-loaded sentence with no waste. The Korean line restates the identical information and does not earn its place for an agent that already parsed the first sentence.

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 parameters, the description carries the burden of describing what the summary contains, and it does not — it never says which metrics or fields are returned. For a zero-arg read tool this is adequate but leaves the return value opaque.

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 takes zero parameters, so the baseline is 4. There are no parameter semantics to clarify, and the description correctly implies nothing is configurable.

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 (a 6-server fleet) and enumerates its members, which is concrete. However, 'Summary' is a vague verb, and nothing distinguishes it from siblings like server_status or hq_health, so an agent cannot tell what kind of summary this is or how it differs.

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 versus server_status, hq_health, or crew_status. The fixed scope (6 named servers) is implied but no condition or alternative is 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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuinely useful context beyond them: a prompt-injection warning that returned content is third-party data rather than instructions, plus the semantic shape of the return (proposals/reviews annotated with applied, awaiting approval, ...).

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-loads purpose, then usage, then the security warning — good ordering. However the entire content is duplicated in Korean, roughly doubling length without adding new information for a reader of either language.

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?

No output schema exists, and the description compensates by describing what is returned (proposals, reviews, and their handling statuses). Combined with the annotations covering safety and the fully documented schema, an agent has everything needed to call it 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 description coverage is 100%, so both parameters (limit default/max, platform host example) are already documented in structured data. The description adds no parameter-level detail, 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?

States a specific verb ('Read') and resource ('the guestbook of a star365 platform') and further specifies the content type: improvement proposals and reviews left by other AI agents with their handling status. This clearly distinguishes it from the sibling guestbook_post (which writes entries).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells the agent when to call it: 'Read this first so you do not file the same proposal twice,' which establishes ordering relative to guestbook_post. It stops short of naming guestbook_post directly or stating exclusions, but the usage context is clear.

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 this is a non-read-only, non-idempotent write, so the safety profile is covered. The description adds real behavioral value beyond that: posted content is auto-classified, fed into improvements, and returns an outcome as a guestbook reply. It omits auth requirements and rate limits, but the async-reply lifecycle is a meaningful disclosure.

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 purpose is front-loaded and the size is reasonable. The full bilingual repetition of every sentence into Korean roughly doubles the length without adding information for an English-reading agent, which is minor redundancy rather than confusion.

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, and the description compensates by explaining that the outcome arrives later as a guestbook reply. Combined with the annotated write semantics and fully documented parameters, an agent has enough to call this correctly, though the lack of auth or failure behavior keeps it short of 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 description coverage is 100%, so all six parameters (platform, title, body, kind, rating, agent_name) are already documented in the schema itself. The description adds no syntax, format, or constraint detail 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?

The description states a specific verb+resource: leaving an improvement proposal, review, or defect report on a star365 platform. It clearly separates this from a read-only listing sibling (guestbook_list) by framing it as a submission action, though it never names that 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?

It gives content-level guidance (write concretely about what was awkward or where you got stuck while using the platform), which implies the intended context, but it offers no explicit when-to-use vs. when-not, no prerequisites, and no routing to guestbook_list for reading existing entries.

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, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds the concrete scope of services checked, but does not disclose return format, auth requirements, or rate limits.

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 bilingual statements, front-loaded with the resource scope. Every word earns its place and no structural waste is present.

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 parameterless, read-only health-check tool whose annotations cover the safety profile, the description identifies what is being checked well enough to invoke it correctly. It omits return-value details, and no output schema exists to carry them, but this gap is minor for a simple health probe.

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?

Zero parameters are defined, so the baseline of 4 applies. The schema is empty and fully described, so no additional parameter semantics are required.

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 the specific resource (star365 HQ and Langfuse core services) and implies a health-check verb. It distinguishes itself from generic siblings like server_status by naming the exact services, though it does not explicitly contrast with any alternative tool.

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 when-to-use, when-not, or alternative-tool guidance is provided. The context of a health check is only implied by the word 'Health' and the service names.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds essentially nothing beyond that — it restates the resource and does not explain ordering/fallback semantics of the 'chain', freshness, or environment scope.

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?

Very short and front-loaded with the core noun phrase, with no filler. The only inefficiency is the identical content repeated in English and Korean, which doubles length without adding information for a single-language reader.

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 the return shape, and it only says 'provider chain' without clarifying whether the result is an ordered fallback list, names only, or includes health/status. For a simple no-arg read tool it is minimally adequate, but the return structure remains ambiguous.

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 takes zero parameters, so there are no semantics to document and the baseline is 4. The description correctly implies a no-argument, whole-list retrieval.

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 (the MCO LLM router's available provider chain), which tells an agent exactly what data comes back. It does not, however, distinguish this tool from the sibling llm_route_stats or video_providers, so the agent must infer which router-related tool to pick. Clear but undifferentiated.

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 llm_route_stats or video_providers, and no prerequisites or context are given. The agent is left to infer usage entirely from the name and resource phrase.

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, so the safety profile is covered. The description adds the metric vocabulary (success rate, latency, cost), but says nothing about the time window covered or whether the data is cached/real-time.

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 short sentence with the metrics front-loaded and no padding. The duplicated Korean rendering is redundant for a single-language consumer but not harmful.

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-parameter read tool with no output schema, the description should at minimum state the aggregation window (all-time? rolling?) since no parameter can narrow it. It names the metrics but leaves the scope of the data undefined.

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 takes zero parameters, so there is nothing for the description to disambiguate; the 4 baseline applies. The listed metrics are return values rather than parameter semantics, so they add no parameter-level meaning.

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?

Names the resource (MCO LLM router) and the unit of aggregation (per provider) plus the three metrics returned, so an agent can distinguish it from llm_providers. It is clear but never explicitly positions itself against that sibling.

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 llm_providers, acquisition_stats, or any other stats tool. The agent must infer the selection criteria from the name 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, idempotentHint and destructiveHint, so the safety profile is covered. The description adds value beyond that by mapping to the underlying action (action=members.lookup) and by interpreting the result ('found=false means they are not a member yet'), though it does not describe pagination, rate limits, or error behavior.

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 critical instruction ('ALWAYS call this before registering') and the read-only note are front-loaded, which is the right ordering. The fully duplicated Korean text adds length without new information for a single reader, a minor cost against an otherwise tight 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, the description correctly steps in to explain the return semantics (found=false). Combined with the read-only flag, action id, and 100%-covered two-parameter schema, an agent has enough to call it correctly; only error/edge-case handling is left unstated.

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 (email, agent_id) are documented in the schema, including the audit-trail purpose of agent_id. The description adds no parameter-level detail beyond the schema, 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: checking whether a 'star365 unified member' exists for a given email. It also pins down the scope precisely enough to separate it from member_register and members_cross_platform, which the sibling list shows are distinct operations.

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 instructs 'ALWAYS call this before registering' and explains why (avoiding duplicate person creation in delegated signup). This gives the agent both the trigger condition and the failure mode it is guarding against, which is the strongest form of when-to-use 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?

Goes well beyond the annotations (which only say not-readonly, idempotent, non-destructive): it discloses that a REAL account is created under the email, that no money moves, that user_confirmed is enforced, and that channel/member key are server-decided. This is exactly the information an agent needs before committing a write.

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?

Purpose and the critical consent gate are front-loaded, and every sentence earns its place. The bilingual Korean text is a near-verbatim repetition of the English, which adds length without new information, holding it below a 5.

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 registration mutation with five params and no output schema, the description covers the consent prerequisite, the idempotent return behavior, and the server-controlled fields. Nothing an agent needs in order to invoke 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 coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it explains why user_confirmed is mandatory and that anything other than true is rejected, and clarifies that channel/member key are deliberately absent as arguments. It reinforces rather than duplicates 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+resource ('Register a star365 unified member') and even names the underlying action (action=members.register). This distinguishes it cleanly from read-only siblings like member_lookup and members_summary without opening any 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?

Gives clear preconditions: consent must be obtained via the privacy URL before setting user_confirmed=true, and it explains that already-registered people get the existing member back rather than a duplicate. It doesn't explicitly name a sibling alternative (e.g. member_lookup) but the usage context 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds only the metric definition and nothing about scope, time window, or return shape, so it neither enriches nor contradicts the structured metadata.

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?

Extremely short and front-loaded, with the metric stated immediately. The bilingual duplication is redundant for a token-sensitive agent but serves legitimate localization and costs little.

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-parameter, no-output-schema stat tool, the description is minimally adequate: it names the metric but says nothing about the time range, segmentation, or form of the returned number, which an agent might reasonably need before invoking or interpreting it.

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 takes zero parameters, so per the rubric the baseline is 4. There are no parameter semantics to clarify and the description correctly implies a no-argument aggregate query.

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 metric (count of members who signed up on more than one platform), which is concrete and identifiable. It does not, however, differentiate itself from siblings like members_summary or members_north_star, leaving the agent to infer which stats tool to pick.

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 no when-to-use guidance, no prerequisites, and names no alternative despite several sibling stats tools (members_summary, members_north_star) existing. The agent must guess when this specific cross-platform metric is the right choice.

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. Beyond that the description adds nothing behavioral — no indication of the time window covered, whether the value is cached or live, or what dimensions the KPI is broken down by.

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?

Extremely short and front-loaded, with no filler preamble. The only mild redundancy is the verbatim Korean restatement of the same phrase, which duplicates rather than extends the meaning.

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 and no parameters, so the description is the only source of information about what an agent gets back. It does not say whether the result is a single number, a time series, or a breakdown, leaving the return shape unknown for a metric-fetching 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 tool takes zero parameters, so there is no parameter semantics burden and the baseline is 4. The description neither needs to nor does explain any inputs.

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 concept (North Star growth KPI), so an agent knows this returns a growth metric rather than raw member data. However, it is a bare noun phrase with no verb (fetch/get/read) and gives no basis for distinguishing it from siblings like members_summary or members_cross_platform.

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 statement of what question this answers, and no naming of alternatives such as members_summary. Usage must be entirely inferred 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 fully cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is low, but the description adds essentially nothing beyond metric names that already appear in the body text. No mention of scope, freshness, or what the summary aggregates over.

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 line plus a bilingual restatement — very lean, arguably under-specified rather than wasteful. The metric list is truncated with an ellipsis, which costs information without saving much space.

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-arg summary tool with a rich sibling set (members_north_star, members_cross_platform, acquisition_stats), the description is too thin to route or interpret results. No output shape is hinted at and no scope boundary is given.

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?

Zero parameters, so the baseline is 4. There are no argument semantics to explain and none are invented, which is the right call.

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 resource and deliverable type (totals/summary) with named example metrics, but is mostly a restatement of the tool name. It does not distinguish itself from siblings like members_north_star, members_cross_platform, or acquisition_stats, which an agent would need to route correctly.

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 rather than the adjacent members_* or *_stats tools. The agent is left to infer the scope (all members? platform-wide? current or historical?) with no exclusions or alternatives named.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the probed-backend enumeration, a useful behavioral detail, but says nothing about cost, latency, or what happens on a failed probe, so it earns only modest credit beyond 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?

Two short, front-loaded clauses that state purpose immediately with no filler. The English/Korean duplication adds length that a monolingual reader does not need, slightly denting efficiency.

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-parameter diagnostic tool with no output schema, the description is mostly sufficient but omits the shape of the result (e.g. per-backend status/error fields) that an agent would want to interpret the probe. Annotations cover the safety dimension, leaving this as the main remaining 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 tool takes zero parameters, so the schema carries no parameter semantics to clarify; the baseline for a parameterless tool is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific action ('self-probe status') and resource ('each Reach backend'), and enumerates the exact channels probed (web/github/youtube/reddit/twitter/rss/search), so an agent knows this is a diagnostics tool distinct from reach_read/reach_search. It does not, however, distinguish itself from overlapping status/health siblings like hq_health or server_status.

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 guidance on when to call this versus the sibling health/status tools (hq_health, server_status) or when not to. Usage is only implied by the word 'doctor' and the status framing.

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, openWorld). The description adds genuinely new behavior: automatic channel detection and a self-healing Jina fallback if the primary fetch fails. It does not disclose rate limits, failure modes, or auth/robots constraints, so it isn't 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?

The capability statement and the fallback/no-key facts are front-loaded in the first sentences, which is good structure. However, the full Korean restatement roughly doubles the length without adding information for a non-Korean-reading agent, which is mild redundancy rather than pure waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully states the return shapes (markdown or structured JSON), and annotations carry the safety semantics. Gaps remain around pagination, size limits, and error behavior on blocked or unreachable URLs, but nothing required to invoke the tool 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 both parameters are already documented in the schema, including the owner/repo shorthand and the channel override. The description restates channel auto-detection but adds no syntax or format detail beyond what the schema provides. 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: read a public URL and return markdown or structured JSON. It also enumerates the channels handled (web, github, youtube, reddit, rss), which helps an agent frame the tool's scope. It stops short of explicitly contrasting with the sibling reach_search, so it falls below a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Read any public URL live' plus 'No API key needed' implies the usage context (single-URL fetch, no auth setup), but there is no explicit when-to-use/when-not guidance and no routing to reach_search or reach_doctor. The agent must infer which reach_* tool applies.

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, openWorld, idempotent and non-destructive, so the safety profile is covered. The description adds genuine context beyond that: no API key needed and an explicit fallback chain (HN to DuckDuckGo to Jina-Google) for web search.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, with the capability statement and the fallback behavior front-loaded. The Korean duplication is redundant for most readers but does not obscure the content.

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 search tool with no output schema, the description covers sources, cost/key requirements, and fallback behavior. The safety profile is fully provided by annotations, so little is missing an agent would need to invoke it.

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 both q and channel are already documented in the schema, including the channel option list. The description adds no parameter-level syntax or semantics, 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 (Search) and enumerates the exact resources (web, GitHub, YouTube, Reddit), which clearly sets it apart from siblings like reach_read and reach_doctor. It is recognizably the search tool without opening the schema, though it does not name sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. The reader must infer that this is the retrieval tool relative to reach_read/reach_doctor from the verb 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 readOnly, idempotent, non-destructive, and closed-world behavior. The description adds only the scope: TCP checks across 5 servers. It does not disclose auth needs, timeout behavior, aggregation, or failure reporting, but with rich annotations the gap is less severe.

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 very short and front-loaded. The Korean translation duplicates the English content without adding information, but the definition remains efficient and easy to scan.

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?

No output schema exists, so the description should carry more of the return-shape burden. It only says 'status' in the Korean clause and never explains whether results are per-server or aggregate, leaving an agent to infer the output from the tool name.

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 an empty object schema with 100% coverage, so the baseline of 4 applies. No parameter semantics are needed or missing.

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 resource and scope ('TCP health fan-out across 5 servers') but uses no explicit verb and does not differentiate from siblings like hq_health or reach_doctor. An agent can infer it checks server health, but the purpose is only implied.

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 when-to-use guidance is provided, and there is no mention of alternatives or when not to call this tool. The agent must guess its role relative to sibling health-check tools such as hq_health or reach_doctor.

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 notably openWorldHint=false, so safety and idempotency are covered. The description usefully confirms the closed-world nature by framing this as a fixed registry of 5 named providers plus fallbacks, but adds nothing about freshness, rate limits, or whether the list is live versus static.

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 single sentence that puts the resource type first and the concrete contents immediately after, with no preamble. The bilingual Korean echo is duplicative for a pure-English reader but appears to be an intentional convention in this toolset.

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 parameters, no output schema, and full annotation coverage, the description carries the burden of explaining what the agent gets back, and it does so by naming the returned dimensions (availability, free tier, capability). Adequate for a zero-arg registry lookup, though it never says how the fallbacks relate to the five primary providers.

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 takes zero parameters, so there is nothing for the description to disambiguate and the schema is trivially complete. Baseline 4 applies; no parameter-related gap exists.

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 ('video provider registry') and even enumerates the concrete contents (5 named 2026 providers plus fallbacks, availability, free tier, capability). This is far more specific than a tautology, but it never distinguishes itself from the sibling llm_providers, leaving the agent to infer that this is the video counterpart.

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 statement, and no alternative tool is named. The agent must infer from the name alone that this is the discovery step before any video generation call, which is a reasonable but unstated inference.

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