knos

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the tool returns every step with its Qloo call, input, output and effect, plus decision outputs like OPEN/REFUSE and escrow details. However, it says nothing about permissions, side effects, rate limits, reversibility, or other operational constraints.

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

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

The description is a single compact sentence that front-loads the input and then lists the processing chain and outputs. It avoids filler, though the arrow notation is dense and less scannable than separated clauses.

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?

This is a complex orchestration tool with no annotations, no output schema, and four completely undocumented input parameters. The description adds some return-shape context but leaves major gaps in input semantics and usage conditions that an agent needs in order to invoke it correctly.

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

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

Schema description coverage is 0% across four parameters. The description only partially covers one parameter, ref, by naming accepted paper identifier types (DOI, arXiv, PubMed, OpenAlex), and gives no meaning or format for idea, place, or product.

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

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

The description states a specific pipeline: paper ID becomes a research card, then Qloo evidence at each decision, producing who/where/price tier/escrow targets and an OPEN or REFUSE outcome. This is clear enough for an agent to understand what the tool does, though it does not explicitly differentiate itself from siblings such as knos_crossings or knos_research_card.

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

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

No when-to-use, when-not-to-use, prerequisites, or alternative-tool guidance is provided. The pipeline implies it is used when starting from a paper identifier to evaluate a funded product, but the agent is left to infer all usage conditions.

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 discloses ordering ('newest first') and returned fields (id, paper or idea, verdict, report hash), which helps an agent know what it will get. It does not state that this is read-only, whether there is a result cap, or how many crossings are returned, which are important for a zero-parameter listing 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?

One compact sentence, front-loaded with the resource and ordering, and the returned columns are listed efficiently. Nothing is wasted.

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 listing with no output schema, the description gives the scope, ordering, and field names, which is nearly enough to call it correctly. Missing only a note on volume or caps and an explicit safe/read-only statement.

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?

There are 0 parameters, so the baseline is 4. The description correctly does not invent parameters and instead describes outputs. It could explicitly say 'no parameters – returns all crossings', but the omission is minor.

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 ('Every crossing this server ran') and the ordering ('newest first'), plus enumerates returned fields. Clear enough to distinguish from knos_cross (which presumably creates a crossing) and from other knos_* memory tools.

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

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

The phrase 'this server' implies a server-scoped listing, but there is no explicit when-to-use guidance, no mention of limits or pagination, and no exclusions or alternatives such as knos_memory_search. Usage is only weakly implied by the name and description.

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 hints at a processing path (product idea -> Qloo evidence -> code-made decision), which suggests an analysis rather than a mutation, but it never states side effects, whether the call is read-only, auth requirements, latency/cost, or how the decision is represented. "A decision made by code" is opaque rather than disclosive.

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 short, but the brevity reflects under-specification rather than economy: one arrow fragment with no sentence that actually states what the tool does or returns. Nothing is wasted because almost nothing is said.

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 annotations, no output schema, and 0% parameter documentation, the description is the only source of information and it is a single fragment. The agent cannot determine the return type, the meaning of "decision," the role of `place`, or any usage constraints, making the definition inadequate for a two-parameter 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 description coverage is 0% for both parameters. The phrase "product idea" loosely maps to the required `idea` parameter, but the optional `place` parameter is never mentioned anywhere, so an agent cannot know it controls geography or what format it expects. The description does far too little to compensate for the coverage gap.

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 title ("Is this product wanted?") plus the arrow fragment convey the gist: evaluate demand for a product idea using Qloo evidence and return a coded decision. But the description itself has no verb and never says what the "decision" is or how it is expressed, so the purpose is vague rather than specific. It also does not distinguish itself from siblings like knos_evidence or qloo_where_popular.

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

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

There is no statement of when to use this tool versus the many qloo_* siblings (qloo_rank, qloo_where_popular, qloo_recommend) or knos_evidence. No prerequisites, no exclusions, no trigger conditions are given. The agent is left to infer usage entirely from the name.

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 that the call moves funds, posts work, is gated on human confirmation, needs a session token, and operates on devnet test money only. It doesn't cover failure modes, idempotency, or what 'verified' means in practice.

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

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

