Golden Kog token risk analyst by Kognai

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context not in the annotations: pricing is set by the Kognai CFO and the call itself is free, which tells the agent there is no charge for invoking it. It does not describe the response shape or payment mechanics in any depth.

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 dense sentence with no filler, and the subject (what the service does/never does) is front-loaded. It is terse but not padded, which suits a small informational 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?

For a zero-parameter, read-only info tool this is nearly adequate, but it omits what the response actually contains (structured text? a URL? a price table?) and gives no indication of payment flow details, leaving the agent to discover the return format on the first call.

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 and the schema is fully described, so there is nothing for the description to disambiguate. Baseline for a no-parameter tool applies.

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

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

The description names the resource ('Golden Kog') and enumerates the content the tool returns: what it does/never does, prices, and how to pay. That is clear and distinct from the token-analysis siblings (analyze_token, resolve_ticker, monitor_token). It stops short of a crisp verb like 'retrieve service info', but an agent can still tell what the call yields.

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

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

Usage is only implied: an agent infers it should call this to learn about the service before paying. There is no explicit when/when-not and no mention of the sibling tools, though the informational nature makes the boundary fairly obvious. 'Free' hints at a no-cost precondition but isn't framed as 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 declare readOnlyHint=true and openWorldHint=true, and the description adds genuinely new operational context: the tool is paid (partner key or x402), it refuses to output trading signals ('Risk and structure facts, never a trading signal'), and it discloses the special handling of regulated issuer assets (ISSUER CONTROLLED with named issuer rather than risk points). That is substantive disclosure beyond the annotation set.

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?

It is front-loaded with the purpose, which is good, but the first sentence is an overlong run-on with multiple stacked parentheticals ('a regulated issuer's asset, such as USDC or an xStock, is ISSUER CONTROLLED...') that hurts scannability. The final two short sentences (no trading signal, paid) are efficient and earn their 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?

With no output schema and only two well-documented parameters, the description takes on the return-value burden itself and does so reasonably, describing the risk level, points, per-flag evidence, measured facts, and text summary. The payment requirement and the no-trading-signal boundary are covered, leaving little an agent needs that 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% for both parameters, including the chain enum and the token address format, so the schema already carries the parameter burden. The description adds no parameter-level detail (formats, syntax, constraints), 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 names a specific verb+resource ('One token risk and structure analysis') and enumerates the outputs it produces (risk level, flags with evidence, measured facts, short text). It implicitly separates itself from monitor_token by emphasizing a single one-shot analysis, though it never names the sibling outright.

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

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

Usage is implied — analyze one token for risk/structure facts — and the access prerequisite is stated ('Paid: partner key or x402'). However, there is no explicit when-to-use guidance and no routing against monitor_token, resolve_ticker, or get_job, which are plausible alternatives for a related intent.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the required view-token provenance ('from the paid reply'), the fields returned (state, report, alerts), and the cost model ('Free'). It does not mention error behavior or pagination, but that is a minor gap against an already-covered read-only profile.

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

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

A single compact sentence with no filler, and the key scoping detail (the token source) is front-loaded. The trailing 'Free.' is terse but purposeful. The grammar is somewhat compressed to the point of being cryptic, which slightly hurts immediate parseability.

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 burden of describing the return payload (state, report, alerts). It also covers the auth-style requirement via view_token provenance and the cost. For a two-parameter read tool this is nearly complete; only error/pagination behavior is 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 description coverage is 0% for both parameters, so the description must compensate. It does explain where view_token comes from ('from the paid reply') and that job_id identifies the job, which adds real meaning over the bare schema. However, it does not clarify the gk_ id format or the token's minimum length constraints present in the schema, so compensation is only partial.

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 (retrieve a job by id) and enumerates the returned content (state, report, alerts), which is more than the title restates. The sibling tools (about, analyze_token, monitor_token, resolve_ticker) are in a different domain, so no differentiation is needed, but the description does not name them. The phrasing 'a job by its id with the view token from the paid reply' is a bit compressed but decipherable.

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

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

Usage is implied: you need a view token obtained from the 'paid reply' and the call is 'Free', which hints at a cost contrast. There is no explicit statement of when to use this versus alternatives, nor any exclusions or prerequisites beyond the token origin. Adequate but leaves the agent to infer context.

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 (readOnlyHint=false, openWorldHint=true) only signal 'has side effects, reaches outside', so the description carries real additional weight: it discloses that the tool is a long-lived monitor whose results arrive asynchronously via webhook or polling, and that it is gated behind payment/partner credentials. It does not say what happens if webhook is omitted or whether monitoring can be cancelled, which keeps it out of 5 territory.

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 action and trigger list, then two short sentences for the billing and access facts. Minimal waste, though 'the window on sale is 24 hours' duplicates the schema's '24 is the window on sale' and the single long first sentence is dense.

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 does the necessary work of explaining what comes back and how (each alert as a JSON POST to the webhook, or retrievable via get_job). Required vs optional is left to the schema. For a four-parameter tool with 100% schema coverage this is close to complete, missing only lifecycle details such as cancellation or failure behavior.

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 four parameters (chain, hours, token, webhook) are already documented in the schema, including the 32-44 char / 0x-hex address formats and the 1-72 hour bounds. The description only echoes the 24-hour default and does not add format or constraint detail beyond it, 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 ('watches one token') and enumerates the alert triggers it fires on (dev wallet sells, top holder sells, liquidity pulled, authorities changed, new wallet cluster). It also names the sibling it hands off to ('polling get_job'), so an agent can separate it from get_job and analyze_token without opening a 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?

Explains the two delivery modes (webhook push or polling get_job) and states the purchasable window ('the window on sale is 24 hours') plus the access requirement ('Paid: partner key or x402'). It does not contrast the tool against the analyze_token sibling, which is the one adjacent choice an agent might weigh, 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 and openWorldHint, but the description adds real value beyond them: the full returned field set, the sort order ('verified first, then liquidity'), the semantics of the verified flag (mint on Jupiter's verified list), and cost ('Free'). It stops short of stating result limits, empty-result behavior, or rate limits, so it is strong rather than exhaustive.

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 the returned attributes before the workflow guidance, which is the right order, and every clause carries information. Minor redundancy between 'Candidates only: Golden Kog never picks one' and the later 'KOG is never a candidate' costs it the top score.

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 a single fully documented parameter, no output schema, and read-only annotations, the description covers everything an agent needs: what comes back, how it is ordered, that it is a candidate list requiring human selection, and which sibling to call next.

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 there is only one parameter, so the schema already documents the ticker format ('letters and digits, with or without $'). The description's 'WIF or $WIF' examples reinforce the $ prefix handling but add no new constraint 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?

Opens with a concrete resource and scope: 'The Solana tokens that carry a ticker such as WIF or $WIF', and enumerates exactly what each candidate carries (symbol, name, mint, liquidity USD, pool count, age, verified). It explicitly separates itself from the sibling analyze_token by declaring this returns candidates only and never picks a winner.

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: show candidates to the person, let the person choose, then call analyze_token with that exact mint. It also states a negative condition ('never picks one and never analyses a ticker') and the 'KOG is never a candidate' exclusion, so there is no ambiguity about when to use it versus analyze_token.

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