Performance Atlas

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

Annotations carry the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false). The description adds crucial behavior beyond annotations: cost and currency, on-chain payment requirement, that the result is a reusable bearer token, and critically the accounting rule that failed calls are free — a non-obvious, high-value detail.

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

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

Three sentences, all load-bearing: what/how (purpose, payment), what you get (token), and how/when usage applies (per-call consumption, failed calls free). No filler, front-loaded.

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

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

For a zero-parameter purchase tool, everything needed to call it correctly is present: cost, payment network, artifact returned, and the exact consumption mechanism on sibling tools. No output schema exists, but the description compensates fully by describing the returned token and its lifecycle.

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?

Input schema has zero parameters (baseline 4). The description still adds meaning by explaining that the purchase's output is a token to be injected as params._meta['creatinginai/pack'] on sibling tools, which is the real parameter semantic an agent needs.

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 (Buy), resource (a pack of 20 paid calls), price ($1.00), and payment channel (x402 in USDC on Base) in a single sentence. Clearly distinguishes itself from data-retrieval siblings like atlas_kit/atlas_draft by being the payment instrument that feeds them.

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

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

Explicitly states when to use it (to avoid paying per call) and exactly how the returned token is consumed (send as params._meta["creatinginai/pack"] on atlas_kit or atlas_draft). Names the downstream tools, so the purchase-to-use flow is unambiguous.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds material context the annotations cannot convey: the call is paid ($0.10/call via x402 USDC on Base, or 20 for $1.00 with atlas_buy_pack) and the output is a mechanical scaffold that must be rewritten, with a different return shape for voice targets. It does not cover failure modes or what happens if the character cap is exceeded.

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

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

Four tight sentences, front-loaded with what the tool produces and how to treat the result; the output-disposition instruction and pricing follow logically. The pricing clause is somewhat long but carries real invocation-relevant information, so little 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?

With 9 parameters (nested objects, enums) and no output schema, the description does describe the returned artifact and its voice-target variant, which is a real contribution. However, it never explains the return envelope or the meaning of key domain terms (kit, elements mode, character cap), leaving the agent to infer a good deal.

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

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

