iDos Games

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

Annotations confirm non-destructive and non-open-world, and the description adds genuinely useful context the annotations cannot carry: the comment is published under the publisher's own name (an identity/attribution constraint that should change how the agent writes) and that mentioned people are notified. It stops short of saying whether comments are editable or deletable after posting.

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, zero filler, and the core action is front-loaded before the behavioral caveats. 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?

With no output schema and full parameter coverage, the description only needs to convey purpose plus behavioral caveats, and it does so for a simple mutating tool. It is slightly thin on post-conditions (edit/delete, threading behavior), but nothing needed to call 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 description coverage is 100%, so all five parameters are already documented in the schema (including that mention_ids comes from list_kanban_members). The description only adds the side effect of mention_ids; it adds nothing about body formatting or parent_comment_id semantics beyond the schema. Baseline 3.

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 ('Post a comment on a card') in the first sentence, which cleanly separates it from the read-side sibling get_kanban_comments and from card-level mutations like update_kanban_card. An agent needs no schema inspection to know what this does.

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

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

Usage is implied rather than stated: 'Mentioned people are notified' hints that mention_ids is the notify path and the optional params are opt-in, but there is no explicit when-to-use/when-not or a named alternative such as replying via parent_comment_id versus posting top-level. Adequate but with a clear routing gap.

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?

Goes well beyond the annotations (readOnly=false, openWorld=false, destructive=false) by disclosing the returned identifiers, the one-hour expiry on upload_url, the required zip layout, the exact upload mechanism, quota behavior, and the embedded-game network/host restrictions. These are exactly the operational traits an agent cannot infer from structured fields.

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

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

Front-loaded with the core action and return contract before the procedural details, and the dense clause chain is mostly load-bearing. It is long for a single-parameter tool, and the wrapper/network-host warnings sit at the tail, but nothing is pure padding.

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 still names what comes back (build_id, upload_url, asset_base) and supplies the full end-to-end procedure and constraints, so an agent can both call it and complete the flow 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 100% and the sole parameter (title_id) is already documented as the live TitleID versus the -DEV copy. The description adds only the framing that the target is a 'Title', so the baseline of 3 applies — the schema does the heavy lifting.

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 (start uploading), resource (a READY web build of the game), and destination (a Title), immediately distinguishing it from finish_build_upload. An agent knows this is the initiation step of a two-phase upload flow without opening the schema.

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

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

Explicitly sequences the follow-up (call finish_build_upload after the PUT) and states a hard prerequisite: 'Needs a shell to run the upload — a browser-only client cannot upload files.' It also warns against uploading a wrapper rather than the game itself. It stops short of enumerating alternative tool choices beyond the successor 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive write. The description adds genuinely useful behavior: the human key is server-assigned (OPUS-451) and returned in the reply, which stops an agent from trying to specify it. It does not cover permissions or reply shape beyond that.

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 terse sentences with the action front-loaded and zero filler. The auto-assigned key detail is a single clause that earns its place because it prevents a common misuse.

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

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

No output schema exists, and the description only notes that the human key is in the reply without describing the rest of the return payload. For a write tool with seven parameters, this is adequate but leaves return-format details to inference.

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 fully documents all seven parameters, including the retry-safe optional card_id. The description adds nothing about parameters themselves, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Add a card to a column'), which is clearer than a tautology. It distinguishes creation from the update/move/delete siblings by name alone, but does not explicitly contrast them in text.

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 create_kanban_column, update_kanban_card, or the bulk workflow. The only implied context is that a card must belong to a column, which the schema already conveys.

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=false, destructiveHint=false, and openWorldHint=false, so the agent knows this is a non-destructive closed-world write. The description adds nothing about whether the operation is idempotent, what happens on name collision, or ordering/position semantics for the new column. With annotations covering the safety profile, a 3 reflects minor added value.

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 no wasted words, appropriately sized for a simple write operation. It is front-loaded with the action and resource.

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 mutation tool with no output schema, the description omits what is returned (new column id?), any positional/ordering behavior, error conditions, or permission requirements. Annotations carry the safety profile, but lifecycle and response details are missing.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema (name, color hex, project_id board). The description adds no syntax, constraints, or default behavior beyond what the schema provides; baseline 3 applies.

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

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

States a clear verb (add) and resource (column to a board), so the action is unambiguous. However, it does not distinguish itself from siblings like update_kanban_column or reorder_kanban_columns beyond the implicit 'create' semantics.

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 guidance, no mention of prerequisites (e.g., project_id must reference an existing board), and no routing to alternatives such as create_kanban_project for initial setup.

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 this is a non-read-only, non-destructive, closed-world write. The description usefully adds the side effect that a default column set is provisioned, which matters for a create operation. It does not mention permissions, whether names must be unique, or what the call returns.

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, zero filler, and the core action is front-loaded before the default-columns side effect. Nothing here is redundant with the 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?

With no output schema, the description could have stated what the create returns - notably the new board id, which downstream tools like create_kanban_column and create_kanban_card need. Otherwise it is adequate for a simple 4-parameter creation 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 100% - name, color, emoji and description are all documented in the schema. The description adds no parameter meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb + resource ("Create a board") that an agent can match to the create_kanban_project name and distinguish from update_kanban_project or create_kanban_card. It does not, however, explicitly contrast itself with sibling creation 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?

"so you can add cards right away" implies the follow-up step (create_kanban_card) and the readiness of the board, giving implied usage. There is no explicit when-to-use/when-not statement and no alternative named (e.g., create vs update a project).

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 idempotentHint=false and openWorldHint=true, but the description adds real context: it consumes a plan slot, fails with TITLE_LIMIT_REACHED plus an upgrade link, requires the 'title:create' permission, and immediately registers both the Title and its '-DEV' copy on this connection. It does not describe the response payload shape in detail, 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?

