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

No annotations are present, so the description carries the behavioral burden. It discloses that it returns assistant reply as text and requires NOVAI_API_KEY, which is useful. However, it does not mention cost implications, rate limits, or other operational constraints that matter for an LLM API call, leaving a notable gap.

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?

Well-structured with a clear Args list, front-loaded purpose, and no wasted words. Every sentence contributes essential information (scope, parameters, return, auth, alternative).

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?

Given the output schema exists, the description need not explain return values, but it does so concisely. Auth and parameter semantics are complete. A minor gap remains: cost or rate-limit behavior is not mentioned, which could affect invocation decisions.

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%, so the description must compensate fully. It defines all three parameters: model (with example and source), prompt (user message), and system (optional system prompt), adding clear meaning beyond the bare schema titles.

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 ('Send a chat completion') and resource ('Chinese LLM'), lists example providers, and explicitly distinguishes from the image-generation sibling. An agent can identify the tool's exact function 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?

Explicitly names the alternative for image generation ('use novai_generate_image instead') and implies the appropriate use case (chat completion). Prerequisite for model IDs is given via 'model id from novai_list_models'.

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?

No annotations are provided, so the description must carry the full behavioral burden. It describes the return format ('a single model record with name, price_usd, unit and url') and the read-only nature is implied by 'Return,' but it lacks explicit safety, rate-limit, or data freshness details. For a simple read tool, this is adequate but not comprehensive.

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

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

The description is front-loaded with purpose, then logically presents arguments, return values, and the alternative tool. Every sentence is informative and there is no wasted text.

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

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

For a simple one-parameter tool with no output schema and no annotations, the description covers all essential aspects: purpose, allowed parameter values and default, return fields, and an alternative for broader needs. Nothing critical is missing for correct invocation.

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%, so the description fully compensates by listing all allowed category values and the default ('Chat / LLM'). This gives the agent everything needed to supply the parameter correctly.

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 ('Return'), resource ('cheapest model'), scope ('in one category'), and source ('live price leaderboard'), and explicitly distinguishes itself from the sibling novai_pricing_feed. An agent can immediately understand what this tool does and how it differs from the full-feed alternative.

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?

Provides an explicit alternative and the condition for using it: 'Use novai_pricing_feed when you need the full ranked feed across all categories.' This implicitly defines when to use this tool (when you need only the cheapest model in a single category), giving clear 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?

With no annotations, the description carries the full burden and does well: it discloses pricing ($0), free-tier limits (10 calls/day, 5 req/min), and that the result is a list of model ids. It stops short of describing failure behavior when the rate limit is hit or any auth requirements, which keeps it from 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?

Four short sentences, front-loaded with the core action and count, followed by the usage rule, the rate-limit caveat, and the alternative. No filler or repetition.

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?

Simplest possible call signature, and the description still covers cost, rate limits, and sibling routing. An output schema exists so return values needn't be explained, and the mention of 'list of model ids' is a bonus rather than a crutch.

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

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

The tool takes zero parameters, so the schema-coverage baseline of 4 applies. The description correctly implies no filtering or pagination arguments are needed, consistent with the empty 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 ('List the 5 models that are free to call on NovAI') and even enumerates the family (GLM Flash: text, vision, image, video). It explicitly contrasts with the sibling novai_list_models, so an agent can disambiguate 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 trigger ('Use when the user wants zero-cost calls') and names the alternative tool plus the condition that selects it ('For the full paid+free catalogue use novai_list_models'). Both the when and the when-else 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?

With no annotations, the description carries the full disclosure burden and does meaningfully well: it reveals the cost model ('Billed per image'), points to a pricing tool for the exact amount, and states the return shape (list of image URLs). It omits moderation/content-policy behavior and any rate or quota limits, which keeps it from 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?

Front-loaded with the capability, then parameters, then return value, then cost caveat and the sibling alternative — no filler sentences. The docstring-style 'Args:' block mildly duplicates what the schema already lists, but the added examples justify it.

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?

