Agents & Dragons

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

With no annotations, the description carries the full burden and does well: it discloses the failure mode (illegal build returns 400 with an {errors} list to fix and resubmit) and the conditional dependency on rollId. It does not state what a successful call returns or whether creation is idempotent, which are the remaining gaps for a mutation 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 sentences, front-loaded with the core action and the required-field list. The middle sentence enumerates optional field names that the schema already lists, which is partly redundant, but it is doing work by grouping them as conditional rather than always-required.

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 20-parameter, nested-object tool with no annotations and no output schema, the description covers required vs. conditional fields, the rollId prerequisite, and the error path. It omits the success return shape (no output schema exists to compensate) and does not name ad_get_build_options directly.

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 above that by explaining conditional relevance — the optional pick fields are "used where the chosen race, class, and background call for them" — and by calling out the rollId condition tied to abilities.type. That is meaning the schema cannot express on its own.

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 character") plus the input contract ("from a full build object"), which distinguishes it from the read-oriented siblings like ad_get_build_options and ad_get_rolls. An agent immediately knows this is the write path that consumes a build object rather than producing 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?

Prerequisites are stated concretely: rolled ability scores require a rollId from POST /api/ability-rolls, and race/class/background values must come "exactly as listed in the build options" (i.e. from ad_get_build_options). No explicit when-not guidance or named sibling tool reference, but the ordering of operations is clear.

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

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

With no annotations, the description carries the full burden. It adds real behavioral context beyond the schema: the templateId/campaignId mutual exclusivity and the caveat that seed is only honored "where supported." It still says nothing about permissions, whether the table goes live immediately or must be started via ad_start_table, or what is returned.

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 action, then each parameter in a compact semicolon-separated clause. Dense but every clause carries information; only the repeated "sunken-bell" example is redundant with the schema.

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

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

For a five-parameter mutation tool with no annotations and no output schema, the description covers all parameters but leaves the lifecycle (create vs. start) and the return shape entirely unaddressed. Adequate to invoke, incomplete for an agent reasoning about what happens next.

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 semantics the schema does not: templateId and campaignId are framed as alternatives, and seed is qualified as conditionally supported. The "sunken-bell" example duplicates the schema field description, but the exclusivity rule is net-new value.

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+resource ("Create a table"), which is unambiguous against siblings like ad_create_character, ad_join_table, and ad_get_table. It doesn't explicitly contrast itself with ad_join_table or ad_start_table, but the name-plus-verb combination makes the scope 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?

It does give one genuinely useful selection rule — use templateId to launch from a template, or campaignId to attach an existing campaign "instead" — which tells the agent the two are alternatives. But there is no guidance on when to create a new table versus joining/spectating an existing one, and no prerequisites (e.g., whether registration is needed first).

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

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

With no annotations provided, the description carries the full burden. It does disclose one meaningful behavioral fact — no authentication required — and the enumerated content implies a static, read-only reference dataset, but it says nothing about caching/staleness, result size, or whether the option lists are complete or campaign-scoped.

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

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

One sentence, front-loaded with the verb and resource, with the enumerated payload in the middle and the auth note trailing. Every clause adds information; 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 zero-parameter, annotation-free tool with no output schema, the description does the important work by listing the categories returned, effectively standing in for return-value documentation. It is only slightly incomplete in not clarifying whether these options are global or tied to a specific game system/setting.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to disambiguate, and the empty schema with additionalProperties=false is self-consistent with a parameterless reference fetch.

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 ('Fetch') and resource ('legal character-build options') and then enumerates exactly what is returned: races, classes, backgrounds, alignments, languages, weapons, spells, feats, and point-buy/standard-array rules. This clearly separates it from mutating siblings like ad_create_character, which consumes this reference data rather than producing it.

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 this is the lookup to call before ad_create_character, but the description never says when to use it versus other read tools such as ad_get_me or ad_get_rolls, nor does it state any prerequisites or exclusions. 'No authentication needed' is useful context but is not usage 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?

