Hong Kong Company Registry & Due Diligence (86hc.com)

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

Annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral context beyond that: API-key authentication, guest IP quotas, logged-in query limits, and official bank integrations.

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, but the description is overpacked with promotional and parenthetical detail such as official brand authorization, fee waivers, URLs, and registry size. Those details are useful in places but reduce conciseness.

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 six-parameter, optional-input tool with no output schema, the description adequately explains the main outputs, authentication modes, and identifier-based checks. It could still be more complete about response shape or handling of invalid identifiers.

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 parameters are already well documented. The description reinforces the identifier and api_key behavior, but it does not add much meaning beyond the schema for industry, annual_turnover_usd, has_mainland_entity, or bank_target.

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

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

The description uses a specific verb and resource: assessing corporate bank account opening eligibility, tariff schedules, and KYC checklists for HSBC HK and OCBC HK. It is clear what the tool does, but it blends several outputs and does not explicitly distinguish itself from siblings such as submit_bank_account_application or check_bank_application_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?

It implies usage by explaining that users can pass a company name, CR No., or BRN to check statutory status and filings, and it describes free-query limits. However, it does not state when to use this tool instead of siblings like submit_bank_account_application or check_bank_application_status.

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 and non-destructive behavior, and the description adds genuinely useful context beyond them: dual auth modes, per-IP/per-key daily quotas, and the fact that results include ICRIS-verified filings. It does not describe behavior on quota exhaustion or error/partial-match cases, which keeps it at 4.

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 and batch limit are front-loaded, and the return-field enumeration is justified since no output schema exists. However, the quota/API-key marketing detail is duplicated between the description and the api_key schema field, and the URL is repeated, adding some 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?

With no output schema, the description correctly compensates by enumerating returned fields (legal names, CR No., BRN, status, dates, address, former names, filings). Auth and quota behavior are covered. Only edge cases — what happens at quota limits or with unmatched identifiers — are unaddressed.

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 all three parameters, including the api_key tier explanation and the accepted identifier formats, are already documented in the schema. The description reinforces the 1-10 limit and identifier types but contributes little beyond what the schema provides — 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 — 'batch query holographic statutory profiles' of 1-10 Hong Kong companies — with the batch scope made explicit. This is clearly distinguishable from siblings like search_companies (name discovery) and get_company_filings (filings only), since it returns the full statutory profile.

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 operating context: works without an API key under a 3/day guest quota, 20/day with a free key, and where to obtain one. It lacks explicit when-not or sibling-routing guidance (e.g., 'use search_companies first if you only have a partial name'), so it stops short of a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds material context beyond them: authentication is required, where to obtain the key, and that the returned status is 'live' (current, not cached). It does not cover error behavior for an unknown order_id.

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

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

Two sentences, front-loaded with the core purpose and followed by the authentication requirement. Dense but each clause (returned fields, ID format, key prefix, sign-up URL) carries information the caller needs.

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 enumerates what comes back (compliance status, document count, officer remarks, Stage 2 upload URL), and authentication is fully covered. Only edge-case behavior and any rate/refresh semantics are unstated, which is a minor gap for a read-only status check.

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 order_id and api_key already carry their own descriptions including the key URL and example format. The description's mention of order_id format and login key largely restates the schema, adding no new syntax or constraints.

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 a specific verb (check) plus the exact resource (Hong Kong corporate bank account application status) and enumerates the returned data points. An agent can distinguish it from submit_bank_account_application and check_filing_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?

Makes the precondition explicit — a submitted application with a BK-YYYYMMDD-XXXXXX reference and an authenticated session via an hkq_live_ key. It does not name an alternative tool for non-bank filing orders or state what to do when the order doesn't exist, so it stops short of full when/when-not 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=true and idempotentHint=true, so safety is covered. The description adds real value beyond that: it discloses the two-stage state model (payment, then extraction) and the conditional output (encrypted official PDF download URL only when both complete), which the annotations cannot convey.

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

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