Schema description coverage is 100% and the nested state object is thoroughly documented, so the schema carries the parameter burden. The description adds only oblique references ('from the kit', 'the target's character cap') without clarifying how parameters like beats, control, or shows affect the output. Baseline 3 is appropriate.

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

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

States a specific verb+resource: assembles a first-draft acting paragraph from the kit, fitted to the target's character cap and already linted. It references the sibling artifacts it depends on (kit, lint, targets, atlas_buy_pack), though the domain jargon ('kit', 'character cap', 'delivery line') is not defined, so differentiation from atlas_show/atlas_kit is only partial.

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 post-call guidance ('It reads mechanically: rewrite it as prose') and one output branch ('A voice target gets the delivery line instead'), plus the paid alternative atlas_buy_pack for bulk. It never states when to reach for this tool versus atlas_show or atlas_kit, so the usage guidance is implied 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?

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is low, yet the description adds real behavior: the exact semantics of reset/breach/overshoot/flat and the carry-over rule for omitted fields. 'Free' signals a cost trait not captured anywhere in structured data.

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 paragraph that front-loads the deliverable and then defines each flag inline. Every clause carries information, though the parenthetical flag glossary makes it slightly dense to scan.

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

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

With no output schema, the description usefully sketches the return (flags per beat) and the carry-over rule. However, with three optional params it never explains when to pass 'project' versus 'characters', leaving a real ambiguity for a nested-object tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds a genuine semantic rule beyond the schema: 'Fields a beat leaves out carry over from the beat before', which governs how the nested beat objects should be authored. It does not clarify the project-vs-characters input choice.

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 concrete resource and output: a character's arc 'beat by beat' with named continuity flags. The title 'Check a journey' plus the flag taxonomy make the analysis function legible. It does not explicitly differentiate from siblings like atlas_lint or atlas_show, which would be needed for a 5.

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/when-not guidance and no named alternative. The trailing 'Free' hints at a cost tradeoff against a paid sibling (atlas_buy_pack), but the agent is left to infer whether to reach for this over atlas_lint or atlas_show.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes further by disclosing the payment model ($0.10 per call via x402 on Base, or 20 for $1.00 with atlas_buy_pack), which is significant operational context an agent would not otherwise know. It stops short of describing the return shape or latency.

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

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

Three sentences: what the kit is, how to use it, and cost. The deliverable is front-loaded and the pricing trailer is separated cleanly. The first sentence is dense with parenthetical asides, but nothing is redundant.

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 nine-parameter, nested-object generation tool with no output schema, the description usefully sketches what the kit contains and points to the next step (atlas_lint). Pricing is covered. Only the actual return format is left implicit, which is acceptable given the content overview.

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

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

Schema description coverage is 100%, so all nine parameters are already documented in the schema. The description lightly reinforces meaning ('shot size — where the tell can be seen', the target model's rules) but adds no syntax or format detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description names a concrete deliverable (a direction kit for a character state) and enumerates its contents — beat-by-beat behaviour fitted to shot size, eye life, breath, target-model rules, a voice delivery line — which is specific enough to distinguish it from generic drafters. It also names atlas_lint as the follow-up. It does not, however, differentiate itself from close siblings like atlas_draft or atlas_show.

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

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

It gives a workflow chain ('Write the acting prose from it, then atlas_lint the prose'), which implies when to reach for this tool, but offers no explicit when-to-use-vs-alternatives guidance against atlas_draft, atlas_show, or atlas_journey. Usage is inferable but not spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds value the annotations cannot: it is free (no credit cost), and it discloses the return contract — "ok is true when there are no errors; each finding carries its fix" — which matters since no output schema exists.

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 the credit-saving rationale are front-loaded, and the two trailing clauses deliver the result contract compactly. The opening sentence is dense with a long list of checks, but every item earns its place by telling the agent what will be flagged.

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 7-parameter validator with a deeply nested state object and no output schema, the description covers the essentials: what is validated, the cost profile, and the shape of the result. Minor gaps remain (no explicit statement of when validation is unnecessary, no severity model), but nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so every parameter including the nested state object is already documented in the schema; baseline 3 applies. The description only lightly reinforces this, tying the tell check to the state ("a tell bigger than the state allows") and pointing to atlas_targets for target ids, without adding syntax or defaults beyond the schema.

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

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

States a specific verb (check/lint) and resource (an acting paragraph or voice direction), and enumerates the exact defect classes it detects — emotion labels, mugging, lens looks, quoted speech, oversized tells, character caps. That level of specificity clearly separates it from siblings like atlas_draft or atlas_show, which generate rather than validate.

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?

"before spending credits" gives a clear trigger for when to reach for this tool, and the target parameter points to atlas_targets for valid ids. It stops short of naming an explicit alternative or stating when-not to use it, so it falls just under the top tier.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely new traits beyond that: that the operation is 'Free' (a cost property annotations cannot express) and that 'what comes back is behaviour' (a return-nature hint in the absence of an output schema). It does not mention ranking or pagination behavior, so it stops short of a 5.

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

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

Three short sentences, front-loaded with the scope and corpus, followed by the query intent and the cost/return note. Every sentence earns its place with no repetition of structured fields.

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 five-parameter, no-output-schema search tool, the description covers the corpus, query intent, result nature and cost. With no output schema it could say more about result shape (grouping, ordering, why a query returns cues rather than the emotion matched), leaving a small gap for an otherwise complete definition.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters including the shot enum, limit range and table/channel filters; the baseline is therefore 3. The description adds a mild nuance by framing the query intent ('search by emotion or situation'), but no syntax, format or filtering semantics beyond what the schema 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 a specific verb+resource ('Full-text search across behaviour cues, FACS action units, expressions...') and enumerates the searchable corpus, so the agent knows exactly what this tool covers. It does not explicitly differentiate itself from the seven siblings, but none of them (buy_pack, draft, journey, kit, lint, show, targets) is a search tool, so the purpose is unambiguous.

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?

'Search by emotion or situation; what comes back is behaviour' implies the intended query pattern and hints that the result type differs from the query type. However, there is no explicit when-to-use vs when-not guidance and no routing to any alternative tool, so usage is only implied rather than stated.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds two things the annotations do not: the response bundles related records that reference the entity, and the call is free (relevant next to paid siblings such as atlas_buy_pack). It still says nothing about errors for a missing id or result size.

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 sentence with the primary lookup mode front-loaded and the alternate key and return scope packed into parentheticals. No filler and nothing an agent must read past to act.

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 one-parameter read tool with no output schema and full annotation coverage, the description covers the lookup key, the return scope, and the cost. The remaining gap is minor: no indication of behavior on an unknown id or the shape of the returned records.

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

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

With one parameter at 100% schema description coverage, the schema already explains that id accepts 'a record id from a kit or search, or an emotion name.' The description restates the same duality without adding format, source, or resolution guidance beyond it, so the baseline 3 applies.

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

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

Names a specific resource ('one atlas record') and two lookup keys (record id or emotion name), plus the payload shape ('with the records that use it'). It is distinguishable from atlas_search in that it fetches a single known entity rather than querying, though it never names the sibling explicitly.

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

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

'by id (or an emotion by name)' implies the precondition that you already have an identifier, which is a usable usage cue. However, it never states when to prefer this over atlas_search or atlas_kit, and the 'Free' note hints at a cost-based decision without saying how it selects against the paid siblings like atlas_buy_pack.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds two things beyond that: the tool is 'Free' (no credit cost, meaningful given the paid atlas_buy_pack sibling) and the content shape of the response. It goes modestly beyond structured data without contradicting it.

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 tight sentences plus the one-word cost note 'Free'. The resource description is front-loaded and nothing is redundant or padded; 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?

With no input parameters, no output schema and rich annotations, the description carries the remaining burden by stating what the returned records contain (models, character caps, requirements) and how the ids are reused. Nothing an agent needs to call this correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4 per the rubric. The description still usefully clarifies that a 'target id' is the value this tool yields and that other tools consume, which gives the otherwise-absent parameter concept meaning.

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 specifically what the tool returns: the target models the atlas knows, each with its prompt-field character cap and requirements. It is clearly a catalog/lookup resource distinct from the action-oriented siblings (atlas_draft, atlas_lint, atlas_kit), though the phrasing is nominal rather than a verb+resource claim.

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?

'Pass a target id to atlas_kit, atlas_draft and atlas_lint' explains the downstream role of the returned ids, which effectively tells the agent when to call this first. It gives clear context but no explicit when-not condition or exclusion relative to other lookup siblings such as atlas_show or atlas_search.

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