With no annotations, the description carries the full load. It does disclose the key behavioral trait — results are scoped to the authenticated player — which is valuable context an agent cannot get from the empty schema. However it says nothing about behavior when unauthenticated, whether the character list can be empty, or the response shape.

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

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

A single front-loaded sentence with no filler. The scope (authenticated player) comes first and the payload detail (characters with status and table) follows.

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 return values, and it does list player plus per-character status and table. It stops short of describing the fields of the player record or the empty-state case, but it is sufficient to 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?

Zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and it correctly signals that the tool takes no arguments by describing an identity-derived result.

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

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

Specific verb ('Return') plus a precisely scoped resource: the authenticated player and all of their characters, including each character's status and table. It is clearly distinguishable from siblings like ad_get_table or ad_list_tables because the scope is the caller's own identity, not arbitrary tables.

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 can infer this is the identity/bootstrap call, but the description never says when to prefer it over ad_get_table or ad_list_tables, nor does it mention prerequisites such as being registered. Implied context only.

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

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

With no annotations, the description carries the full burden: it discloses that the log is 'public', that entries come 'in order', and what fields each entry has, which is useful. It omits access prerequisites (does the caller need to be at the table to read it?), whether results are live or snapshot, and error behavior for an unknown tableId.

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, front-loaded with the purpose and the return contents, followed by the paging instruction. Nothing is wasted and nothing important trails.

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?

Because there is no output schema, the description's enumeration of returned fields (die, modifier, total, target, outcome) is doing real work and makes the tool callable without guesswork. The remaining gap is access/error semantics for a mutation-free read against a specific table.

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 schema already documents after as a roll id sequence cursor and limit as 1-500 with a default. The description only adds the paging intent, which is a marginal gain over the schema.

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

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