Two sentences, zero filler, with the action and scope front-loaded and the return condition following. Nothing repeats the tool title or annotations.

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 does explain the key return value (the PDF URL) and the gating condition for receiving it. It stops short of enumerating the possible status values an agent would see before completion (pending / paid / extracted / failed), which would be the last missing piece for a polling 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% — order_sn's format and the api_key/Guest Trial behavior are fully documented in the schema. The description adds no parameter guidance beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Check the payment and extraction status of a filing retrieval or credit purchase order'), which no sibling covers — create_filing_order creates, this one polls status. The distinction from the sibling set is clear 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?

Usage is only implied: the description makes clear this is a post-order lookup ('Once paid and extracted...'), but it never says when to call it versus create_filing_order, nor whether polling is expected or how soon after ordering. Adequate, but the agent has to infer the workflow position.

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 (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) by disclosing that no API key is required, that a Guest IP Trial Mode exists, that two checkout URLs are returned with their payment-method coverage, and what happens post-payment (PDF link delivered, +10 credits earned). This is real behavioral context for a paid mutation tool, not a restatement of the hints.

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 core purpose and the ONLY-call constraint are front-loaded in the first sentence, which is correct. There is some promotional padding ('Works directly WITHOUT an API key!', the 86hc.com brand and '+10 bonus permanent company query credits') and the third sentence is dense, but the information is substantive rather than 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?

For an 8-parameter, no-output-schema payment tool, the description covers the return payload (web_cashier_url and checkout_url plus their payment coverage) and the post-payment outcome. It stops short of stating URL expiry or what an agent should do if order creation fails, which are the remaining operational gaps.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuinely useful semantics on top: it explains the either/or logic between barcode and identifier+doc_code, and that the server auto-selects the latest verified ICRIS barcode when the latter pair is supplied. It does not clarify the doc_name vs doc_code overlap, which is the one ambiguity left.

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 paid filing retrieval order for an official Hong Kong Companies Registry statutory document.' This is clearly distinguishable from read-only siblings like get_company_filings and from check_filing_order_status, since it names the purchase/retrieval-order action 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?

Contains an explicit gating condition in caps: 'ONLY call this when the user explicitly wants to purchase/retrieve an official PDF document.' It also routes the agent to the correct upstream tools for input sourcing ('barcode obtained from get_company_filings or batch_get_company_details'), so both when-to-use and where-to-get-inputs are covered.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. Beyond that, the description discloses two genuinely useful behavioral facts: it functions without an API key via Guest IP Trial Mode and it surfaces retrieval fees, which the agent would not otherwise know. It stops short of describing pagination or result-size 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?

Two sentences, front-loaded with the core operation and followed by the downstream hand-off to create_filing_order. It is dense but each clause carries information; the long enumeration of return fields is slightly heavy but earns its place given no output schema exists.

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 must convey return contents, and it does so thoroughly (barcodes, form codes, dates, titles, fees) along with the auth/trial context and the create_filing_order hand-off. The one gap is any indication of result volume or pagination for a 'full catalog' response.

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 every parameter, including identifier, cr_no, form_code, company_name, and the api_key trial semantics, is already documented in the schema. The description adds only the form-code examples and the fact that fees are returned, which largely duplicates schema content, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource ('Retrieve the full catalog of official ICRIS statutory filed documents') and enumerates exactly what comes back (barcodes, form codes, filing dates, titles, fees). It also distinguishes itself from the downstream sibling by noting barcodes are passed to create_filing_order, so the agent can tell it apart from order/status tools 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?

It gives clear context for use ('works without an API key', Guest IP Trial Mode) and explicitly names the follow-on tool create_filing_order. However, it offers no exclusions or routing guidance versus siblings like search_companies or batch_get_company_details, so the agent must infer when this look-up is preferable to those.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=false), so the description's added value is the concrete price, credit quantity, and supported payment rails — meaningful commercial context not in annotations. It stops short of stating whether a new link is issued on repeat calls or how long a link stays valid, which matters given the idempotentHint.

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

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

