inkflow

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

With no annotations, the description carries the behavioral burden. It explains what checking the balance relates to—credits that settle orders instantly—and confirms the tool performs a check rather than a purchase or mutation. It could explicitly state the response format, but the read-only nature is strongly implied.

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, each earning its place: the purpose, the credit behavior/context, and the top-up alternative. No redundant or filler 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 simple one-parameter balance check with no output schema, the description covers what the tool does, why it matters, and what related action to take. The main missing detail is the exact response format or currency of the returned balance, but this is a minor gap.

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

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

The schema provides only a string field named apiKey with no description, and schema coverage is 0%. The description compensates by identifying it as your INKFLOW API key, giving the parameter concrete meaning beyond the bare 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?

The description uses a specific verb and resource: 'Check the credit balance on your INKFLOW API key.' This clearly identifies the tool as a balance inquiry and distinguishes it from siblings like inkflow_quote, inkflow_order, and inkflow_topup.

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

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

The description gives clear context: credits allow instant purchases without a human, and it explicitly directs the user to inkflow_topup for topping up. It does not spell out explicit when-not-to-use conditions, but the intended use case is obvious.

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 exist, so the description carries the disclosure burden. It clearly signals an informational read-style query by saying 'Returns', lists what is returned, and adds an important availability caveat about the non-orderable book-to-movie adaptation. It does not explicitly say 'read-only', but the wording makes side effects unlikely.

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 'full catalogue' and 'Returns', but then becomes a long marketing-style run-on with details like 900,000-word editions, LoRA rank-64, and 24-hour delivery. These details are not needed for invoking the tool and dilute the actionable instruction.

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 optional-parameter catalogue lookup with no output schema, the description is largely complete: it states the returned fields, currency handling, and an unavailable offering. A more precise return shape or an explicit 'this is only a listing, not an order' statement would be the only meaningful additions.

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 only parameter, currency, is fully described in the schema as an ISO currency string with a default of USD. The description's mention of 'live prices in the requested currency' reinforces the parameter but does not add meaningful semantics beyond the schema. Baseline 3 applies due to 100% schema description coverage.

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 ('INKFLOW's full catalogue') and a clear action ('Returns products, tiers, genres, languages and live prices'). It is clearly distinguished from transactional siblings by being informational and by explicitly flagging that book-to-movie adaptation is not currently orderable.

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 intended use is implied: use this tool to retrieve catalogue information and live prices. However, it never names sibling alternatives such as inkflow_quote or inkflow_order, nor does it state when not to use it. The guidance is present but implicit rather than explicit.

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 full burden. It does disclose the key behavioral consequence that ULTRA LoRA training starts on the chosen face, which signals a non-read-only, consequential action. But it omits whether the choice is final, whether credits are consumed, or if the training is immediately triggered, so disclosure is only partial.

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 one efficient sentence with a clear action, resource, and consequence, ending with a meaningful outcome statement. There is no filler or repetition of schema details.

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

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

With no output schema and no annotations, the description leaves significant gaps: how the candidate thumbnails are provided, what response to expect, whether the training start is immediate or requires confirmation, and whether the selection is reversible. For a tool that triggers a consequential training action, this is inadequate.

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 only 33%, so only 'choice' has a schema description. The description adds meaning to 'choice' by linking it to the '3 candidate thumbnails' and 'chosen face', and gives context to 'orderId' via 'digital-actor order'. However, 'apiKey' remains unexplained and no parameter details are given for orderId beyond inference, so compensation is 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?

The description uses the specific verb 'Pick' and names a concrete resource ('one of the 3 candidate thumbnails for a digital-actor order'), and adds the consequential outcome 'ULTRA LoRA training starts'. This clearly positions the tool as the face-selection step before training and distinguishes it from sibling inkflow_train_ultra_lora_actor.

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

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

The description implies when to use the tool — before or as part of a digital-actor order when a face must be chosen — and hints that training follows. However, it does not explicitly state alternatives, exclusions, or the relationship with inkflow_train_ultra_lora_actor, leaving the guidance mostly 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?

With no annotations provided, the description carries the behavioral burden and does disclose no-auth access and zero cost. It also clarifies the content returned. It does not mention output format, limits, or delivery mechanics, but for a zero-parameter free-sample tool the stated behaviors are the material ones.

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 one front-loaded sentence with no filler. It leads with the most important facts, enumerates the sample categories, and closes with the usage intent.

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 no-parameter tool with no annotations and no output schema, the description covers access requirements, cost, and the substance of what the user receives. It could be more explicit about delivery format or sample limitations, so it is not a perfect 5.

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 is empty, so there are no parameter semantics to document; baseline 4 applies. The description reinforces that no key is required and introduces no conflicting parameter expectations.

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 opens with 'FREE, no key needed' and names the exact deliverable types: 'ULTRA LoRA actor cards (multi-pose stills)', 'object/set LoRA renders', and 'product spec sheets'. It clearly identifies the tool as a free sampling endpoint and distinguishes it from ordering, quoting, or top-up 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?

The phrase 'see the quality before ordering anything' tells the agent when to use this tool, and 'FREE, no key needed' communicates the access context. It does not explicitly name alternatives or state when not to use it, so it stops 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?

No annotations are present, so the description carries the behavioral burden. It does disclose useful behavior: it returns live status fields and only includes delivery links when complete. However, it does not clarify whether the operation is read-only, what happens for invalid or incomplete order IDs, or any auth/rate-limit considerations beyond the apiKey parameter.

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 a single sentence that front-loads the core purpose and packs concrete status details into a compact, readable list. There is no filler or redundant information.

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 two-parameter status lookup with no output schema or annotations, the description conveys the main result categories and the completion condition for delivery links. Still, it omits any explicit explanation of how apiKey and orderId should be supplied and does not describe the response structure, which would be more important without an output schema.

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 for the undocumented apiKey and orderId parameters. It only implies that 'an order' is referenced, and it never explains the apiKey's origin/format or the orderId format. The additional status-field detail does not clarify the parameter meanings.

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 clearly identifies the resource (an order) and the function (live status check), and adds useful specifics: chapters written, QA phase, and delivery links when complete. It distinguishes itself from siblings like inkflow_order by focusing on status rather than creation, though it does not use an explicit verb such as 'get' or 'retrieve'.

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

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

The description implies that this tool should be used when an agent needs current order progress, but it does not explicitly state when not to use it or mention alternative siblings. There is no direct comparison to inkflow_order, inkflow_quote, or other related tools.

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

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

With no annotations provided, the description carries the full burden — and it does well: it discloses that this is a paid transaction, that writing starts automatically once payment clears, that progress is available via job status/webhooks, and that an apiKey is required. It stops short of describing failure modes, refunds, or cancellation behavior, but the key side effects are transparent.

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 dense and information-rich but presented as one long, run-on paragraph with heavy ALL-CAPS emphasis and semicolon-separated clauses. It could be significantly improved with bullet points or clearer sentence boundaries. Every sentence does contribute, but scanning and parsing are harder than necessary.

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 14-parameter paid-order tool with no output schema and no annotations, the description covers the core ordering flow, payment behavior, and monitoring paths well. But it omits some product enum values, does not describe the return shape or order confirmation behavior, and leaves several parameters (wordTarget, seriesBooks, lengthTier) without contextual explanation.

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 about 50%, and the description compensates partially by explaining product enum values (e.g., short-video is 9:16, YouTube-video is 16:9, audiobook is narrated from manuscript) and the GBP/credit condition for currency. However, several parameters such as wordTarget, seriesBooks, lengthTier, and genre receive no added meaning, and the 'demo' and 'editor-report' product values are not mentioned.

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 opens with 'Place a paid order' — a specific verb and resource — then enumerates the supported product types (book, manual, technical spec, series, audiobook, videos, packs, films). This clearly distinguishes it from sibling tools like inkflow_quote, inkflow_topup, and inkflow_job_status by establishing that this is the order-placement action.

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

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

The description gives explicit payment-mode guidance: instant settlement with credit and GBP quote versus a Stripe payment URL otherwise. It also points to related tools for top-ups (inkflow_topup) and progress (inkflow_job_status), and states the apiKey prerequisite. It does not directly contrast with inkflow_quote or cover all when-not-to-use cases, but the operational 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?

With no annotations provided, the description carries the behavioral disclosure burden. It discloses that no order is placed, that quotes are honored for 24 hours, and how pricing is computed with margins and floors. It does not cover every possible edge case, but it gives the agent essential behavioral expectations.

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 compact and front-loaded with the core purpose, followed by decision-relevant pricing and validity information. Every sentence earns its place and there is no redundant 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?

The description is sufficient for a quote tool: it explains what it does, how pricing works, and that quotes expire. The lack of an output schema is a minor gap, but 'firm price quote' strongly implies the response contains a price. It could be more explicit about how to convert the quote into an order, but the overall context is usable.

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 50%, so the description needs to compensate for undocumented parameters. It adds useful meaning around product pricing and media types, but it does not clarify currency, lengthTier, wordTarget, seriesBooks, or sourceOrderId beyond what the schema already provides.

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 opens with 'Firm price quote WITHOUT ordering', which clearly identifies the action (quote), the resource (writing/audio/video products), and explicitly distinguishes it from placing an order. It is immediately clear this tool is for pricing only, unlike sibling inkflow_order.

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 phrase 'WITHOUT ordering' clearly positions this as the pre-order pricing tool and implicitly points to inkflow_order as the ordering alternative. However, it does not explicitly state 'use inkflow_order when ready to purchase' or list conditions where a quote would not be appropriate.

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 full behavioral burden. It discloses revenue splits, payout methods, instant credit, verification from file headers, human review before publication, and a strict content policy. This is unusually transparent and useful.

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 the core purpose and every sentence adds relevant operational or policy context. It is slightly dense but not wasteful. The all-caps opening is effective at highlighting intent.

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 single-parameter tool with no output schema, the description covers purpose, financial terms, verification, review, and content policy. It does not describe return values or failure behavior, but those are not critical for invoking 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?

The schema has one parameter, apiKey, with 0% schema description coverage. The description does not explain the apiKey parameter or how it is used. However, the parameter is self-explanatory by name and the tool only has one, so the gap is small but still present.

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 begins with a specific verb and resource: 'LIST YOUR OWN TRAINED LoRA SETS FOR SALE on INKFLOW.' This makes the tool's purpose immediately clear and differentiates it from siblings like inkflow_order, inkflow_balance, and inkflow_train_ultra_lora_actor.

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

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

The description clearly indicates the intended context: selling your own trained LoRA sets. It does not explicitly name alternatives or say when not to use it, but the context is unambiguous and the prerequisite of owning trained LoRA sets is 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?

With no annotations, the description carries the full burden and does well: it reveals that the tool returns a one-time checkout link for a human to pay, rather than directly charging or updating balance. It also emphasizes the human-in-the-loop aspect, which is critical for an agent deciding whether to invoke this 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?

Two tightly packed sentences with no filler. The action is front-loaded, followed by the critical behavioral caveat and human-in-the-loop note. Every 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?

Completeness is strong for a simple two-parameter tool with no output schema. The description explains the return value (checkout link), the payment flow, and the reason this step needs a human. Minor gaps like currency units are already hinted by the parameter name and schema range.

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 50%; only gbp has a description ('5 to 2000'). The description adds context for apiKey by calling it 'your INKFLOW API key,' but it doesn't clarify that gbp is the amount in British Pounds. It partially compensates for the coverage gap but not fully.

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 opens with a specific verb and resource: 'Add credit to your INKFLOW API key.' It also distinguishes itself from siblings by noting this is the only step that needs a person, which sets it apart from tools like inkflow_balance or inkflow_order.

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?

Clear context is provided: top up when balance runs out and human payment is needed. It doesn't explicitly name alternatives or exclusions, but the phrase 'after that you transact autonomously until the balance runs out' implies when to use it versus continuing with other operations.

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?

There are no annotations, so the description carries the full behavioral burden and does so thoroughly. It discloses the 4,500+ step rank-64 training, .safetensors output, reference pack, perpetual commercial license, synthetic-person guarantee, and the conditional training-start workflow. This goes well beyond a simple 'creates' or 'updates' statement.

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 the core purpose and packs deliverables, licensing, workflow, and pricing into three information-dense sentences. It is slightly long, but every clause contributes operational or commercial meaning with no 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 a paid custom-training tool with no output schema, the description covers the essential flow: what the user receives, what the agent should capture in the actorBrief, the required follow-up face choice, and the flat $48 price. It omits delivery time and result-return mechanics, but those are secondary for correctly starting the transaction.

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 only 20%, so the description needed to compensate for the undocumented parameters apiKey, currency, actorName, and webhookUrl. It only elaborates on the actor brief and the face-selection step, leaving important invocation details about authentication, currency handling, and webhook behavior unexplained.

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 opens with a specific action—'Commission a custom ULTRA-trained LoRA digital actor'—and specifies the exact deliverable format, training scale, and identity purpose. It also distinguishes this tool from the sibling inkflow_choose_actor_face by positioning it as the ordering step that precedes face selection.

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

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

The description clearly explains the usage sequence: order, receive candidate thumbnails, then choose a face before training starts. It names the next tool to call, inkflow_choose_actor_face, which gives an agent actionable routing guidance, though it does not explicitly exclude alternatives like inkflow_order or inkflow_free_samples.

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