States a specific verb and resource ('Read the table's public roll log') and enumerates what a roll entry contains, so the agent knows exactly what comes back. It does not explicitly differentiate from siblings, but no sibling overlaps this resource, so ambiguity is low.

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 after and limit to page through it' gives a clear usage pattern for the two optional parameters. It does not say when to call this at all (e.g., polling for new rolls after an action, refreshing a log view) or what to do on an empty result, so guidance is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full behavioral burden. "Read" plus the enumeration of returned state makes clear this is a non-mutating inspection and tells the agent what data it receives, which is genuinely useful. However, it says nothing about behavior when the table is missing, whether the snapshot is live or cached, or any access requirements for a table the agent may not be seated at.

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

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

One front-loaded sentence that leads with the verb and resource before the field list, with no filler or redundancy. The enumerated state list is dense but each item maps to a distinct payload component, so it earns its 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?

The tool is a simple single-parameter read with no output schema, so the description must characterize the response — and it does, itemizing essentially every top-level field an agent would get back. Only the error/empty-table behavior and freshness semantics are missing, which is acceptable for this complexity.

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 baseline of 3 applies. The description mentions "a table's" state but adds no meaning about the identifier's format or origin 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 ("Read a table's full state") and enumerates the returned facets: campaign, party, scene with checks/choices/encounter, round, submitted actions, recap, combat. That is far more specific than a restated name. It stops short of an explicit sibling contrast (e.g., vs. ad_spectate_table or ad_list_tables), which keeps it at 4 rather than 5.

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

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

Usage is only implied: an agent can infer this is the call to inspect one table's live condition, but there is no statement of when to prefer it over ad_spectate_table, ad_list_live_tables, or ad_get_rolls, and no prerequisites or exclusions. With thirteen siblings, the absence of routing guidance is a real 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?

With no annotations, the description carries the full burden. It does disclose a real behavioral constraint the schema cannot: a hard cap of 6 seats shared across humans and agents. It omits what happens on a full table, whether the table must be unstarted, idempotency, and required authorization.

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, action first, constraint second, with no filler. Every clause carries information an agent needs.

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 two-param state-changing tool with no annotations and no output schema, the definition is minimal but workable. It leaves the agent without failure-mode guidance (table full, table already started, character already seated) or any sense of what the call returns.

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 (tableId, characterId) are already documented in the schema. The description adds only the ownership nuance in "your character's id"; it gives no format, sourcing, or discovery hints (e.g., where to get tableId).

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?

A specific verb+resource: "Seat one of your characters at a table" makes the join action unambiguous. It implicitly separates itself from ad_create_table and ad_list_tables, but never names ad_spectate_table, the closest sibling, so the agent must infer passive-vs-active participation.

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: "one of your characters" hints that a character must exist first (ad_create_character) and that you are the owner. There is no explicit statement of when to use this versus ad_spectate_table, nor any prerequisite or exclusion 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?

No annotations are provided, so the description carries the burden. It does disclose a meaningful behavioral trait — results are limited to the public spectator view and require no authentication — but says nothing about result size, ordering, or whether private tables are silently excluded.

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

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

A single sentence with the key qualifier ('without authentication') placed inside the parenthetical up front. Nothing redundant, nothing 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 no-param list tool with no output schema, the description covers purpose and access scope adequately. A brief note on what fields each listed table carries or how it relates to ad_list_tables would close the remaining gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline for a no-param tool applies, and the description correctly signals the tool is argument-free by describing a fixed listing.

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 (List) and resource (tables) with a scoping qualifier: tables spectatable without authentication. This distinguishes it in substance from ad_list_tables and ad_spectate_table, though it does not name those siblings 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?

The phrase 'can be spectated without authentication' implies the use case (finding public/spectator-visible tables), but the description never says when to prefer this over ad_list_tables or how it pairs with ad_spectate_table. Usage is 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?

No annotations are provided, so the description carries the full burden. It does disclose that authentication is required, which is genuinely useful behavioral context, but it says nothing about what is returned (names, IDs, visibility rules) or whether all tables or only public ones are shown.

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

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

Two short sentences with no filler; the core action is front-loaded and the usage hint follows immediately.

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 zero-param list tool with no output schema, the essentials are covered, but with near-identical siblings (ad_list_live_tables, ad_get_table) the definition should clarify scope — all tables vs. live tables vs. one table — which it never does.

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

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

The tool takes zero parameters, so the parameter baseline of 4 applies. The description adds nothing that could conflict, and the empty schema is self-explanatory.

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

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

States a specific verb and resource ("List tables") and the parenthetical clarifies authentication context. It does not distinguish itself from the sibling ad_list_live_tables or ad_get_table, so an agent cannot tell which listing variant to pick from the description alone.

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 this to find a table to join" implies a use context, which is more than nothing. But the sibling set contains ad_join_table and ad_list_live_tables, and the description never says when to prefer this over those alternatives or when not to use 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?

With no annotations, the description carries the full burden and does well: it discloses that the credential is shown exactly once, that production registration is unnecessary, and that human accounts require a loginName. It leaves out error behavior, idempotency, and permission requirements, but covers the most important operational traits.

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 tool's purpose and followed by the production caveat and then parameter constraints. Every sentence carries useful information and there is no 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?

For a registration tool with no output schema, the description supplies the critical return behavior — the credential is shown exactly once — plus production prerequisites and the key parameter conditions. An agent has enough information to call it correctly and to know when it should not.

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 already 100%, so the baseline is 3. The description still adds meaning: it reinforces that displayName is required, states the conditional requirement that human accounts also need loginName, and explains house as marking an operator-run companion seat rather than restating the parameter names.

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 — create a local account and receive a credential — and immediately frames it as a local/test fallback, distinguishing it from the sibling table and character tools. An agent can tell exactly what this tool is for 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 explicitly says when to use this tool (local/test fallback) and when not to (production, where an Oids API key already works). That is a clear when/when-not rule with a named alternative 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?

With no annotations, the description carries the behavioral burden and does explain that the engine computes checks, attacks, and saves and narrates the result. It omits important mutation details such as permissions required, irreversibility, and error behavior, so it is adequate but incomplete.

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 focused sentences with the main action front-loaded. The parenthetical adds useful behavioral detail without waste, and the auto-resolution note is 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 tool with no output schema, the description explains the action and what the engine does. It does not mention prerequisites such as table membership or authorization, which slightly limits completeness, but the core operation is well covered.

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 tableId parameter is already well documented. The description adds no parameter-specific meaning beyond the schema, 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 uses a specific verb and resource: 'Close and resolve the current scene window now.' It is clear what the tool does, but it does not explicitly differentiate this action from sibling tools such as ad_submit_action or ad_start_table.

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 word 'now' and the note that a window also resolves on its own when it fills or expires gives clear usage context: this tool forces early resolution. However, it does not state when not to use it or name alternative tools.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses the key trait that no authentication is required and sketches the view contents, but says nothing about visibility of private/secret state, error behavior for unknown tableId, or whether the view is live/streaming versus a snapshot.

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

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

One sentence, front-loaded with the verb and the unauthenticated public-view scope, and the return contents listed compactly. Nothing is wasted.

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

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

A simple one-parameter read tool with no output schema, and the description does supply the shape of the returned view (story so far, party, current scene, state) plus the auth-free nature. Only edge-case behavior remains unstated.

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?

Single parameter with 100% schema description coverage, so the schema already defines tableId. The description adds no format details, source of the id, or validity conditions, 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?

Specific verb (read) plus a precisely scoped resource (one table's public spectator view) and an enumeration of what the view contains (story so far, party, current scene, state). It implicitly separates itself from authenticated siblings like ad_get_table by stressing the unauthenticated spectator scope, though it never names that sibling.

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

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

Usage is only implied: 'without authentication' signals the situation where this is the right call, but there is no explicit when-to-use, when-not, or named alternative (e.g. ad_get_table for authenticated full data). An agent must infer the choice from the word 'spectator'.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the creator-only permission constraint, which is important for an agent to know. However, it does not explain side effects, whether starting is idempotent, what happens if the table is already started, or what errors may occur.

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 short sentences with no wasted language. The action and the key eligibility constraint are both front-loaded and easy 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 simple one-parameter action with no output schema, the description covers the core purpose and the most important permission rule. It could say more about state requirements or failure behavior, but it is largely complete for an agent to decide whether and how to call 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 the single 'tableId' parameter is already documented. The description adds a small amount of meaning by implying the table must be one the caller created, but it does not add format or validation details beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Start play at a table.' It also narrows the scope to 'a table you created,' which helps distinguish it from joining or spectating a table. It does not explicitly name sibling tools as alternatives, but the action is clear.

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 clear precondition: 'Only the table's creator can start it.' This tells the agent when the tool is eligible and when it is not. It does not explicitly compare against alternatives such as ad_join_table or ad_spectate_table, but the usage context is clear enough.

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

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

With no annotations, the description carries the full burden and does disclose key behavior: one submission per character per window and a 409 on duplicate submissions. It omits auth/ownership requirements, whether a submission can be amended before resolution, and what a successful response 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?

Three tight sentences with the core instruction, a formatting example, and the constraint/error behavior front-loaded. No filler or repetition of the schema.

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?

Covers purpose, input formatting, and the main failure mode for a simple three-parameter mutation with no output schema. The remaining gap is the success response shape and whether submissions are mutable, which an agent might need.

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 real meaning to 'body' — plain language, exact target and spell names, with a concrete example. It adds nothing beyond the schema for tableId or characterId, but those are self-explanatory.

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: submit one character action for the current scene window, in plain language. The scope constraint ('one action per character per window') and the naming convention make it clearly distinct from siblings like ad_resolve_window or ad_get_rolls.

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 to call (during the current scene window, once per character) and an example of correct input. It does not explicitly route to alternatives such as ad_resolve_window for advancing the window or ad_get_rolls for outcomes, so the when-not guidance is only implied.

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