ScoreIA La Forge

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 blind simultaneous-submission mechanic, the async 'waiting' return when the opponent hasn't moved, the frame-0-is-your-forged-pose rule, the carry-forward pose semantics, and the 16-frame cap. It does not cover failure modes or the precise shape of 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?

Front-loads the core action, then packs the two input modes and the return behavior into a few dense sentences with no filler. The domain jargon makes it terse to the point of requiring careful reading, 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?

For a nested-object tool with no output schema, the description explains both input modes and the return value ('the assault's result, or waiting'), which is what an agent most needs. It remains somewhat incomplete about result contents and the relationship to the forge/seal workflow.

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, but the description adds real meaning by explaining that 'plan' is the Apprentice-level input and 'frames' is the Master-level input, plus the pose inheritance rule for frames. It restates field ranges already in the enum/bounds, keeping it from a 5.

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

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

States a specific action and resource: submitting 'your move for the current assault', sent blind and simultaneously with the opponent. This distinguishes it from siblings like duel_status or duel_ready, though it never explicitly names an alternative.

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 explicit when-to-use or when-not-to-use guidance relative to duel_ready, duel_status, or enter_duel. Usage is only implied by the nature of the operation, and no prerequisites (e.g. needing a forge_handle, or the duel being in progress) are 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?

With no annotations, the description must disclose side effects. It states that the tool locks the knight and that the referee validates and measures it, and that after both are ready the duel starts. However, it does not mention error conditions (e.g., invalid knight), reversibility of the lock, or any return value. This leaves gaps but provides some transparency.

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 sentences and front-loaded with the purpose ('Lock your knight for the duel'). It includes relevant details about the checks and outcome without excessive fluff, earning a 4.

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 has one parameter and no output schema, but the description does not specify what the tool returns or what happens if validation fails. It also doesn't connect to prerequisite tools like enter_duel. Given the simplicity, it's adequate but not complete, so a 3.

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

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

The schema fully describes the single parameter forge_handle with its origin (returned by enter_forge). The description adds no additional meaning about the parameter, so baseline 3 applies given high schema coverage.

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

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

The description clearly states the action 'Lock your knight for the duel' and explains the checks (whole standard knight, weighing) and the outcome (opponent revealed and assaults start). This distinguishes it from sibling tools like forge_add (building) and duel_assault (attacking).

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

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

The description implies when to use it (when you want to ready your knight for a duel) but does not explicitly state order relative to enter_duel or duel_assault, nor mention when not to use it. It lacks explicit alternatives or exclusions, so it's only implied usage.

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

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

With no annotations, the description must carry the behavioral burden. It clearly enumerates the returned data (turn, assault, score, winner) but does not explicitly state that the operation is read-only or has no side effects. While the nature of a status tool suggests it is a query, the description does not disclose this explicitly.

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, front-loaded sentence that starts with the core purpose and then lists specific data points. It is concise, contains no filler, and is easy 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?

For a status query with one parameter and no output schema, the description sufficiently covers the key return values. It does not mention error conditions or prerequisites beyond the parameter, but it gives an agent enough to understand what to expect. The absence of an output schema makes the description's content list essential, and it delivers that.

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

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

The only parameter, forge_handle, is fully described in the schema as 'The forge_handle returned by enter_forge.' Since schema coverage is 100%, the description adds no additional meaning beyond the schema, 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 clearly states the tool reports the duel status: whose gesture is awaited, last assault details, score, and winner. This distinguishes it from sibling tools like duel_assault (action) and duel_ready (readiness signal). The phrase 'Where the duel stands' indicates a query rather than an action.

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

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

The description implies the tool is used to check the current state of a duel, but it does not explicitly state when to use it versus alternatives. It does not mention when not to use it, such as before entering a duel or during an assault, nor does it name any sibling as an 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?

With no annotations, the description carries the full burden and does disclose the key return values (forge_handle, duel_code, rules), which is valuable without an output schema. However, it says nothing about permissions, eligibility, costs, or whether entering a duel has any irreversible effect.

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 the parenthetical routing to forge_add/forge_edit/forge_remove/forge_observe earns its place. The middle sentence is somewhat run-on and jargon-heavy but not 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 12-parameter tool with no output schema the description covers the return shape and opponent workflow, but stays silent on several parameters (level, gear, house_style, match_key, model_claim, provider_claim, participation_class) that the schema must then carry alone.

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 83% (>80%), so the schema already documents nearly every parameter including the opponent enum and duel_code pattern. The description reinforces the house/open/duel_code flow but adds no format or fallback detail 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 (enter) and resource (duel of forged knights) and names the sibling forge_* tools as the build path, so the agent can distinguish it from forge entry points. The framing ('La Joute', ScoreIA's house knight) is colorful but adds some ambiguity over what actually happens.

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 lays out the three participation modes: house (always available), open (another AI joins with your duel_code), or joining an existing open duel by sending duel_code. This is clear conditional guidance, though it never states when to prefer a sibling like duel_ready or enter_forge instead.

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 for behavioral disclosure. 'Start a forge attempt' implies a state-changing action, yet the description does not state whether it creates persistent state, is idempotent, requires prior setup, or has side effects on subsequent sibling calls. It only lists return contents.

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 return contents, with no redundant phrasing. The 'Declare who you are' directive is a compact behavioral cue that earns its place.

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

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

For a 15-parameter tool with no output schema and no annotations, the description gives the essential purpose and return shape but leaves gaps: it does not explain how the response is structured, which identity fields are expected, or how campaign/commission and level affect the attempt. The rich schema compensates partially, but not fully.

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 87%, so the schema already documents most parameters well. The description adds little parameter-level meaning beyond hinting at identity-related claims via 'Declare who you are', which aligns with model_claim, provider_claim, and host_claim but without specifics. A baseline of 3 is appropriate since 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 clearly states a specific verb and resource: 'Start a forge attempt' and enumerates what it returns (commission, coordinate conventions, shapes, materials, roles). It does not explicitly contrast itself with the forge_add/forge_edit/seal_forge siblings, so it misses the top score for 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?

The closing instruction 'Declare who you are' implies this is the entry-point call where the agent identifies itself, and the name 'enter_forge' suggests initialization. However, there is no explicit guidance on when to choose this instead of forge_observe, forge_edit, or seal_forge, nor any exclusion criteria.

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

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

With no annotations, the description must carry behavioral disclosure. It does reveal a key constraint (max 12 parts per call) and a concurrency rule (wait between calls). It does not disclose validation behavior, duplicate handling, or what happens on invalid input, which would matter 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?

The description is two short sentences with no filler. It front-loads the core action and limit, then delivers the call-pattern and input-format guidance. Every clause adds usable 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?

The core purpose and part schema are well covered, but the description lacks lifecycle context: it does not mention that forge_handle must be obtained via enter_forge, nor what the response tells the agent. For a complex tool with no output schema and no annotations, some of that context would be valuable.

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 only 50%, but the description adds meaningful parameter semantics: it states the acceptable count range and clarifies that parts may be supplied as a JSON list or a stringified list. This goes beyond the raw schema types. It does not repeat the detailed nested part schema, which is already well documented.

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 ('Add') and resource ('parts') with a concrete quantity range ('1 to 12 parts'). The sibling names (forge_edit, forge_remove, forge_keyframe, forge_observe) make the distinct action clear; an agent can tell this tool creates new parts rather than modifying or removing 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 gives practical invocation guidance: send one call, wait for the answer before the next, and pass parts as a JSON list or string. However, it does not explicitly contrast this with alternatives such as forge_edit or forge_remove, nor does it state when not to use this 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?

With no annotations, the description carries the full behavioral burden. It discloses that the operation mutates fields and that the id cannot be changed, but it does not explain merge vs. replace semantics, behavior on unknown fields or nonexistent parts, error conditions, response shape, or any required forge state. The id-immutability note is the only meaningful added behavioral 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?

A single sentence with no filler. The core action, target resource, and key constraint are all present and immediately readable. Every word 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?

There is no output schema and no annotations, so the description alone must prepare the agent. It omits return behavior, error handling, update semantics, and preconditions beyond the schema's forge_handle hint. For a mutation tool with three required parameters, this is incomplete.

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 67%, so the description adds some value by mapping 'changes' to part fields and clarifying that id is immutable. However, it does not enumerate valid field names, value formats, or whether changes is a partial update, and the schema itself only provides one example.

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 ('change'), a resource ('fields of an existing part'), and a key constraint (anything but its id). It does not explicitly name sibling tools, but 'existing part' communicates enough contrast with forge_add/forge_remove for an agent to infer its role.

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 'existing part' implies this tool is for modifying an already-created part rather than adding or removing one. However, it provides no explicit guidance on when to choose this over siblings like forge_add, forge_keyframe, or forge_observe, leaving the decision mostly 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?

With no annotations, the description carries the full disclosure burden. It reveals useful behaviors: parts keep their last pose until moved again, and frames are 0.25 s apart. It does not, however, disclose whether setting a pose overwrites existing keyframes, what happens on invalid input, or the result of the operation—important 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?

The description is compact (about 60 words) and front-loaded with the scope, followed by usage modes and a behavioral note. Every sentence adds value, and the moves definition is placed at the end for reference. There is no filler or unnecessary repetition of schema details.

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

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

Given the tool's moderate complexity (4 params, no output schema, no annotations), the description covers the core usage: allowed frame range, single vs. multiple frame invocation, and pose persistence. It does not specify units for position/rotation, whether frame and moves are both required, or error conditions, but the schema's examples partially fill the gap. Overall it is sufficient for a basic correct 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?

The schema covers forge_handle and gives examples for moves and frames, but the description adds critical meaning: the valid frame range (1 to max_frames: 16, 32, or 48), and the exact structure of moves ('moves = {part_id: {position?, rotation?}}'). It also clarifies that frames is an alternative to frame + moves, which is not fully evident from the schema's brief text.

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

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

The description opens with a clear scope ('Animated trials only') and specifies the action: 'set the pose of some parts at one frame' or multiple frames via the 'frames' parameter. It distinguishes this tool from siblings like forge_add/forge_edit by focusing on keyframe placement, and it gives concrete constraints (campaign sizes, frame limits) that make its purpose unambiguous.

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

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

It clearly states the applicable context—animated trials only—and explains the two invocation modes (single frame vs. multiple frames) along with a behavioral rule about pose persistence. However, it does not explicitly name alternative tools for non-animated cases or state when not to use this tool, though the sibling list is self-explanatory in context.

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 of behavioral disclosure. It states what the output contains (bounding boxes, silhouettes), its scope (every part), an important limitation (no referee checks), and how frame selects a pose. It does not explicitly state 'read-only/no side effects', but the verb 'look at' strongly implies it.

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

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

Two sentences, zero filler. The first sentence front-loads the core purpose and output, the second adds a critical limitation and the frame nuance. 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?

Given there is no output schema, the description adequately explains what the agent will get: bounding boxes and silhouettes, plus the frame behavior. It doesn't describe the exact format of the silhouettes or coordinate system, but that is unlikely to prevent a correct selection or 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%, so the baseline is 3. The description adds mild context for frame ('chooses the pose to look at') but this largely restates the schema's 'Animated trials only' and keyframe information. It adds no meaningful detail about forge_handle beyond the schema.

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

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

The description uses a specific verb ('Look at') and resource ('your work'), and elaborates with concrete observable outputs: world bounding boxes and front/side text silhouettes. It also clarifies a key non-goal (does not reveal referee checks), but it does not explicitly name or contrast any sibling tool, so it falls just short of a 5.

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

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

The phrase 'Look at your work' clearly implies when to use the tool: to inspect the current forge state. It gives an explicit exclusion ('Does not reveal the referee's checks') and usage guidance for the frame parameter in animated trials. However, it never names alternative tools, which the top tier requires.

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 present, the description must carry the burden of disclosing behavioral traits. It communicates that the operation is destructive via 'Remove', but it does not state whether removal is irreversible, whether related parts are affected, what happens for invalid IDs, or what the operation returns. For a mutation tool, this is a significant 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?

The description is a single four-word sentence that front-loads the core action and object. There is no filler, repetition, or unnecessary structure; every word earns its place.

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

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

For a destructive tool with no annotations and no output schema, the description is too sparse to be fully actionable. It omits usage context, behavioral effects, relationship to the forge workflow, and any guidance on error cases, leaving the agent to rely primarily on the schema and sibling tool names.

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

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

The schema descriptions cover forge_handle but leave ids undocumented, so schema coverage is only 50%. The phrase 'by id' partially compensates by indicating that ids identifies which parts to remove, but the description adds little beyond the parameter name and does not clarify the format or scope of ids. This is adequate but not strong.

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 'Remove parts by id' specifies a clear verb and resource, and the 'by id' qualifier distinguishes it from sibling tools like forge_add and forge_edit. It is slightly terse because it does not clarify what 'parts' refers to in the forge domain, but it is not tautological or misleading.

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 no guidance on when to use forge_remove versus alternatives such as forge_edit, forge_observe, or seal_forge. There is no stated context, prerequisite workflow, or exclusion condition, so the agent must infer usage from the name and schema.

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

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

No annotations are provided, so the description carries the full burden of explaining behavior. It vaguely hints at validation ('checks the commission') and a return value ('returns your card'), but it does not disclose whether the operation is irreversible, what happens to the forge_handle, or what the returned card actually represents.

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 text is short and begins with 'Finish', but 'Final' redundantly repeats that idea, and the referee/card metaphor uses space without providing operational clarity. This is under-specification rather than disciplined conciseness.

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

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

Despite having only one well-documented parameterhola, the description does not explain the tool's effect, return value, or sequencing relative to the forge_* siblings. With no output schema and no annotations, the missing behavioral and return information leaves the tool incomplete for reliable 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 coverage is 100%: the single required parameter, forge_handle, is already documented as being returned by enter_forge. The description adds no additional parameter meaning, format, or constraints, so the baseline score 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?

The description only communicates finality ('Finish', 'Final') but never clearly states what seal_forge does to a forge, commission, or card. The actual resource and effect are left to metaphor, so an agent cannot confidently distinguish it from a generic terminal operation or from tools like forge_remove.

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?

'Final' and the requirement of a forge_handle returned by enter_forge imply this is meant to be called at the end of a forge workflow. However, the description does not explicitly say when to use it versus forge_edit, forge_observe, or forge_remove, nor does it state any exclusion conditions.

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