An output schema exists, so the brief return-value note is sufficient, and both required parameters are covered. For a simple two-parameter generation tool the description is nearly complete; only model-selection guidance and any size/style options 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 0% (both properties are bare strings), so the description must compensate, and it does: 'model' is explained as an image model id with two concrete examples ('doubao-seedream-5.0, cogview-3-flash') and 'prompt' as the image description. It does not describe acceptable prompt length, aspect ratio, or model-specific 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?

States a specific verb and resource ('Generate images') and names the concrete model families (Seedream, Hunyuan Image, CogView, Wan), so an agent knows exactly what capability this exposes. It also explicitly distinguishes itself from the chat sibling ('For chat use novai_chat instead').

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 routing guidance away from novai_chat and instructs the agent to check novai_pricing_feed for per-image price before calling. It stops short of saying when to prefer one image model over another or when not to generate images at all, but the key alternative is named.

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

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

With no annotations, the description carries the load and does disclose the return shape (sorted list of model id strings) and an important negative trait (no prices included), which prevents an agent from misusing it for cost queries. It stops short of stating that the call is read-only with no side effects, and gives no latency, auth, or caching context.

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 short lines, front-loaded with the core action and scope before the routing advice. Every sentence, including the no-prices caveat, carries informational weight with no redundancy.

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?

A zero-parameter listing tool with an output schema is about as simple as it gets, and the description still covers scope, count, output format, and sibling routing. Nothing an agent needs in order to call this correctly is absent.

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 baseline is 4. The parenthetical model count gives the agent a sense of result size, which is a small value-add beyond an empty 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 (list every model id on the NovAI gateway) and quantifies scope with the 111-model count. An agent can immediately distinguish this enumeration tool from novai_chat, novai_generate_image, or the pricing siblings.

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

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

Explicitly names the triggering condition ('when the user asks which models exist') and routes to alternatives by task: novai_free_models for zero-cost, novai_cheapest or novai_pricing_feed for prices. This is textbook when-to-use/when-to-use-something-else 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?

With no annotations, the description must carry the behavioral load, and it does disclose the return shape, that prices are live (with a generated_at stamp), and a critical usage caveat that units differ by category and comparison must be unit-aware. It stops short of stating pagination, caching/freshness guarantees, or auth needs, which is the only reason 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?

Four short lines, each doing distinct work: purpose, use case, alternative routing, return shape, and a units warning. Front-loaded with the purpose and free of 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?

No output schema exists, but the description inlines the return structure ({generated_at, categories: [{category, models: [...]}]}) and flags the unit heterogeneity that would otherwise cause an agent to miscompare costs. For a zero-parameter read-only tool, nothing material is missing.

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

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

The input schema has zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description instead spends its words on return-value semantics, which is the right use of space here.

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 — "Return the complete live price leaderboard" — and immediately scopes it as "all categories, models ranked by normalized cost." The breadth of "complete/all categories" is exactly what separates it from the sibling novai_cheapest, so an agent can pick between them 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?

Gives the affirmative case ("Use for comparisons or cost tables") and the negative case with a named alternative ("For one quick answer use novai_cheapest instead"). The routing condition is explicit rather than inferred.

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?

No annotations are provided, so the description carries the burden; it signals a read-only informational source ('published platform metrics') and states the return type ('Returns a JSON object'). It does not address freshness/caching of the metrics or whether any auth is required, which is the only remaining gap for a zero-param read tool.

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

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

Three short sentences: content first, usage trigger second, sibling disambiguation third. No filler, and the most decision-relevant routing information is front-loaded.

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 compensates by enumerating the fields the JSON object contains, and it names the sibling to use for the adjacent need. Nothing an agent needs to call this zero-param 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?

The tool takes no parameters, so there is nothing to disambiguate; the baseline applies. The description instead usefully documents the conceptual payload (fee, multiplier, refund policy, rate limits, billed units) in place of parameter detail.

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 ('Return NovAI's published platform metrics') and enumerates exactly what is covered: platform fee, price multiplier, refund policy, rate limits, billed units. It explicitly distinguishes itself from the pricing sibling by scoping itself to policy rather than model prices.

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 trigger ('Use when the user asks how billing or pricing policy works') and an explicit exclusion with the alternative named ('For actual model prices use novai_pricing_feed'). The agent can route between the two without inspecting either schema.

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