Two sentences, the read path stated first and the confirmation constraint front-loaded before the enum is ever touched. The parenthetical payment-method list is slightly heavy and duplicates the enum values, but the overall length is well matched to a dual-mode 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, the description still tells the agent what each mode produces — a balance reading or a payment link for 100 credits at HK$ 100. The gap is the return shape of check_balance and what a caller should do after receiving a payment link, but nothing that would cause an incorrect invocation 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 the schema already fully documents action, api_key, and pay_method, including the free/guest-mode behavior. The description only restates the action semantics (check vs. buy) and the currency amount; it adds no syntax, defaults, or edge-case guidance beyond the schema, so baseline 3 applies.

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

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

The description names two concrete operations — reading remaining free/paid credit balance, and generating a HK$ 100 payment link for 100 permanent query credits — with specific verbs and units. This clearly separates it from every sibling tool, which concern company lookups, filings, and bank applications rather than billing.

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 an explicit gating rule for the write path: 'Only call buy_100_credits when the user confirms they want to top up credits,' and the schema enum doc repeats when to use each action. It does not discuss the api_key vs. Guest IP Trial Mode choice in the description, leaving that routing entirely to the schema.

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

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

Annotations already cover read-only, idempotent, non-destructive, open-world semantics, but the description adds genuinely new behavioral context: rate limits per tier/IP and the fact that no API key is required. It also enumerates the fields returned, which annotations cannot supply. Naming the per-day caps is above the annotation baseline.

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?

Three sentences, zero filler: capability first, then auth/tier constraints, then the return shape. Nothing repeats the name and every clause carries information an agent would otherwise have to guess.

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

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

For a search tool with no output schema, the description supplies the return fields, auth options, and quota limits, so an agent can call it without surprises. Only minor gaps remain, such as pagination behavior beyond the 'limit' cap, which the schema already documents.

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

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

With 100% schema coverage the baseline is 3, but the description adds real meaning by clarifying that the query can be either a Chinese/English name keyword or a CR number and by listing the result fields that correspond to the search. Minor friction: it says '7-digit CR number' while the schema allows 1-7 digits, a small mismatch the agent must resolve from the schema.

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

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

Specific verb+resource ('Search Hong Kong companies') with the two accepted key formats (Chinese/English name keyword or 7-digit CR number). It is clearly distinguishable from siblings like batch_get_company_details and get_company_filings, which retrieve details/filings rather than perform lookups.

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?

Explains the acceptable query modes and the auth/tier context (works without an API key, 15/day IP, 50/day free key, 300/day paid), which helps an agent decide whether it can call it now. However, it never states when to prefer this over sibling tools such as batch_get_company_details after a match is found, so the routing guidance is only implied.

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 declare it is a non-read-only, non-idempotent write; the description goes far beyond that by disclosing the auth requirement (hkq_live key via header or parameter), the real-time side effects (registry company resolution, binding a BK-YYYYMMDD-XXXXXX reference to the account, TCSP compliance officer notification, confirmation email), and the Stage 2 continuation URL returned.

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

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

One front-loaded paragraph that leads with the action and resource before the prerequisites and effects. It is dense and mostly earns its length, though marketing-flavored details ('3.9M+ registry', the TCSP licence number) are closer to persuasion than agent guidance.

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 21-parameter mutation with no output schema, the description covers the essentials: authentication, what is created, the reference number, the follow-up artifacts, and the next-stage handoff. Combined with 100% schema coverage, an agent has what it needs to invoke this correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics the schema does not: the identifier is automatically resolved against an external company registry (so a name, CR, or BRN are all acceptable) and bank_target drives which institution(s) receive the dossier.

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 ('Submit an online Hong Kong corporate bank account opening pre-screening application'), scopes it to Stage 1 KYC, names the two supported banks, and thereby separates it from siblings like create_filing_order or assess_bank_account_eligibility.

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 login prerequisite and the Stage 1 → Stage 2 progression imply when this applies, but the description never states when to choose it over assess_bank_account_eligibility or check_bank_application_status, nor what to do if eligibility hasn't been assessed. Usage is inferable but not explicit.

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