Purpose is front-loaded in the first clause, and the middle sentences carry operational facts (slot consumption, DEV copy, non-idempotency, error code, permission) that each add value. The tail section re-enumerates base_game options and category that the schema already documents, which is modest duplication.

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 carries the burden of explaining the return: it names the returned TitleID and the paired '-DEV' Title, and states they are added to this connection. Error behavior, permission needs, and the create-once semantics are all covered, leaving nothing an agent needs in order to call 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 100%, so the baseline is 3; the description largely restates what the schema already says about name, idea, base_game (enum and fallback from the idea) and category. It adds only the framing 'give a name and the idea', which is a minor value-add over the structured fields.

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 ('Create a NEW game (Title) on the publisher's account') and elaborates what gets provisioned (base module, starter build, DEV sandbox). An agent can immediately separate it from the many get_/save_/draft_ siblings that never create a Title.

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

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

Explicitly names what to do with the result ('pass the returned TitleID as title_id to get_<section> / save_<section> and the build tools next'), says base_game can come from list_modules, and warns not to retry a successful call. It also excludes a nearby assumption by stating no token is launched here and that needs the dashboard wallet.

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 destructiveHint=true and readOnlyHint=false, but the description goes further by disclosing that the operation is IRREVERSIBLE and that the task key is never reused, plus a required approval step. This is exactly the extra behavioral context annotations cannot convey.

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 compact sentences: the action first, then the critical warnings, then the safer alternative. No filler, and the most decision-relevant facts are front-loaded.

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

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

With no output schema, the description still covers the safety profile, the irreversibility and key-reuse caveats, the approval requirement, and the fallback action. Nothing an agent needs to call this destructive tool responsibly is missing.

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

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

Schema description coverage is 100%, so both parameters (project_id, card_id) are already documented in the schema. The description adds no format, constraint, or identifier details beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Delete a card') and immediately differentiates itself from the alternative (moving the card off the board). It is clear enough to select without opening the schema, though 'card' is slightly generic where the manifest name is 'kanban_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?

Gives an explicit precondition ('ask the publisher before calling this') and names the alternative path plus the condition that selects it ('To take a card off the board without losing it, move it instead'), routing the agent to move_kanban_card. When-to-use and when-not-to-use are both 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 destructiveHint=true and readOnlyHint=false, but the description goes further by disclosing the cascading effect (every card is deleted) and that the operation is irreversible, plus a social/permission constraint (ask the publisher first). These are material behaviors an agent could not derive from the annotations alone.

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 sentences, front-loaded with the catastrophic behavior in capitals, then the alternative path. Every clause earns its place and 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 destructive two-parameter tool with no output schema, the description covers the cascade, irreversibility, precondition, and alternative tool. Nothing an agent needs to call this safely 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% with both parameters documented (column_id, project_id), so the schema already carries full parameter meaning. The description adds no syntax, format, or edge-case detail for either parameter, so the baseline of 3 applies.

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

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

States a specific verb (delete) and resource (kanban column), and immediately distinguishes itself from delete_kanban_card by disclosing that the entire column and every card within it are removed. An agent can tell this apart from sibling deletion tools 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?

Explicitly routes the agent: move cards with move_kanban_card if they should survive, and ask the publisher before proceeding. Both the alternative tool and the precondition for using it are named rather than left to inference.

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 mark this as destructive, but the description goes further by disclosing that the deletion cascades across cards, comments, and attachments and that there is no undo. It also gives a practical safe alternative, adding substantial context beyond the destructiveHint annotation.

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 two tightly packed sentences with no wasted words. The irreversible scope is front-loaded before the safer alternative, which is the right emphasis for a dangerous operation.

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 destructive tool with built-in annotations and no output schema, the description covers the essential risks, recommended prerequisite, and safer alternative. Nothing needed 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 description coverage is 100% and the single parameter 'project_id' is already documented as 'Board to delete.' The description does not add syntax, format, or other meaning beyond what the schema provides, so the baseline of 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 and resource ('Delete a whole board') and immediately scopes the blast radius to every card, comment, and attachment. This clearly distinguishes it from sibling tools like delete_kanban_card or delete_kanban_column.

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 warns that the action is irreversible with no undo, tells the agent to ask the publisher first, and names the preferable alternative ('archive via update_kanban_project(archived=true), which is reversible'). This is exactly the when-to-use / when-not-to-use guidance needed for a destructive operation.

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?

Beyond the annotations, the description discloses the approval workflow, non-publication behavior, scheduling semantics, and content constraints. It also clarifies the permission needed for the separate publishing path. These details materially help an agent understand the behavioral consequences of calling the 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?

The description is front-loaded and appropriately sized for a mutation tool with approval behavior and content rules. Most sentences carry relevant invocation guidance. The note about X charging more for posts with links is somewhat tangential and could be trimmed without losing 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?

Given the rich schema and annotations, the description covers the essential workflow: draft creation, pending approval, scheduling, and publishing alternative. It lacks some context around draft permissions and what the tool returns, but no output schema exists and the approval behavior is clearly explained. The multi-network scope is left mostly to the 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 coverage is 100%, so the parameters are already well documented. The description adds useful text-specific rules such as the 280-character X limit, link counting as 23 characters, no @mentions, and no invented facts. It does not add much to the network parameter beyond the schema, and its X-centric framing may obscure the other supported networks.

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 gives a specific verb and resource: propose/draft an X post for a Title, and it explicitly says the post is not published. It also distinguishes itself from publish_social_post. However, it frames the tool as an X-specific poster even though the schema supports telegram, bluesky, and discord, so the scope is slightly understated.

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 clearly describes the main usage context: creating a draft that lands in the dashboard for approval rather than publishing immediately. It names publish_social_post as the publishing alternative and includes the social:publish permission condition. It does not explicitly distinguish when to use draft_social_reply versus this tool, but the post-vs-reply distinction is reasonably implied by the resource 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?

Adds real behavior beyond the annotations: the draft is non-publishing (awaits approval), it overwrites any earlier unpublished suggestion for the same item, and content is constrained (no links, no @mentions because X adds the author). Those are exactly the side-effect and content rules an agent needs before calling a non-readOnly tool.

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

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

Three short sentences, front-loaded with the action and provenance, then the approval/overwrite behavior, then the content rules. Nothing is repeated from the schema and no sentence is 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?

With no output schema, the description still covers the important post-call state (draft pending approval, prior suggestion replaced) and content constraints. The only gap is what happens on an invalid or already-published item_id, which an agent would want to know.

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 meaning for text (link and @mention prohibition) and for item_id (retrieve it from get_social_inbox). title_id is left as the bare 'TitleID' label, which is the only unexplained input.

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 (propose a reply) and resource (an inbox item), and pins the item_id's provenance to get_social_inbox. The 'waits for approval in the dashboard' clause cleanly separates it from publish_social_reply and from draft_social_post, which targets posts rather than inbox items.

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 tells the agent where item_id comes from (get_social_inbox) and that the result is queued for dashboard approval rather than published immediately, which is the key routing signal versus publish_social_reply. It does not spell out exclusions or failure conditions, so it stops short of a 5.

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 the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so 'Read-only and free' is largely redundant. However, the description adds real behavioral value the annotations do not: the meaning of exact/approximate results, that video and music estimates come from the vendor's own sum, and the critical warning that zero credits does NOT mean free.

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, front-loaded with the purpose and the cost caveats, with no filler. Every clause carries either routing information or a non-obvious interpretation rule for the result.

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

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

There is no output schema, so the description must explain the return semantics — and it does, covering the three possible result states and explicitly warning about the zero-credits trap. Combined with the schema's full parameter coverage, an agent has everything needed to call and interpret 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?

Schema description coverage is 100%, so all five input parameters are already documented in the schema, including the pointer to list_ai_tiers for valid params keys. The description adds no input-parameter semantics beyond what the schema states — the exact/approximate flags it discusses are output-side concepts, not schema inputs. Baseline 3 applies.

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

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

States a specific verb and resource ('Estimate what a generation will cost in credits') and clearly positions itself relative to the generate_* siblings as a pre-flight check rather than an action. An agent can tell immediately this is a cost-query tool, not a generation tool.

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 timing context ('before running it') and reassures the agent it is read-only and free, which lowers the cost of calling it speculatively. It stops short of naming a specific alternative or an explicit when-not-to-use condition, so it is strong context without full alternative routing.

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 destructiveHint=true and openWorldHint=true, so the bar is lower, yet the description adds substantial context: ~100 s wait window, version appearing in dashboard history, returned TestUrl, and idempotency on repeat calls. It does not explicitly state what the deploy path overwrites or what happens to the currently live version, so the destructiveHint is not fully elaborated.

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?

Five dense sentences, each carrying distinct information (purpose, wait behavior, result, deploy effect, polling, idempotency) with the core action front-loaded. No filler or restated field text.

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

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

For a mutation tool with no output schema, the description compensates by describing the returned version and its TestUrl, the timeout, the polling path, and the deploy side effect. Combined with the annotations, an agent has everything needed to call and follow up 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 coverage is 100%, so the baseline is 3. The description reinforces deploy semantics and the build_id/idempotency relationship, but adds little syntax or format detail beyond what the schema already documents for label, deploy, build_id, and title_id.

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?

Starts with a precise verb+resource ('Finish an upload started with begin_build_upload') and immediately differentiates itself from the sibling it builds on. An agent can tell it apart from begin_build_upload and get_build without opening any schema.

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

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

Explicitly names the prerequisite tool (begin_build_upload), the fallback when the operation is still running (poll get_build), and the two modes selected by deploy. The when-to-use-as-test vs when-to-go-live distinction is spelled out, and the idempotent retry case is called 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?

Adds substantial context beyond the annotations: it costs one generation of the publisher's credits (text for heroes, image or music for the rest), takes ~2 minutes before a retry is warranted, that a retry with generation_id is free, and that the asset is appended to package.assets and occupies the given slot. Those side effects and cost/auth facts are not derivable from readOnlyHint=false / openWorldHint=true.

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 is front-loaded and nearly every clause carries information (cost, retry, slot mechanics, validation hand-off). It is dense and semicolon-chained rather than structured, which costs some scannability, but no sentence is 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 10-parameter, nested-object, no-output-schema tool, it covers the return shape (updated package and its link), cost, timing/retry, and pre-publish validation. Remaining gaps are failure modes (what happens if generation fails outright) and the meaning of tier/base_set, which the schema only gestures 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?

Schema coverage is 100%, so the baseline is 3; the description still adds meaning, explaining slot syntax (cast[0], set, music), what `package` is and where it comes from, and elaborating each kind beyond the schema's terse enum string. It does not explain `tier`, `base_set`, or `style` beyond what the schema already says.

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 (generate an asset for a video) and enumerates the six asset kinds with a parenthetical gloss for each (voxel hero CharacterSpec recipe, rig recipe, cut-out, prop, scene, loop). It also distinguishes itself from the generic generators by tying output to the studio's asset format and the `package` from plan_video.

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 context: run after plan_video, pass the plan item's slot, retry with the same kind + generation_id after ~2 minutes, and check hero recipes with validate_asset before publishing. It also points at estimate_media_cost for budgeting. It never explicitly excludes sibling generators like generate_image/generate_music/generate_text, which would have made this a 5.

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?

Adds rich behavior beyond the annotations: 'Billed per character' discloses cost, and the async job contract (waits ~2 minutes, otherwise returns status queued/running, then poll get_generation) is exactly what an agent needs to invoke it correctly. Annotations only mark it as a non-destructive open-world write, so the description carries and delivers the real behavioral load.

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 tightly packed sentences, front-loaded with purpose, then billing, then the async contract. Every clause earns its place 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 6-param mutation tool with no output schema, the description covers cost, async lifecycle, and the polling path well. It does not say what the successful result actually contains (e.g., an audio URL/asset), leaving the agent to infer the artifact from get_generation.

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 meaning by explaining the tier/model/params interaction — the voice comes from the tier's model unless passed in params — which clarifies how params and tier relate in practice. It stops short of explaining params keys or provider precedence beyond what the schema already documents.

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

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

States a specific verb and resource — 'Generate speech (text-to-speech) for the title' — which distinguishes it reasonably from generate_music/generate_image/generate_video siblings. The title mentions 'or sound' but the description narrows to speech only, leaving a small mismatch with the advertised scope.

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 operational context: when the call returns synchronously versus when to 'poll get_generation with its id', and how the voice is chosen (tier's model unless overridden in params). It does not state when to prefer this over generate_music for non-speech audio, so sibling routing is only 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?

Annotations only declare the safety profile (openWorld, non-destructive, not read-only), while the description adds genuinely operational detail: the call blocks for about two minutes, may return an unfinished generation with status queued/running, and the successful result carries a CDN URL in Assets. That is exactly the behavioral context the annotations cannot supply.

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 tight sentences in a logical order: what it makes, where the artifact lands, then the job/blocking semantics and fallback. No filler or redundant restatement of the name.

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 correctly compensates by describing the return shape (generation record with status, CDN URL in Assets) and the timeout/polling contract. Combined with a fully documented input schema, an agent has everything needed to call it and handle the async case.

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 parameter docs are unusually rich (tier vs model/provider cancellation warnings, vendor-declared params, unknown keys ignored), so the schema carries the load. The description says nothing about tier, model, params, or provider, adding no meaning beyond the schema — baseline 3 applies.

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

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

States a specific verb and resource ('Generate an image') and narrows the domain with examples ('icon, sprite, art') for a title, which distinguishes it from the adjacent generate_video/generate_music/generate_audio/generate_text/generate_three_d siblings. It also names get_generation as the polling counterpart, so the agent can place the tool precisely.

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 usage context: the output is meant to be referenced from title config or code via the CDN URL in Assets, and it states the alternative path when the job isn't finished (poll get_generation with the id). It does not state when to prefer a different generation tool instead, but the surrounding guidance is strong.

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 only declare it is a non-destructive, open-world write. The description adds the operationally critical detail that this runs as a job: the call blocks for about two minutes, may return queued/running instead of a result, and in that case the agent must poll get_generation with its id. That is exactly the behavior an agent cannot infer from annotations.

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 tight sentences: purpose first, sibling/cost differentiation second, async mechanics third. Nothing is padding and the most important constraint (job may not finish) is not buried.

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 6-parameter, nested-schema generation tool with no output schema, the description covers the async lifecycle, the polling fallback, and the cost/vendor distinction from the nearest sibling. Combined with the fully documented schema, an agent has everything needed to call and follow up 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 100%, so the schema already documents tier, model, params, provider and title_id, including the nested params object and the tier-cancelling warnings. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Generate music (a loop or a short track)') and immediately scopes the output type. It also names and rules out the nearest sibling by explaining that generate_audio is speech, so an agent can route 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?

Explicitly distinguishes this tool from generate_audio on both vendor path and price, which is real routing guidance. It does not state when-not to use it (e.g. for voiceover or longer tracks), so it stops short of a full when/alternatives rule set.

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 only the safety profile (readOnlyHint=false, openWorldHint=true, destructiveHint=false). The description goes well beyond them: it discloses asynchronous job semantics, an approximate two-minute wait budget, the degraded response shape (queued/running with an id), the required polling follow-up, and who pays the credits. That is exactly the behavioral context the annotations do not carry.

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

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

Front-loaded with purpose, then job semantics, then the polling fallback and the credit/label note. Every sentence carries new operational information and none is padding, despite the dense em-dash phrasing.

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

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

There is no output schema, so the description must explain return values and it does: either the generated text or a generation object with queued/running status plus an id. Combined with the wait window and polling instruction, an agent has everything needed to invoke and follow through 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 100%, so the schema already documents all seven parameters, making a 3 the baseline. The description's only parameter-level addition is restating that title_id is an optional report label and that credits belong to the publisher, which largely duplicates the title_id schema text and says nothing about prompt, model, provider, max_tokens, temperature, or system_instructions.

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

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

States a specific verb and resource (generate text via AI) and immediately scopes it with concrete artifact types (copy, item descriptions, dialogue), which cleanly separates it from the generate_image/audio/video/music/three_d siblings. An agent can pick this tool without opening the schema.

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

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

Explicitly describes the invocation contract: the call blocks up to about two minutes, and if not ready it returns a queued/running generation whose id should be polled via get_generation. That names the follow-up sibling and the condition that selects it. It gives no guidance on when to prefer a different generation tool, but the resource 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 only declare readOnly=false, destructive=false and openWorld=true; they say nothing about execution model. The description adds the crucial fact that this is asynchronous and returns a job id/status that must be polled via get_three_d — behavior not inferable from the annotations or schema.

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, zero padding: the capability comes first, the critical async/polling constraint second. Every clause earns its place and the most actionable fact (async + poll) is front-loaded in the flow.

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 10-parameter, nested-object, mutating generation tool with no output schema, the description covers the two things the schema cannot: the async job contract and the retrieval path. What remains thin is operation-specific dependency guidance (text-to-3d vs image-to-3d vs remesh/rig inputs), which is only implicitly covered by the 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 100% and the schema is unusually rich (tier, model cancellation warning, params semantics, per-operation URLs), so the description rightly defers to it. It adds nothing beyond the schema for the 10 parameters, which is acceptable given full coverage but earns no extra credit.

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

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

States a specific verb and resource (generate a 3D asset/mesh) and names the companion tool get_three_d for retrieving the result, which lets an agent separate it from that poller. It does not, however, differentiate itself from the other generate_* siblings (generate_image, generate_video, generate_audio), so the agent gets no help on 3D vs 2D 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 gives a strong post-invocation workflow ('returns a job with an id and status — poll get_three_d'), which is real routing guidance. But it offers no when-to-use guidance relative to the other generation tools, and no when-not-to-use or prerequisite conditions (e.g. when image_url or input_task_id is required per operation).

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 only cover the safety profile (readOnly=false, destructive=false, openWorld=true), so the async contract is genuine added value: the tool returns a job with an id and status, and completion requires polling get_video. The billing caveat (duration drives cost, minimum-length charges possible) is a non-obvious operational trait worth disclosing.

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 action first, then cost, then async contract. No filler, though the cost sentence is slightly dense with two distinct ideas (duration driver plus minimum billing).

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 characterizes the return value ('a job with an id and status') and names the follow-up tool, which is the key gap an agent would otherwise hit. The 6-parameter, nested-params surface is well covered by the schema itself.

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 tier, model, params, provider and title_id in detail, including the tier-cancellation warning. The description only adds the connection that duration (a params key) is the cost driver; that is marginal above the baseline of 3.

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 verb and resource ('Generate a video clip') and implicitly disambiguates from generate_image, generate_audio and generate_text by naming the media type. It does not explicitly contrast with the closest sibling remix_video, so it falls short of full sibling differentiation.

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 real usage context: estimate cost first, and poll get_video for the result after the async call. However it never names estimate_media_cost (the actual sibling) nor states when to prefer a different generation tool or when not to use this one, leaving routing partly to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: that shared secrets (SSV keys, report keys) are NOT stored here and only the TitleSecrets entry name is returned, which prevents an agent from expecting credential material in the response.

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 read-scope constraint is front-loaded in the first clause. The long enumeration of sub-features is verbose but largely earns its place by scoping what 'Advertising' means; the two-sentence structure is coherent, though the list is denser than strictly 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 read-only single-param tool with no output schema, the description does enough — it defines the field's domain and the secrets caveat. It stops short of describing the return shape or noting any auth/permission needs, which 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?

With a single parameter and 100% schema description coverage (title_id fully documented in the schema), the schema carries the parameter semantics. The description adds nothing about title_id, so baseline 3 applies.

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

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

States a specific verb and resource ('GET ONLY the Advertising field of TitlePublicConfigurationModel') and enumerates exactly what that field contains. An agent can immediately tell this apart from save_advertising or get_title_data.

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 'GET ONLY' phrasing and contrast with the write-path sibling save_advertising imply this is the read-side tool, but there is no explicit statement of when to use it versus alternatives like get_title_data (which may or may not also expose advertising). Usage is implied rather than 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=true and destructiveHint=false, but the description adds real context: the section is server-only and 'never sent to the game client or the CDN', generation is charged to the publisher's credits, and spend caps live in the private config, not here. That goes well beyond what the annotations provide.

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 purpose is front-loaded in the first clause, but the remainder is a single sprawling sentence with dense nested parentheses covering modes, tiers, pricing, gates, schedules and limits. Much is necessary detail given no output schema, but the structure is hard to parse.

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 carries the burden of explaining the returned structure and largely does so: Enabled as master switch, Features keyed by FeatureKey, Modality, Model, Behavior, Safety, Gate, Schedule, Limits and PriceOptions. Minor gaps remain (no pagination/format notes), but it is substantially complete for a read 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 100%, so the single title_id parameter is already documented, and the description adds no syntax, format, or constraint detail beyond it. Baseline 3 is appropriate when the schema does the work.

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: 'GET ONLY the AI field of TitlePublicConfigurationModel', and clarifies it is the in-app AI generation configuration. This distinguishes it from the broader save_ai and get_title_data siblings, though it never names an alternative 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?

There is no 'use this when/when not' guidance, nor any routing to siblings such as save_ai (write) or list_ai_tiers (enumeration) despite them being obvious alternatives. Usage is only implied by the verb 'GET'.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds context about defaults, plan caps, reserved event-name prefixes and retention behavior, but discloses nothing about permissions, response envelope, or limits of the call itself.

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 dense wall of text enumerating every sub-field of the configuration with no headings or front-loading of the essential action. Only the opening clause is actionable; the bulk is model reference that is hard 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 effectively documents the returned configuration (Events, Dimensions, RetentionDays, EventNaming, AutomaticEvents, defaults and caps), which compensates for the missing return-value schema. It omits the response shape/envelope, but is otherwise thorough for a one-parameter read 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% with a single required title_id parameter, so the schema already carries parameter documentation and the description adds nothing about it. Baseline 3 applies when the schema does the heavy lifting.

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 first sentence states a specific verb and resource: 'GET ONLY the Analytics field of TitlePublicConfigurationModel', which implicitly distinguishes it from other field getters and the write counterpart save_analytics. The purpose is unambiguous, though much of the remaining text describes the field's contents rather than the 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?

There is no explicit when-to-use guidance and no named alternative. The read-only intent is only implied by 'GET ONLY', and the description never says to use save_analytics to change these settings, nor when in a workflow this call is 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: the result is scoped to a single field of TitlePublicConfigurationModel and is a slug→URL dictionary covering Unity AssetBundles/Addressables manifests. No auth or error behavior is described, but the bar is lower given annotations.

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

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

Front-loaded with the scope constraint ('GET ONLY the AssetBundle field'), then the return shape, then the sibling routing rule. Every sentence carries information; no filler or restatement of the title.

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

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

With no output schema, the description compensates by explaining the returned dictionary's key/value semantics and the domain of URLs it contains, plus where to go for the adjacent image case. For a single-parameter read tool this is complete enough to call 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?

There is only one parameter and schema description coverage is 100% (the schema documents title_id as the TitleID to read data for). The description adds no further parameter detail, so the schema carries the burden — the baseline of 3 for high coverage applies.

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

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

States a specific verb and resource ('GET ONLY the AssetBundle field') and describes exactly what the value shape is (dictionary of bundle slug → CDN URL). It explicitly routes to a sibling ('for images alone use ImageData'), so an agent can separate it from get_image_data without reading either schema.

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

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

Gives a concrete selection rule: use this for binary game content, use ImageData for images alone. That is a real when-to-use/when-to-use-something-else statement. It stops short of exclusions or prerequisites (e.g., title must be the caller's own title), so not a full 5.

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, destructiveHint=false and openWorldHint=false, so the safe-read profile is covered. The description adds real scoping behavior ('GET ONLY the Attribution field') and rich domain context about touch-point chains, but discloses no operational traits such as auth requirements, pagination, or what the response concretely 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?

The action is properly front-loaded in the first sentence, but roughly four sentences of domain exposition follow for what is a single-field read. The content is informative yet disproportionate to the operational payload, so it reads as an essay rather than a tightly scoped tool definition.

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, closed-world read with no output schema, the description does the heavy lifting by explaining what the returned Attribution settings control (touch counts, dedup window, aliases, referral channel). It omits the mechanical return shape, but the semantic coverage of the returned field is strong enough that an agent can reason about the result.

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 single title_id parameter is documented in the schema, so the baseline is 3. The description adds no format, default, or constraint detail for title_id, though its discussion of what the Attribution section configures gives indirect context for the title being read.

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 opening clause gives a specific verb and resource: 'GET ONLY the Attribution field of TitlePublicConfigurationModel', which pins the scope to a single config section rather than the whole title document. That scope note also implicitly distinguishes it from the paired get_title_data / save_attribution siblings, though it never names an alternative 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?

Usage is only implied: an agent can infer 'call this to read attribution settings', and the 'GET ONLY' phrasing suggests it is the read counterpart to save_attribution. There is no explicit when-to-use, when-not, or named alternative, so guidance stays at the minimum-viable level.

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, destructiveHint=false, openWorldHint=false. The description adds substantial beyond that: it explicitly reassures there are NO secrets, explains why (OAuth client IDs are public by protocol design, no flow uses a client secret), and describes the audience-per-platform behavior. Strong added context for a read-only 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?

The scope is front-loaded ('GET ONLY the Authentication field...'), followed by dense but relevant detail on contents, secrets, and platform audiences. Every sentence carries information, though the platform-audience sentence is somewhat elaborate for a description.

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

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

No output schema exists, so the description carries the burden of explaining the return value, and it does so thoroughly (field contents, public client IDs, per-platform audience). It is nearly complete, missing only an explicit statement of what to do when the section is empty or how the caller should consume multiple filled IDs.

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?

Only one parameter (title_id) with full schema description coverage, so the schema already documents it. The description adds no syntax or format guidance for title_id and focuses entirely on return content. 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 and resource: it reads ONLY the 'Authentication' field of TitlePublicConfigurationModel, and it names the content (third-party sign-in methods, OAuth client IDs). An agent can tell exactly what is returned. However it does not explicitly name its write counterpart save_authentication or get_title_data, so sibling differentiation is only implicit.

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

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

Usage is implied by the scope description rather than stated. It notes that device/e-mail/Telegram/SSO logins need no configuration so are absent, which lightly signals when this endpoint is relevant, but there is no explicit when-to-use/when-not or reference to the save_authentication alternative.

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/destructive/openWorld, so the safety profile is covered. The description goes well beyond them, disclosing the domain semantics: BanCapability checkboxes, the BlockLogin override behavior, DefaultLevelID meaning, and two built-in ids ('hard', 'soft') that exist even when unlisted. Missing only return-format/pagination behavior, which is minor 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?

The core action is front-loaded in the first clause, which is good, but the remainder is a dense single paragraph cataloguing capabilities and flags that reads more like model documentation than invocation guidance. It is relevant but over-long and hard 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?

For a one-parameter read tool with no output schema and annotations covering safety, the description supplies enough domain context (level structure, built-in ids, override semantics) for an agent to interpret the result correctly. Nothing essential about calling it is missing.

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

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

Schema description coverage is 100% for the single title_id parameter, so the schema already defines it. The description adds no syntax, format, or sourcing detail about title_id, so the 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 and resource and narrows scope sharply: 'GET ONLY the "Ban" field of TitlePublicConfigurationModel.' It also distinguishes itself from the mutation sibling by naming the player-facing tool (SetPlayerBanStatus) that should be used instead. An agent can separate this from save_ban and get_title_data without opening any schema.

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

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

Explicitly says this section 'only defines what each level MEANS' and directs the agent to player-facing tools to actually ban someone, which is genuine when-to-use/when-not-to-use routing. It stops short of contrasting with the broader get_title_data sibling, so the guidance is strong but not exhaustive.

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, openWorldHint=false and destructiveHint=false, so safety and scope are covered structurally. The description adds the useful scoping fact that only one field is returned and explains where that field is derived from, but says nothing about auth requirements, error behavior, or fallback when the field is unset.

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 clauses, with the scoping constraint ('GET ONLY') front-loaded and the payload contents immediately after. It is dense with domain jargon and the lineage sentence is somewhat redundant, but there is 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?

With no output schema, the description correctly carries the burden of describing the returned payload and does so concretely. It is close to complete for a simple read tool; only the unset/empty case and any title-permission requirement are unaddressed.

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

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

There is a single parameter (title_id) and schema description coverage is 100%, so the schema fully documents it. The description adds no format, validation, or lookup semantics beyond what the schema already states, which is the expected baseline for a one-param 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?

States a specific verb and resource ('GET ONLY the Blockchain field of TitlePublicConfigurationModel') and enumerates exactly what that field contains (chain selectors, contract addresses, RPC overrides, gas policy, supported networks). It also distinguishes itself from the sibling get_currency by naming the data lineage (Currency.CryptoCurrencies[].Networks) and calling itself the title-level companion config.

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?

'GET ONLY' clearly frames this as a scoped read against the title config, and the lineage note tells the agent how it relates to get_currency. It stops short of an explicit when-to-use-this-vs-alternative rule (e.g. 'use get_currency for per-currency network data'), so it is clear context without exclusions.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations by explaining the status enum values (Queued, Building, Staged = ready to deploy, Live, Failed) and noting that it returns errors and links, which helps an agent interpret results during polling.

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 sentences with zero waste. The return-value details are front-loaded, followed immediately by the usage hint, and 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 output schema, the description carries the burden of explaining return values, and it does so adequately by listing status, errors, and links. It could be more complete by mentioning error handling or authentication requirements, but for a read-only polling tool with annotations covering safety, it is largely sufficient.

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 both parameters (build_id and title_id) are already documented in the schema. The description adds no additional meaning or format details for these parameters, making the baseline 3 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 states a specific resource and scope: 'State of one version of the Title's game', and enumerates what is returned (status, errors, test and live links). It distinguishes itself from list_builds by focusing on a single version, but does not explicitly name list_builds or other alternatives to contrast with.

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 clear usage context: 'Use it to poll finish_build_upload', which tells the agent exactly when this tool is appropriate. However, it provides no when-not guidance or explicit alternatives (e.g., use list_builds to enumerate builds).

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful scope-narrowing behavior ('GET ONLY the Character field', not the whole title config), but says nothing about error behavior or what the returned Character payload looks like for this specific call.

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 purpose is correctly front-loaded in the first sentence, but the trailing block about skins being non-stackable Items and being granted by stores/lootboxes/quests describes item and skin configuration, not reading Character data — substantial text that does not earn its place for a getter.

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-only tool with full schema coverage and annotations, the description is more than sufficient and the scope-narrowing clause removes real ambiguity about what is returned. The off-topic skin-granting detail is surplus rather than a missing piece.

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?

Only one parameter (title_id) and schema description coverage is 100%, so the schema already documents it fully. The description adds no format, default, or lookup semantics beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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 ('GET ONLY the Character field of TitlePublicConfigurationModel') and immediately enumerates the domain content (playable units, NPCs, summons, stats, abilities, evolution paths). It also distinguishes the resource from the sibling concept Item, so an agent can tell Character apart from Item data without opening a schema.

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

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

Usage is only implied — the agent can infer this is the read counterpart to save_character, and the 'create that item first' note hints at a skin workflow. But there is no explicit statement of when to call get_character versus get_title_data or get_item, and no exclusions or prerequisites for this tool itself.

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 readOnlyHint/destructiveHint/openWorldHint already covering the safety profile, the description adds real behavioral context: channels are server-partitioned (language validated against Localization locales, country from IP) so rooms are config-bounded, and Group channels are hidden because no external GroupSource provider exists. It does not discuss pagination or auth, but the added domain behavior is substantial.

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 critical scoping constraint is front-loaded in sentence one, but the remainder is a dense block of domain theory (SegmentGate, LimitSpec, Retention.HistoryHours, Redis) that is only partly needed to select or invoke a one-parameter getter. It is information-rich but not tightly edited.

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

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

There is no output schema, so the description must convey what comes back, and it does: channels (world/announcement/group), direct-message settings, moderation rules, polling economics. It also states what is explicitly absent (messages). It could be clearer on the returned shape, but it compensates well for the missing 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 coverage is 100% for the single title_id parameter, so the schema already carries the full burden. The description never mentions title_id or adds syntax meaning, 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?

The opening sentence gives a precise verb and resource: 'GET ONLY the Chat field of TitlePublicConfigurationModel', immediately distinguishing it from the many other get_* config siblings. The scope is unambiguous (config only, not messages), so an agent can route to it without opening the schema.

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

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

It gives strong negative scoping: messages 'live in the ChatMessages collection', and 'Muting a player and reviewing reports are admin actions, not config', which steers the agent away from expecting those here. It stops short of explicitly naming a sibling (e.g. save_chat as the write counterpart), so it lacks full alternatives routing.

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 establish readOnly/non-destructive/non-openWorld, so the safety profile is covered. The description goes beyond that by enumerating what the section contains — active JS revision, engine limits, rate limits, per-handler metadata, client log/stack-trace exposure — and notes the significance of scripts for writing protected player 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?

Front-loaded with the exact scope constraint ('GET ONLY...'), then context. The scripting explanation is long but informative rather than repetitive; only the closing 'prefer dedicated tools' sentence drifts from the read-only purpose.

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 describes the shape of the returned data (revision plus execution policy and limits), which is what an agent needs to interpret results. It stops short of mentioning permissions or error behavior, but is otherwise complete for a single-parameter getter.

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?

Only one parameter (title_id) with 100% schema description coverage, so the schema fully documents it. The description adds no format, sourcing, or validation detail for title_id, making the baseline 3 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 precise verb and scope: 'GET ONLY the CloudCode field of TitlePublicConfigurationModel', which cleanly separates it from save_cloud_code and publish_cloud_code. The agent knows exactly which slice of title configuration this returns.

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 read-only usage and warns to 'prefer the dedicated cloud-code tools over editing this section by hand', but that guidance addresses editing rather than when to call this getter versus alternatives like get_title_data. No explicit when-to-use or when-not-to-use conditions are given for the read path.

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 the safety profile (readOnlyHint, destructiveHint=false, openWorldHint=false), so the description only needs to add surrounding context. 'GET ONLY the ... field' usefully discloses that the response is a narrow, single-field slice rather than the whole configuration model, which is real value beyond the annotations, though return shape and error behavior are not addressed.

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

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

Front-loaded with the key scope constraint ('GET ONLY...') followed by a compact definition of the domain. Four short fragments, no repetition, though the domain gloss is slightly padded.

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-only getter with no output schema and full annotation coverage, the description supplies the domain meaning (what fields and concepts the Collection covers) so the agent knows what it is fetching. It stops short of describing the returned structure, which is the only notable 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 coverage is 100% for the single title_id parameter, so the schema carries the documentation burden. The description adds nothing about title_id (syntax, source, required-ness) beyond what the schema states, so baseline 3 applies.

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

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

States a precise verb and resource ('GET ONLY the Collection field of TitlePublicConfigurationModel') and then defines what the Collection domain contains (sets of items/cards/characters/achievements, completion rewards, tier/rarity grouping). This scoping is specific enough to separate it from the many other get_* config-domain siblings without naming 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?

'Use for compendium-style meta content' implies the context of use but gives no when-not conditions and names no alternative (e.g. get_item, get_reward, get_data_collections). Adequate but leaves the agent to infer when this is preferable.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds substantial beyond-annotation context: secrets are addressed by name and never surfaced as values, spend caps are evaluated against what has been PAID rather than earned, and anti-fraud hold/maturity semantics. It omits error/empty-campaign behavior, so it falls short of 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?

The key operation is correctly front-loaded in the first clause, but the rest is an oversized data-model essay covering schedules, rate cards, milestones, budgets, providers, moderation and anti-fraud that an agent does not need in order to select or invoke a single-parameter getter. Much of this belongs in the returned model's documentation, not the tool description, so it is over-specified rather than concise.

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 with no output schema, the description compensates thoroughly by explaining what the field contains and, importantly, what it does NOT contain. It is complete enough for correct invocation; the only minor gap is any hint about behavior when no campaign is configured.

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 is a single parameter (title_id) with 100% schema description coverage, so the schema already carries the semantics. The description adds no syntax or format detail about title_id, so the baseline 3 for fully-covered schemas applies.

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

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

The opening states a specific verb+resource+scope: 'GET ONLY the CommunityMarketing field of TitlePublicConfigurationModel,' and it clarifies what Community Marketing is (creator reward program). It distinguishes itself from siblings by asserting that operational data (creators, submissions, accruals) lives in other collections, so an agent can tell it apart from save_community_marketing and the operational getters without opening the schema.

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

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

It clearly frames the read-only config-retrieval context and explicitly excludes related-but-separate data (creators, submissions, journal) and the funding source (Currency section). However, it never names an alternative tool (e.g., save_community_marketing for writes), so the routing guidance is implied rather than explicit, which keeps it out of the top band.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description reinforces the scope ('GET ONLY' a single field) and characterizes the domain content, but adds nothing about auth/permission requirements or what happens if the field is unset. Adequate, not rich.

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 scoping constraint is front-loaded in the first clause, and the remaining sentences are compact. The middle domain-detail sentence ('Defines participation rules, shared progress...') leans slightly toward flavor over instruction, but it is not wasted space.

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 must convey what comes back; it sketches the returned configuration (participation rules, shared progress, contribution tracking, tiered rewards) rather than leaving the return opaque. It does not describe the field's structure or shape, which is the remaining gap for a read 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 100% for the single title_id parameter, so the schema already carries the semantics. The description adds no format, source, or validation detail beyond what the schema provides; baseline 3 applies.

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

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

States a precise verb and resource ('GET ONLY the CoopEvent field of TitlePublicConfigurationModel') and explicitly contrasts itself with TimedEvent (solo) and Leaderboard (pure ranking), which are actual siblings in the tool list. An agent can select this tool without opening any schema.

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

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

Gives clear context for when this tool is the right one ('guild raids, server-wide goals, leaderboard tournaments where players contribute together') and names the two adjacent concepts it is not. It stops short of an explicit directive like 'use get_timed_event for solo events', but the differentiation 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 already declare readOnlyHint/destructiveHint/openWorldHint, so the safety profile is covered. The description adds real context beyond that: it scopes the read to a single field of a larger model rather than the whole title config, and explains that item IDs resolve against the Item catalogue and costs against Currency — useful cross-reference behavior an agent would otherwise have to infer.

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 sentences, no filler, and the read-only scope is front-loaded before the content enumeration. Slightly dense in the second sentence's list of sub-fields, but every clause carries 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?

With no output schema, the description usefully explains what the returned Craft field contains and how its identifiers relate to other catalogues — exactly the gap an output schema would normally fill. An agent has enough to call it and interpret the result.

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?

Only one parameter and schema coverage is 100%, so the schema fully documents title_id (including its Russian description). The description adds no syntax or constraint detail for the parameter, which is fine given the schema does the work; the baseline for a well-documented single param is a 4.

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 ('GET ONLY') plus the exact resource ('the Craft field of TitlePublicConfigurationModel') and enumerates its contents (inputs, output item, success rate, time cost, station/skill prerequisites). This clearly separates it from sibling getters like get_item and get_currency, which the description explicitly names as related catalogues.

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?

'GET ONLY' implies a read and hints that the corresponding writer is save_craft, but no alternative is named and no when/when-not condition is stated. Usage is implied rather than prescribed.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable context: the 'Main' CryptoCurrency entry is protected and cannot be overwritten, with changes silently ignored. However, this is about write behavior for a read-only tool, which is slightly tangential, and no return format or pagination is described. The protected-key note is useful but doesn't fully compensate for a read tool's behavioral gaps.

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 information-dense but front-loaded with the key scoping statement. However, it includes a lengthy explanation of the Currency catalogue and its references that, while informative, is somewhat verbose for a simple getter. Every sentence earns some place, but the note about protected 'Main' entry is more relevant to save_currency.

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

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

Given the tool's complexity (1 param, no output schema, rich annotations), the description provides substantial context about what Currency contains and how it relates to other systems. It is nearly complete, though it could clarify that this returns a configuration object without a 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 100%, so the schema fully documents the single title_id parameter. The description doesn't add parameter-specific syntax or format details. With 0 params needing explanation beyond the schema, baseline 4 applies per the rule for 0 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?

States a specific verb+resource: GET only the 'Currency' field of TitlePublicConfigurationModel. This is highly specific and distinguishes it from siblings like get_item or get_store, which are separate configuration domains.

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 usage by explaining what the Currency catalogue is and that CurrencyID is referenced by Item prices, Store SKUs, and other systems, giving context for why an agent would call it. However, it doesn't explicitly state when to use this versus alternatives like save_currency or get_item, leaving usage inferred 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 readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: it is a settings-only read ('Records themselves are NOT here - they live in the engine's DataCollection* collections'), points to the server API for records, and notes that collection/searchable-field/sort-key/storage counts are plan-capped.

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 tool's own behavior is dispatched in one front-loaded sentence, but the body then runs to several hundred words of data-model design guidance (module selection, Economy/Ref rules, per-field options, quest/analytics integrations) that is tangential to invoking a getter. Much of it documents the returned field's shape, but the design-policy passages do not earn their place for a read call.

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 carries the burden of explaining what the returned DataCollections field contains, and it does so exhaustively (Kind, Mode, Fields, SortKeys, Access, Limits, Counters, Integrations, PublicViews, AnonymousSearch, Roles). An agent can interpret the response without any further documentation.

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 is a single parameter with 100% schema description coverage, so the schema fully documents title_id. The description adds no format or sourcing detail for the parameter; baseline 3 applies when the schema does the heavy lifting.

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 opening states a precise verb+resource+scope: 'GET ONLY the DataCollections field of TitlePublicConfigurationModel.' This immediately separates it from get_title_data (whole config), save_data_collections (the write counterpart), and get_collection/get_item, so an agent can distinguish it without opening a schema.

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

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

It establishes the read context and heavily guides the domain decision of whether a data collection should exist at all ('USE A READY PLATFORM MODULE FIRST... declare a collection only for what no module provides'). It does not explicitly name a sibling read alternative (e.g., get_title_data for the full model) or state exclusions for calling this getter, so it stops short of full when/when-not guidance.

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

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

Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description reinforces this with "GET ONLY" and clarifies the scope is a single field rather than the whole config, but adds no auth, rate-limit, or fetch-behavior 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?

The actual tool behavior occupies one clause; the remaining hundreds of words are an unstructured, single-block encyclopedic treatise on slots, nodes, pricing, milestones, and presets. No paragraphs or headings break it up, so the operative instructions are hard to locate.

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 deep description of what DealOffer contains (Slot/Offer/Node decomposition, PriceOptions, Reward.Grants, presets) is the only way an agent learns the return shape, which is genuinely valuable here. It still omits the response envelope and the fact that title_id resolution may fail.

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% for the single title_id parameter, so the schema already carries the semantics and baseline 3 applies. The description adds nothing about how title_id is sourced or scoped.

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?

Opening clause gives a specific verb+resource: "GET ONLY the 'DealOffer' field of TitlePublicConfigurationModel," and the closing sentence explicitly contrasts it with Store (always-on shop, no progression) and Premium (subscriptions). Purpose is identifiable, though the verb is buried under a dense domain-model lecture rather than front-loaded.

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 Store/Premium contrast implies when DealOffer is the right target, and "GET ONLY" implies read-only retrieval. But there is no explicit when-to-use statement, no prerequisite about needing a title context first, and no guidance on the obvious read-vs-write pairing with save_deal_offer.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds meaningful domain behavior beyond that: weighted variant allocation, stable-hash assignment, SegmentGate audience gating, ScheduleSpec scheduling, and inline Params overrides. Return-format specifics are still absent, but the semantic content is rich.

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 scoping constraint ('GET ONLY the Experiment field') is front-loaded, followed by a compact description of the field's contents. Dense but each clause carries domain information; only minor trimming would help.

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 read with no output schema, the description compensates by explaining what the Experiment payload contains (variants, gates, schedule, overrides). Combined with annotations covering the safety profile, an agent has enough 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 coverage is 100% with a single documented title_id parameter, so the schema carries the parameter semantics. The description adds nothing about the parameter's format or constraints, making the baseline 3 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 and resource: 'GET ONLY the Experiment field of TitlePublicConfigurationModel', which precisely scopes the read and implicitly distinguishes it from a whole-model fetch. It does not name the sibling (e.g., get_title_data) that returns the full model, so differentiation is inferred rather than explicit.

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 use-case ('Used to test config changes against measurable cohorts') which implies when the data matters, but offers no explicit when-to-use routing versus get_title_data or save_experiment, and no exclusions or prerequisites.

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, destructiveHint=false and openWorldHint=false, and the description goes well beyond them: it discloses the 40-entry cap, the fact that each tracked id becomes a key in the player document read on every request, and that no historical data exists because tracking only begins when an action is added. Those are real operational constraints an agent could not infer.

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

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

It is front-loaded with the scoping statement, and the remaining sentences carry domain meaning rather than filler. It is dense, but with no output schema the explanation of entry format and limits is substantive, not 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?

With no output schema, describing what the field contains (entry format like 'Character:EquipItems', the cap, the funnel use case) is exactly what the description should do, and annotations cover safety. Minor remaining gaps are the response wrapper and title_id semantics, but nothing blocking correct invocation 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?

There is a single required parameter and schema description coverage is 100%, so the schema fully documents title_id. The description adds nothing about the parameter, which matches the baseline 3 when the schema does the heavy lifting.

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 verb and resource and narrows scope precisely: 'GET ONLY the FeatureTracking field of TitlePublicConfigurationModel.' An agent immediately understands this is a read of one settings field, and the get/save naming pair with the save_feature_tracking sibling makes the distinction obvious.

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

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

Usage is only implied by the read-only nature of the operation. The description never states when to call this versus save_feature_tracking, or that it is the read counterpart to the write tool, nor any prerequisite such as needing a valid title_id. It provides domain context but not selection guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds non-obvious context the annotations cannot: this returns a partial view ('GET ONLY the GameLoop field') of a larger configuration model, plus the domain boundaries of that field. It does not discuss size, caching, or failure modes, but for a trivial single-key read that is a minor 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?

Two sentences, front-loaded with the scope constraint ('GET ONLY...') before the content and routing guidance. The middle enumeration of gameplay sub-domains is a bit dense but each item helps an agent judge relevance, so it earns its place; only marginally over-explained.

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 carries the burden of telling an agent what comes back, and it does so conceptually (match settings, level pacing, difficulty curves, energy/cooldown gates, retry/continue economy). Combined with the read-only annotations and fully documented single parameter, nothing needed 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?

Only one parameter (title_id) and schema description coverage is 100%, so the schema already defines it. The description adds no title_id format, source, or scoping detail beyond what the schema provides; per the rubric, a highly covered single-param read sits at the baseline of 3.

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 (GET) and a precisely bounded resource: the single 'GameLoop' field of TitlePublicConfigurationModel, then enumerates the gameplay domains it covers. An agent can tell it apart from the sibling get_item/get_character/get_collection/get_season reads because the description explicitly assigns those to different scopes.

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?

Explicit routing: 'Use for tuning the moment-to-moment gameplay; not for content (use Item, Character, Collection) and not for meta-progression (use Season).' Both the when and the when-not are stated with named alternative siblings.

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, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds value beyond that: it maps the status lifecycle (queued|running|completed|failed), explains that Assets/OutputText only appear when done, and notes the operation is free – all context an agent cannot get from annotations.

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 sentences, front-loaded with the core action and its return shape, followed by the polling guidance. Every clause earns its place 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 single-parameter read with no output schema, the description covers the essential return shape and the polling pattern well. It could note pagination/expiry of CDN URLs or rate limits, but nothing critical for correct invocation 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% and the single generation_id parameter is fully documented in the schema, including its origin ('Id returned by a generate_* tool'). The description adds little parameter-level detail beyond restating 'by id', so baseline 3 applies.

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

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

States a specific verb and resource ('Read a generation by id') and enumerates the fields it returns (status with full enum, Assets CDN URLs, OutputText, error). This distinguishes it from the many sibling get_* tools by naming exactly the generation artifact and its lifecycle states.

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 tells the agent when to use it for polling ('Poll it for generations that returned queued/running'), which is the key non-obvious usage pattern given the generate_* siblings that produce the ids. No exclusions are needed because the scope is already narrow.

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, openWorldHint=false, destructiveHint=false, so safety is covered; the description's 'Read-only' partly restates that. However it adds real context beyond annotations: the files are sourced from @idosgames/app-shell and must be written to the project root, and it clarifies the tool returns scaffolding rather than a mutation.

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 is front-loaded and every clause is actionable, but the parenthetical file enumeration makes a single very dense sentence. It earns its length given the absence of an output schema, but could be split for readability.

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

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

There is no output schema, yet the description fully describes the return contents and their origin, plus the required follow-up steps. For a zero-param scaffolding tool this covers everything an agent needs to invoke and act on 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?

With zero parameters the baseline is 4. The description reinforces this by noting it 'takes no title_id', preempting an agent from trying to pass one, though no further parameter meaning 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?

States a specific verb+resource (get the host scaffold) and enumerates exactly what the scaffold contains (index.html, main.tsx, app.config.ts, wallet files, modules.ts, config). It clearly distinguishes itself from get_module and get_manifest by positioning itself as the starting base that those build upon.

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 scopes usage to NEW projects and lays out the ordered workflow: write files to root, install versions from get_manifest, then add modules with get_module. It even explains the selection rule for modules (systems with inBase, games with the modules each game 'uses'). Alternatives and sequencing are fully specified.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds real behavioral value by disclosing the return shape (Dictionary<string,string> of slug -> URL/path) since no output schema exists, plus the 'GET ONLY this field' scoping constraint. No permission/rate-limit notes, keeping it 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?

Front-loaded with the core action, followed by the return type, key/value semantics, and disambiguation. Every sentence earns its place, though the TitlePublicConfigurationModel and Dictionary<string,string> jargon make it slightly dense for an agent-facing description.

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

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

With no output schema, the description compensates by fully describing the returned dictionary and its key/value meaning, and it pre-empts the most likely wrong-tool choice via sibling cross-references. An agent has everything needed to call 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 100% for the single title_id parameter, so the baseline of 3 applies. The description adds no syntax, format, or sourcing guidance for title_id beyond what the schema already documents.

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

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

Opens with a specific verb and resource scoped to a single field: "GET ONLY the 'ImageData' field of TitlePublicConfigurationModel." Combined with the sibling cross-references (Currency, Item, Character), an agent can distinguish this from neighboring getters without opening any schema.

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

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

Explicitly routes the agent: per-currency icons go to Currency.VirtualCurrencies[].AssetPaths, per-item icons to Item, character art to Character. This is a rare, direct when-to-use / use-something-else rule.

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 the safety profile (readOnlyHint true, destructiveHint false), so the description's burden is lighter. It adds real context beyond annotations: the exact field it reads ('GET ONLY the Item field'), the domain it governs, and the downstream systems that reference it (Store SKUs, loot tables, quest rewards, craft recipes). It does not describe return shape or pagination, but those gaps are minor for a read-only single-field getter.

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

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

Front-loaded with the critical scoping phrase ('GET ONLY') and then compactly enumerates contents, defining characteristics, and cross-references. It is moderately long but each clause carries routing or domain value, with no filler sentences.

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 read-only, single-parameter getter with no output schema, the description covers what the tool retrieves, what the data means, and which siblings to use instead. The absence of return-format detail is acceptable given there is no output schema to contradict and the annotations carry the safety contract.

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?

Only one parameter (title_id) and schema description coverage is 100%, so the schema already documents it fully. The description adds no syntax, format, or filtering nuance for the parameter, making the baseline 3 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 ('GET ONLY the Item field of TitlePublicConfigurationModel') and immediately scopes what the resource contains (catalogue of consumables/equipment/resources). It explicitly distinguishes itself from the sibling get_premium and get_character, so an agent can route without opening any 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?

Names two alternatives and the condition that selects them ('for premium-tier bundles use Premium; for character entities use Character'), which is clear routing guidance. It stops short of a full when/when-not matrix, but the cross-references are explicit and actionable.

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 establish readOnly, non-destructive, and closed-world, so the bar is lower. The description adds genuinely useful behavioral context by enumerating what the compact payload contains (key, title, priority, assignee, due date, labels, counters) and what it omits (descriptions, checklists), which matters since there is no output schema.

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, zero filler, with the core read behavior front-loaded and the sibling routing appended last. 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?

With no output schema, the description correctly compensates by describing the returned card shape and pointing to get_kanban_card for depth. It omits any mention of board size limits or pagination, a minor gap for a board that could hold many cards.

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?

Only one parameter and schema description coverage is 100% – the schema already explains project_id and its origin (list_kanban_projects). The description adds no format, syntax, or lookup detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Read a board: its columns and the cards in them') and immediately scopes what the board read contains. It distinguishes itself from get_kanban_card by declaring that cards come back COMPACT, so an agent can tell the two apart 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?

Explicitly names the alternative for full card text ('Call get_kanban_card for the full text of one card'), giving a clear routing rule. It does not cover other siblings such as search_kanban_cards or get_my_kanban_tasks, and gives no explicit when-not-to-use, so it falls short of a 5.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. Beyond that, the description discloses the exact payload a caller receives (description, checklist, links, watchers, estimate, column), which is meaningful since there is no output schema.

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 sentences, zero filler: the first front-loads scope and return content, the second resolves the addressing question. Nothing repeats the name or title.

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-parameter read tool with no output schema, the description supplies the missing knowledge about what is returned and how the card is identified. The required project_id is left to the schema, which is acceptable given its explicit description.

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 basline is 3. The sentence 'Address it either by card_id or by its human key like OPUS-451' adds a concrete key example, but the either/or exclusivity is already stated in the schema's own parameter descriptions, so it adds little beyond what is structured.

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 (read) and resource (one kanban card) and immediately enumerates what the card contains: description, checklist, links, watchers, estimate, column. The emphasis on 'ONE card in full' distinguishes it from the list/search siblings (search_kanban_cards, get_kanban_board, get_my_kanban_tasks) without needing to name 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?

The description explains how to address the card (card_id or human key), but gives no guidance on when to use this tool versus search_kanban_cards for lookup or get_kanban_board for the whole board. The 'ONE card in full' phrasing implies single-card retrieval but never states the condition or exclusions.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered without the description. The description adds one real behavioral detail (chronological ordering, oldest first) but says nothing about pagination or whether the default 100 caps the result.

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 the resource first and the ordering qualifier last. No filler, no restatement of the title.

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 read-only thread fetch, the essentials are present and annotations plus the 100% schema coverage carry the rest. The only gap is that with no output schema, the shape of a returned comment is never described, though that is a minor omission 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 100%, so all three parameters are already documented in the schema, making the baseline 3. The description adds only the ordering dimension; it adds no semantics for card_id, project_id, or how limit interacts with the thread.

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 ('Read the comment thread of a card') plus an ordering guarantee ('oldest first'). It contrasts implicitly with the write-side sibling add_kanban_comment, but never names it, so it stops short of full sibling differentiation.

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

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

Usage is implied by the read-a-card's-thread phrasing, and the read verb distinguishes it from add_kanban_comment. However, there is no explicit when-to-use statement, no mention of alternatives such as get_kanban_card or search_kanban_cards, and no guidance on when to adjust the limit.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context with 'GET ONLY ... field', telling the agent the response is a partial read rather than the full configuration. It stops short of describing return format or field-level defaults, so not 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?

The scoping constraint and the resource contents are front-loaded in the first sentence, and the alternative tool is named last. Every sentence earns its place with no restatement of the title or 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?

With no output schema, the description usefully enumerates what the Leaderboard field contains, partially compensating for the missing return documentation. It is close to complete for a single-parameter read tool, though it does not describe the response envelope or error/auth cases.

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% with a single required title_id, so the schema already carries parameter documentation. The description adds no syntax or format guidance beyond what the schema provides, making the baseline 3 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 precise verb+resource combination ('GET ONLY the Leaderboard field of TitlePublicConfigurationModel') and enumerates the field's contents (name, ranking metric, reset cadence, rewards, eligibility). This clearly separates it from save_leaderboard and from the other get_* config readers.

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 scopes the use case ('pure player-vs-player ranking') and routes the agent to a named alternative for the contrasting case ('For collaborative team goals use CoopEvent'). The agent does not have to infer when this tool is 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?

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds real conceptual context beyond that: what the field contains and the client resolution order t(x) = own table -> fallback table -> x. It does not mention auth needs or rate limits, but the extra structural insight is genuinely 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?

Front-loaded with the operative constraint ("GET ONLY...") and well organized. It is somewhat long and slightly redundant, since the "translation tables live elsewhere" idea is stated twice (once for storage, once for editing), but every sentence carries relevant context rather than 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 read-only, single-parameter tool with no output schema, the description supplies enough: it explains what the returned field represents, the fallback resolution semantics, and where the related translation data lives. Nothing critical for correct invocation is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The single title_id parameter is documented in the schema; the description implies per-title scoping but adds no format, syntax, or constraint detail 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?

States a specific verb and resource: "GET ONLY the 'Localization' field of TitlePublicConfigurationModel," then enumerates exactly what that field holds (locales, default/fallback, missing-key behavior, store limits). It actively carves out its scope against the sibling concern by declaring that translation tables live in the separate TitleLocalization collection, so an agent can tell it apart from get_localization_keys.

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 that this reads settings only and an explicit exclusion: "Add or edit translations through the Localization endpoints, not through this section." However, it does not name the read-side alternative (get_localization_keys) or say when to prefer this over get_title_data, so the routing guidance is good but not fully complete.

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 the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds genuinely new behavioral context on top: long tables are truncated and report that fact, and text resolves via t(x) = player's table -> fallback table -> the key literal itself. The fallback-chain explanation tells the agent what it will actually observe at runtime, which the annotations cannot convey.

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, purpose front-loaded, no filler or restated boilerplate. The final sentence about resolution order is the longest and most tangential, but it earns its place by explaining why untranslated literals still render.

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

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

There is no output schema, so the description must carry return-shape information, and it does: keys with default-language text, the configured locales, and truncation on long tables. Combined with the usage trigger and filter syntax, an agent has everything needed to call this correctly on the first try.

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; the description earns an extra point by making the 'prefix' parameter concrete with examples ('shop.', 'quest.') that show the expected key-namespace format. title_id is left unexplained, but its meaning is unambiguous from 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?

The description states a specific verb and resource ('List the title's localization KEYS') and pins down scope precisely: default-language text plus the configured locales. It is clearly distinguishable from write-side siblings such as save_localization_keys. It does not explicitly contrast itself with the similarly named get_localization, which is the one sibling an agent could plausibly confuse it with.

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 an explicit trigger condition: 'Call it before writing any user-visible string so you reuse an existing key instead of inventing a second one for the same label.' That is strong, actionable when-to-use guidance, and the prefix-filter hint supports invocation. It stops short of naming the alternative tool (get_localization) or stating when not to call it.

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 the read-only, non-destructive, non-open-world profile, so the safety burden is lifted. The description adds useful domain behavior beyond that: the model is section-scoped (only the Lootbox field), and it enumerates what the data contains (pity, guaranteed rares, currency costs, ID references). It stops short of describing return shape or error/edge behavior, so not 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 sentences, each front-loaded and doing work — scope first, content second, alternative third. Slightly dense, but no filler and no repetition.

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

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

For a single read-only, section-scoped getter with no output schema, the description is essentially complete: it says what field is returned, what it contains, and routes the alternative case. Return shape details would be the only omission, and those are not critical for invocation.

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

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

Schema description coverage is 100% and there is a single parameter, so the schema already carries its semantics; baseline applies. The description adds nothing about title_id format or scoping 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?

States a precise verb+resource ('GET ONLY the Lootbox field of TitlePublicConfigurationModel') and fully explains what that resource contains — loot tables, weighted entries, pity systems, guaranteed rares, currencies. It also explicitly names the sibling 'Reward' it must not be confused with, so an agent can differentiate without opening schemas.

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 gives both routing rules: 'GET ONLY the Lootbox field' and 'For straight (non-random) reward bundles use Reward.' That directly answers when-to-use-this vs an alternative; nothing is left to inference.

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, destructiveHint=false, and openWorldHint=false, but the description adds extensive behavioral context: default capacity, overflow removal of oldest letters without unclaimed rewards, expiration loss of unclaimed rewards, gift/transfer burn-on-claim mechanics, fee behavior, and the player-admin plan requirement for reward letters.

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

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

Front-loads the core purpose, but then crams an extremely dense, unstructured block of model details into a single paragraph. The length is partly justified by the absence of an output schema, yet it is not scannable and could be structured more effectively.

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 carries the full burden of explaining the returned Mailbox configuration, and it does so comprehensively. An agent has enough context to understand the resource and call the 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?

Schema description coverage is 100%, and the only parameter title_id is documented in the schema. The description adds no parameter-level meaning beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (GET) and resource (the 'Mailbox' field of TitlePublicConfigurationModel), and explicitly excludes notifications, which are handled by Push. An agent can distinguish it from get_push and save_mailbox without opening the schema.

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

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

Explicitly says notifications are not here but Push, and that letters/broadcasts are not config but sent via dashboard or CloudCode server.SendMail. This names alternatives and exclusions, clearly routing the agent to the right tool or mechanism.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered; the description's 'Read-only' largely repeats that. It does add meaningful new context by disclosing the specific package set returned and the intended use.

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 tight, front-loaded sentences with zero filler: verb+resource, the package list, the reason, and a clarifying note. Minor redundancy in 'Read-only' against the annotations keeps it from a 5.

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 carries the return-value burden and does so by enumerating the exact packages. Combined with the no-parameter statement and use case, an agent has everything needed to call this no-arg read 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 tool has zero parameters, so the baseline is 4. The description reinforces this by stating it 'takes no title_id,' removing ambiguity for an agent used to title-scoped get_* tools.

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 (Get) and resource (@idosgames runtime npm packages), and enumerates exactly which packages (core, wallet, module-sdk, react, app-shell). An agent can distinguish this from the many other get_* siblings purely from the description.

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 applicability: install these packages so the base and modules resolve their imports, and explicitly notes it takes no title_id. It lacks an explicit when-not or named alternative, but no sibling performs this function, so the guidance is sufficient.

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, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds genuine domain behavior beyond that: 'Everything offered is escrowed at creation; commission is taken at settlement' and the escrow/commission lifecycle, which is rich context for interpreting the returned config.

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 read scope is front-loaded in the first clause, then detail follows. It runs several dense sentences for a one-parameter read tool, but the elaboration is mostly load-bearing for differentiating the marketplace from Store and DealOffer.

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 carries the burden of conveying what the Marketplace field contains, and it does so by enumerating the audience gate, schedule, price/commission policy, and tradability lists. It is complete enough for an agent to call and interpret it, though error/pagination behavior is unmentioned.

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% for the single title_id parameter, so the schema already documents the input fully. The description adds no syntax or format detail for title_id, so the baseline 3 applies.

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

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

States a specific verb and resource ('GET ONLY the Marketplace field of TitlePublicConfigurationModel') and immediately names two siblings it is not, distinguishing Store (title-sold SKUs) and DealOffer (promotions) from player-to-player trade. An agent can tell exactly what is read and how it differs from neighbors.

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 positions the tool against alternatives by naming get_store and get_deal_offer domains and clarifying that 'here players trade with each other.' It gives clear selection context, though it stops short of stating prerequisites or an explicit when-not to call it.

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 the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds substantial domain behavior: the grouping under InstantBattle, RuleID keying, wager economy, and cross-references to Character.Stats StatIDs and Item bonuses, which tells the agent what the data means.

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

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

Front-loaded with the core action ('GET ONLY the 'Match' field') before the detail. It is dense and long, but the length is justified by the absence of an output schema and each clause describes a distinct part of the returned 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 output schema, the description carries the full burden of describing returns and does so thoroughly: battle-mode grouping, rule catalogue keying, wager economy, the combat-role→StatID mapping, combat params, and custom formulas. Nothing essential for correct invocation or interpretation 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?

Only one parameter (title_id) with 100% schema description coverage, so the schema already documents it fully. The description adds no syntax, format, or constraint detail for the parameter itself. Baseline 3 applies when the schema does the heavy lifting.

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 ('GET ONLY the 'Match' field of TitlePublicConfigurationModel') and immediately scopes what that resource contains. An agent can distinguish this read-config tool from the save_match sibling and the other get_* config tools without opening the schema.

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

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

Usage is implied by the read-only phrasing and the sibling save_match, but the description never explicitly says when to use this vs save_match or any alternative. No exclusion or prerequisite guidance is provided; the agent must infer the read vs write split from the name and annotations.

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?

Beyond the readOnlyHint/destructiveHint=false annotations, it discloses the pagination contract (nextCursor in the answer), the required client-side actions (write files under src/modules/{id}/, install dependencies, register in src/modules.ts), and the 'takes no title_id' constraint. This is substantive behavioral context annotations cannot carry.

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

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

Front-loaded with purpose, then prerequisites, then paging, then a closing constraint — every sentence earns its place. It is dense with colon-delimited instruction lists, which makes it slightly run-on but not wasteful.

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 still describes what comes back (file contents, install instructions, nextCursor) plus the pagination termination condition and the prerequisite dependency. Nothing an agent needs to call 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% and the schema already explains both id and cursor, so the baseline is 3. The description adds the looping semantics tying cursor to nextCursor and clarifies the file-index meaning of cursor, exceeding what the schema alone conveys.

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 ('Get one module's source (files) plus install instructions') and scopes it precisely. It distinguishes itself from list_modules (source of ids) and get_host_scaffold (the required base), so an agent can route without opening a schema.

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

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

Explicit prerequisites ('The project needs the base first (get_host_scaffold)') and an explicit paging loop ('call again with the same id and cursor=nextCursor until nextCursor is absent'). It also identifies list_modules as the id source, covering when and how to use the tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description goes further, disclosing that the section is ABSENT by default (multiplayer DISABLED), that IceServers must hold only public STUN servers while TURN credentials are engine-issued, and the role of MemberTimeoutMs in host takeover — real behavioral context beyond the annotations.

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 key scope statement is front-loaded in the first sentence. The remainder is dense but largely earns its place by explaining returned fields and topology semantics; a couple of clauses (e.g. the VoxelCraft aside) are illustrative padding rather than essential.

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 carries the full burden of explaining the returned model and does so thoroughly: default-absent semantics, DefaultTopology Mesh/Host, MaxPlayersPerRoom cap (default 8), MemberTimeoutMs, and IceServers policy. An agent can interpret the response without further documentation.

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% with a single title_id parameter, so the schema already carries the parameter documentation. The description never elaborates on title_id syntax or format, so 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 and resource scope: 'GET ONLY the Multiplayer field of TitlePublicConfigurationModel'. The capitalized 'ONLY' makes the read scope unambiguous and distinguishes it from the sibling save_multiplayer, which the description implicitly contrasts by explaining that adding the section turns the module on.

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

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

Usage is implied rather than stated: an agent infers it should call this to inspect multiplayer config before enabling it. There is no explicit when-to-use/when-not or a named alternative (e.g. 'use save_multiplayer to modify'). The section-absent-means-disabled note is helpful context but not 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?

Annotations already declare readOnly, non-destructive, and non-open-world. The description adds useful behavioral context beyond that: cross-board scope, deadline ordering, and default assignee logic. It does not discuss pagination or result limits, but for a simple read operation this is solid.

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 sentences, front-loaded with the core return set and scope, followed by the default behavior. Every sentence earns its place with no redundancy.

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

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

For a simple read tool with two optional params, no output schema, and full annotation coverage, the description provides everything needed: what it returns, ordering, scope, default assignee, and how to override 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?

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by clarifying that assignee_id defaults to the connection owner and is used to fetch a teammate's tasks, which is not evident from the schema alone.

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 resource (cards) with a clear scope (assigned to a person, across all boards) and ordering (soonest deadline first). This scope inherently differentiates it from siblings like get_kanban_card (single card) and get_kanban_board (board-specific).

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 provides clear context: defaults to the connection owner, but pass assignee_id to get a teammate's tasks. It does not explicitly name alternatives (e.g., search_kanban_cards) or state when not to use it, so it falls short of a 5.

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