Purpose and consequence are front-loaded, then the confirmation warning and auth requirement follow immediately. The semicolon-chained clauses pack a lot in, but every sentence carries a distinct constraint 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 no-annotation, no-output-schema mutation tool, the description supplies the critical context: irreversible side effect, human-confirmation gate, credential source, and test-only environment. Return behavior and edge cases are unstated but less critical here.

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 all three required parameters. It explains only 'session' (obtained from knos_sign_in); 'commitment' is left entirely undefined and 'evidence_url' is only implied by the tool title.

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 ('Posts a milestone's public evidence page') and adds the consequential outcome ('verified evidence releases the escrow to the maker'). That escrow-release effect clearly separates it from generic post/submit siblings like knos_task_submit.

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

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

Gives an explicit precondition ('CONFIRM FIRST... Ask the human you work for before calling') and tells the agent where the session token comes from ('knos_sign_in returned'). It stops short of naming alternative tools for the case where the agent shouldn't post evidence, so no exclusion 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 behavioral burden. It hints at returned content (product phrase, verdict, report) and an ephemeral 'working memory' scope, but says nothing about required permissions, read-only nature, behavior when nothing is remembered, or why both parameters are optional.

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 short sentence is efficient, but the cryptic framing ('Sibyl, the crossing agent's working memory') spends words on persona rather than stating the operation, so it is concise without being front-loaded with actionable meaning.

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 2-parameter tool with no annotations, no output schema, and zero schema description coverage, the description is far too thin. Neither parameter's role nor the return shape is explained, leaving clear gaps an agent must fill by guessing.

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%, so both 'ref' and 'idea' are undocumented in the schema and the description fails to compensate. The phrase 'a paper or idea' faintly gestures at the 'idea' parameter, but 'ref' is never explained, leaving how to address a paper ambiguous.

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 conveys the resource ('the last crossing of a paper or idea') but frames it as a noun phrase rather than a clear verb+action, relying on 'memory_recall' in the name to supply the operation. Its mention of 'the last crossing' does partly differentiate it from the sibling knos_memory_search, but an agent still has to infer whether this returns, records, or looks up a memory.

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

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

There is no explicit guidance on when to use this versus alternatives such as knos_memory_search, knos_crossings, or knos_cross. The phrase 'working memory' only loosely implies a recall context, leaving the agent to guess the trigger conditions.

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 are absent, so the description carries the full burden. It names the engine (FTS5) and multilingual support, but says nothing about result ordering, ranking, limits, permissions, or return shape for a 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?

One compact sentence with no filler; scope is front-loaded. It is perhaps too terse given the gaps elsewhere, but nothing is wasted.

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 annotations, no output schema, and an undocumented query parameter, the description is far too thin. It doesn't tell the agent what results look like or how to phrase queries.

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% and there is a single required parameter 'q', but the description only implies a query string without explaining FTS5 syntax, phrase handling, or multilingual matching behavior.

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

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

States a specific verb (search) and the resources it spans: agents' memory and the Knos Record, enumerating content types (papers, crossings, decisions, events). It's clearly distinct from knos_memory_recall and knos_crossings, though 'search everything' slightly blurs the line.

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

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

No guidance on when to use this versus knos_memory_recall, knos_crossings, or knos_evidence. The sibling names imply overlap, and the agent must guess which retrieval tool applies.

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

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

With no annotations, the description must carry the full behavioral burden. It does disclose return content fields and one business rule (locked milestones require an evidence page), which is real added context, but it omits any read-only/reversibility statement, ordering, or result-size behavior for what is implicitly a full-server listing.

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 short sentences with no filler, and the resource is front-loaded. But the compression creates ambiguity — "every commitment" and "a locked one" require the reader to guess at entities and status semantics, so brevity costs clarity.

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 listing tool with no output schema, the description must explain the return shape. It names a few fields but does not describe structure, cardinality, or what the status values / claim id mean, so it is only partially complete.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. Nothing in the description conflicts with the empty schema, and no parameter meaning needs compensation.

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 identifies the resource ("every commitment on this server") and enumerates returned fields (escrow order, units, status, claim id), so an agent can infer this is a listing tool. However it never states a verb and does not differentiate itself from close siblings like knos_tasks, knos_task_submit, or knos_evidence, leaving the scope of "commitment" vs "task" ambiguous.

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

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

There is no explicit when-to-use, no when-not-to-use, and no named alternative among the many knos_* siblings. "A locked one needs an evidence page" is an oblique hint toward knos_evidence but is too cryptic to function as 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 that this moves devnet test money or posts work, that it locks units (a mutating side effect), that human confirmation is required, and that no real funds are involved. It does not describe the result of the operation or failure modes.

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?

Short, front-loaded, and the safety-critical instruction is emphasized in caps before the mechanics. Minor redundancy between 'moves devnet TEST money' and 'Test money only; no real funds', but every sentence is functional.

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 3-param mutation tool with no annotations and no output schema, the description covers safety, auth provenance, and parameter meaning adequately. It omits any indication of what is returned or what happens on failure, which is the remaining 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?

Schema description coverage is 0%, so the description must compensate, and it gives meaning to all three parameters: 'report' must be an OPEN report, 'units' are the quantity locked, and 'session' is the token returned by knos_sign_in. It adds no format, type, or range detail (e.g., report identifier format, unit bounds).

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 ('Locks units') and resource ('an OPEN report in devnet escrow') plus the mechanism ('the app's demo buyer'), which is far more concrete than the bare tool name. It does not explicitly contrast itself with near siblings like knos_task_submit, so differentiation is left partly to inference.

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

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

Gives an explicit precondition (CONFIRM FIRST, ask the human before calling) and a prerequisite (pass the session token that knos_sign_in returned), which is real routing guidance. It stops short of stating when this tool should not be used versus alternatives.

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 full burden. It does disclose the card's contents (quoted result, retraction status, recognition), which is genuinely useful given there is no output schema, but it says nothing about read-only safety, authentication, rate limits, or error behavior for an invalid 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?

A single dense fragment with no filler, and the input-to-output relationship is front-loaded. The arrow shorthand is efficient but borders on cryptic for an agent unfamiliar with the convention.

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 annotations, no output schema, and 0% parameter coverage, the description does the heavy lifting on return values, which is a real contribution. It remains incomplete on ref format, failure modes, and routing against the many sibling retrieval tools.

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. The arrow notation does identify the single input as a 'paper id', which is more than the bare string type in the schema, but the expected format (DOI, internal id, external index id) is never specified.

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 plus title identify a specific resource (a landmark paper, keyed by paper id) and enumerate the exact payload it returns — proven result, citations, retraction status, Nobel recognition, enabling product. That is enough for an agent to know what the tool produces. It stops short of 5 because it never differentiates itself from lookalike siblings such as knos_evidence or knos_memory_recall.

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

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

There is no when-to-use guidance, no prerequisite, and no named alternative. With a sibling set containing knos_evidence, knos_memory_search, and knos_memory_recall, the agent gets no signal about which retrieval tool fits which question.

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 whole burden, and it does disclose real behavioral facts: it returns a token that must be forwarded, it can move devnet TEST money or post work, and no real funds are involved. It omits token lifetime/expiry, whether repeat calls create multiple sessions, and any failure behavior, which for a session-issuing tool is a meaningful residual 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?

Three short sentences, with the core purpose ('Returns a session token') front-loaded before the confirmation warning. Slight redundancy in restating test-money-only twice ('devnet TEST money' and 'Test money only; no real funds'), though the repetition is plausibly deliberate safety emphasis.

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 1-parameter sign-in tool with no output schema, the description covers the essentials: what it returns, that the return value must be reused, and the confirm-first requirement. Missing only secondary details like token lifetime or what happens on repeated sign-ins.

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%, with the single 'label' parameter already documented as 'who your human is (a display label)', so the baseline is 3. The description says nothing about the label, and its token-passing sentence refers to the return value, not the input, so no extra parameter meaning is added.

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

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

States a specific verb+resource ('Returns a session token') and scopes it to 'the money tools', which is enough to separate it from every listed sibling, none of which is an auth/money tool. It never names the specific sibling tools the token feeds, so differentiation is by exclusion rather than by explicit reference.

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 when-to-use context: call it to get a token, then pass that token to the money tools, and confirm with the human before calling. There is no alternative tool to route away from, so no exclusions are needed, but the ordering constraint (before the money tools) is only implied by 'need'.

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. It does disclose two useful behavioral facts: work is judged and payment is test money on devnet, which sets expectations about evaluation and stakes. It says nothing about whether sign-in is required (knos_sign_in exists) or whether this is a pure read.

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 front-loaded sentence with no filler; the scope is stated first and the payment caveat second. It is dense jargon ('game rounds', 'devnet') but every clause 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?

For a zero-param, no-output-schema, no-annotation tool the description needs to cover domain, access, and return expectations. It covers domain and payment model well but omits auth requirements and what a returned item looks like, leaving real gaps an agent must guess at.

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. Listing 'game rounds and milestones' does clarify what concept the (empty) query returns, but no parameter meaning is needed or added.

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 (open game rounds and milestones) and its purpose (work for contributors), which is specific enough to separate it from knos_task_submit and knos_milestones. It never explicitly contrasts itself with those siblings, so it loses the top score.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as knos_task_submit for handing work in. The audience phrase 'a person or agent can work on' only loosely implies it is a discovery step.

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, so the description carries the burden and does well: discloses immediate sealed-referee judging, prize payout to a devnet wallet, test units only, and a prominent confirm-first requirement with the session token prerequisite. Minor gap: no detail on rate limits or what happens on failed attempts.

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

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

Front-loads purpose, then behavioral notes, then a bolded confirm-first directive. Dense but largely earned; the confirm-first sentence is somewhat repetitive but justified for a money-moving action.

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 5-param mutation tool with no annotations and no output schema, the description covers purpose, safety, and confirm-first requirements well. The main shortfall is parameter documentation, especially the undocumented 'name' and the exact role of 'code'.

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%, so the description must compensate. It only implicitly touches 'code' (train.py), 'round', 'wallet', and 'session'; 'name' is never mentioned and no parameter is explained at a level useful for correct invocation.

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 (submits) and resource (the whole train.py to an open round), and explicitly distinguishes from sibling knos_tasks ('knos_tasks says what to change'). An agent can tell this apart from knos_tasks 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?

Clear context: submit to an open round, several attempts allowed, links to knos_tasks for what to change. Sets a 'CONFIRM FIRST' precondition, but doesn't explicitly state when-not to use versus other siblings like knos_sign_in (only referenced as prerequisite).

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 behavioral burden, and it discloses nothing: not whether the call is read-only or mutating, whether it requires auth, rate limits, or what it returns. 'LIVE' hints at a real-time backend but is not actionable.

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 a single short sentence, but its brevity reflects under-specification rather than efficient information density. The only content is provenance, which does not earn its place as the sole statement about the 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 tool with no annotations, no output schema, and an empty input schema, the description should explain the purpose, expected inputs, and result shape. It supplies none of that, leaving the agent unable to determine what the tool does or how to call it meaningfully.

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 declares zero parameters (additionalProperties: true), so there is no parameter semantics to document and no coverage gap to compensate for. Baseline 4 applies when there are no params.

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 merely restates the tool name ('qloo_audience_demographics') and adds provenance metadata ('proxied from this server's `qloo mcp` (LIVE)'). It never says what the tool actually does, what an 'audience demographics' operation returns, or how it differs from siblings like qloo_compare_audiences or qloo_where_popular.

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

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

There is no when-to-use guidance, no exclusions, and no mention of alternatives. The one descriptive clause concerns deployment ('LIVE'), not invocation context, so an agent has nothing to route on.

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 behavioral burden, yet discloses nothing: no read-only nature, no auth/permission requirements, no rate limits, no indication of what is returned. The provenance sentence adds no behavioral information an agent can act on.

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 a single short sentence, so it is not bloated, but this is under-specification rather than conciseness — the one sentence conveys only identity and transport, not function.

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-param discovery tool with no annotations and no output schema, the description should explain what capability information is returned and when to call it. Nothing an agent needs to invoke it correctly is present.

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

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

The schema declares zero parameters (additionalProperties: true), so there is nothing for the description to clarify; baseline 4 applies for a parameterless tool.

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 only restates the tool name and asserts provenance ('proxied from this server's qloo mcp'). It never says what the tool does — presumably enumerate available qloo capabilities — so an agent cannot distinguish it from qloo_describe or any other sibling.

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

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

No when-to-use, when-not-to-use, or alternative is given. The phrase '(LIVE)' hints at live data but provides no actionable routing guidance among the 20 sibling 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?

No annotations are provided, so the description carries the full behavioral burden and largely fails: it says nothing about read-only vs mutating behavior, auth needs, rate limits, or how comparisons are computed. The only signal is the '(LIVE)' provenance hint implying fresh rather than cached data, which is a small but real behavioral clue.

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 a single short sentence, so there is no bloat, but the sentence spends its only words on provenance metadata instead of front-loading purpose. Conciseness without substance is under-specification rather than efficiency.

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

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

With no parameters, no annotations, and no output schema, the description was the only place an agent could learn what a 'compare audiences' call does or returns, and it supplies nothing. The definition is inadequate for an agent to select or invoke the tool with confidence.

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 an open object with additionalProperties, so there are no parameter semantics to document. Per the rubric, zero parameters yields a baseline of 4 regardless of description content.

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 never states what the tool does beyond restating its own name; it only asserts provenance ('official qloo-harness tool... proxied from this server's `qloo mcp`'). An agent learns it is a 'compare audiences' tool only from the name, not from any verb+resource explanation, and nothing distinguishes it from siblings like qloo_audience_demographics or qloo_rank.

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

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

There is no guidance on when to use this tool, when not to, or which sibling (qloo_audience_demographics, qloo_rank, qloo_trends, etc.) is the alternative. Nothing indicates what inputs drive the comparison or what preconditions apply.

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, yet it discloses nothing about behavior: no output format, no side effects, no prerequisites, no rate limits. 'Proxied from qloo mcp' is provenance trivia, not behavioral 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?

It is short, but the one sentence is spent on provenance and name restatement rather than on what the tool does. It is concise without being informative.

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 annotations, no output schema, and a description that never explains the tool's function or return value, an agent has no basis for deciding to call it or what to expect. For a zero-parameter query tool this is completely 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?

The tool takes zero parameters, so there is nothing for the description to compensate for; the baseline is 4. No parameter details are needed.

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 restates the tool name and says it is a proxied official tool, but never states what 'describe' does — describe what, an entity, a schema, the server? It gives no verb+resource specificity and does not distinguish it from a dozen siblings like qloo_capabilities or qloo_entity_tags.

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

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

There is no guidance on when to use this tool versus alternatives. The parenthetical '(LIVE)' and 'proxied' offer no selection criteria.

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 behavioral burden, yet it discloses nothing about read/write nature, authentication, rate limits, or response shape. The only hint, '(LIVE)', is meaningless for invocation decisions.

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 a single short sentence, so there is no bloat, but the sentence does not earn its place: it conveys no actionable information about the tool. Brevity here reflects under-specification rather than good structure.

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

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

With no annotations, no output schema, and an empty parameter list, the description is the only source of context an agent has, and it provides none. It is completely inadequate for selecting or invoking this tool correctly.

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

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

The schema declares zero parameters, so per the baseline there is little parameter meaning the description could add. The one caveat is that additionalProperties:true implies undeclared input may be accepted, which the description does not clarify, keeping this from a 5.

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 sentence only restates the tool name and asserts provenance ('official qloo-harness tool ... proxied from this server's `qloo mcp`'), which is tautological rather than a statement of what the tool does. It gives no verb and no indication of what 'entity tags' returns, so an agent cannot separate it from siblings like qloo_find_tags, qloo_describe, or qloo_rank.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of any alternative despite a large sibling set (qloo_find_tags, qloo_capabilities, qloo_audience_demographics, etc.). The agent is left to guess the tool's role entirely.

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 supplied, so the description carries the full disclosure burden, yet it reveals nothing about behavior, return content, or side effects. The '(LIVE)' marker is ambiguous and conveys no actionable trait.

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 single sentence is short, but it is almost entirely wasted on provenance trivia rather than the tool's function. Brevity here reflects under-specification, not disciplined editing.

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 annotations and no output schema, the description is the only source of intent, and it supplies none. An agent has no basis for deciding whether to invoke qloo_find_tags over its many siblings.

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 clarify beyond the schema; baseline 4 applies. The description adds no parameter meaning, but none is needed.

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 only asserts provenance ('official qloo-harness tool ... proxied from this server's `qloo mcp`') and restates the tool name; it never says what the tool actually does. An agent cannot tell what 'find tags' means or how it differs from siblings like qloo_entity_tags.

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

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

There is no indication of when to use this tool, when not to, or which alternative (e.g. qloo_entity_tags, qloo_describe) it replaces. No guidance whatsoever is provided.

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 behavioral burden. It discloses nothing about side effects, permissions, rate limits, return behavior, or whether the operation is read-only or destructive.

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 single sentence is technically concise, but it is under-specified rather than informative. It does not front-load a meaningful purpose or any actionable detail.

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 any tool, especially one in a rich sibling set with no annotations and no output schema, the description is completely inadequate. An agent cannot determine what qloo_rank does or when to select it.

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

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

The tool accepts zero parameters, and the baseline for zero-parameter tools is 4. The description adds no parameter information, but there are no parameters to document.

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 only restates the tool name and says it is proxied from `qloo mcp` (LIVE). It does not state what qloo_rank actually does, what resource it operates on, or how it differs from sibling tools such as qloo_recommend or qloo_compare_audiences.

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

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

There is no guidance on when to use qloo_rank, when not to use it, or which sibling tool is the alternative for related tasks. The agent must guess entirely from the name.

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 behavioral burden, and it discloses nothing: no read/write nature, no auth requirements, no rate limits, no return shape, no cost. The provenance sentence conveys deployment mechanics, not behavior an agent can act on.

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 short, but the single sentence is spent on name repetition and proxy provenance rather than front-loading purpose. Brevity achieved by omission rather than by editing, so it does not earn 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?

For a tool sitting in a 21-sibling qloo/knos namespace with no annotations and no output schema, the description supplies no distinguishing information at all. An agent cannot determine what this tool returns or when it is the right choice.

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 declares zero parameters, so there is no parameter semantics for the description to explain; the baseline for a zero-param tool is 4. The description neither misleads nor adds anything 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?

The description only restates the tool name and asserts provenance ('The official qloo-harness tool qloo_recommend, proxied from this server's `qloo mcp`'). It never states what the tool does — no verb, no resource, no output kind. Among siblings like qloo_rank, qloo_compare_audiences, and qloo_trends, an agent has no basis to select this one.

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

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

No when-to-use, when-not-to-use, or alternative routing is given. The '(LIVE)' marker hints at data freshness but does not explain what condition should select this tool over qloo_rank or qloo_find_tags.

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 of behavioral disclosure, and it discloses nothing beyond the '(LIVE)' proxy note. It does not say whether this is a read or write, what authentication or quota applies, or what the output looks like.

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 a single short sentence with no filler in the structural sense, but the sentence is spent entirely on provenance trivia rather than on information an agent can act on. Brevity here reflects under-specification rather than disciplined 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?

With no annotations, no output schema, and no parameter documentation, the description is the only source of context and it provides none. An agent cannot infer what the tool returns or when it should be chosen over the other qloo_* siblings.

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 are no parameter semantics to explain and the baseline of 4 applies. The description adds no parameter context, but none is needed.

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 essentially restates the tool name ('qloo trends' / 'qloo_trends') and adds only provenance metadata about being proxied from the qloo mcp server. It never states what a 'trend' is here, what entity or category the trends pertain to, or what the tool returns, so it is a tautology rather than a purpose statement.

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

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

There is no indication of when to use qloo_trends versus any of the many siblings such as qloo_rank, qloo_where_popular, qloo_recommend, or qloo_compare_audiences. No conditions, prerequisites, or exclusions are given.

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 of behavioral disclosure, and it discloses nothing: not whether the call is a read, whether it requires auth or a configured entity, how results are scoped, or what the response contains. Only hosting metadata is offered.

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 a single short sentence with no filler, so it is not verbose. However, the sentence is entirely provenance framing rather than a front-loaded functional statement, so brevity comes at the cost of substance.

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, no annotations, and no parameter descriptions, the description must supply the functional picture; instead it supplies none of it. An agent has no basis to know what calling this tool returns or when it is appropriate.

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 (additionalProperties: true, coverage 100%), so there is no parameter semantics for the description to add. Per the 0-parameter baseline this sits at 4; the description neither helps nor harms 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?

The description is essentially a tautology: it restates the tool name and adds only deployment provenance ('official qloo-harness tool', 'proxied from this server's qloo mcp (LIVE)'). It never states what 'where popular' actually does – e.g. returning popularity by geography for an entity – so an agent cannot distinguish it from siblings like qloo_rank or qloo_trends.

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

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

There is no when-to-use guidance, no exclusions, and no mention of alternatives among the 20 sibling tools. Nothing indicates the conditions under which this tool should be selected over qloo_rank, qloo_trends, or qloo_recommend.

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