star365 HQ

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 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, 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 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 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.