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

With no annotations, the description carries the full disclosure burden. It adds useful behavioral details: every node sharing the unit_tag must pass its own guard, and one failure rejects the whole request. However, it does not disclose side effects, idempotency, whether the request is asynchronous, or what happens on success.

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 highly concise and front-loaded with the primary purpose. The two additional sentences add meaningful caveats without padding. The phrase 'There is no unit table' is cryptic but still earns its place as a clarifying detail.

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

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

For a state-changing tool with no annotations, no output schema, and six undocumented parameters, the description is incomplete. It gives no parameter semantics, no usage preconditions, no return behavior, and no side-effect disclosure, leaving an agent to guess at important invocation details.

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

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

The input schema has 0% description coverage, so the description must compensate, but it barely does. It mentions unit_tag in the guard condition, but the required session_id and parameters like manual_override, expected_state_version, node_id, and request_id are left unexplained.

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 action and resource: 'Request the next unit.' It is clear enough to identify the tool's core function, but it does not explicitly distinguish itself from closely related siblings like start_unit, check_advance_unit, or rollback_unit.

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 this tool versus alternatives. It does not mention check_advance_unit as a precondition, nor does it state when advancing is appropriate. The context is implied only by the tool name and the phrase 'next unit.'

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. 'Record ... in its authoritative table' implies a durable write operation, but it does not explain whether the record is created or updated, whether it is idempotent, what side effects occur, or what the return value is. This is thin 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 a single front-loaded sentence with no filler or redundant phrasing. It is genuinely concise, though the brevity contributes to gaps in behavioral and parameter detail.

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

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

Given six parameters, no annotations, and no output schema, this description is contextually incomplete. It does not clarify how this tool relates to resolve_misconception, how severity is interpreted, or how request_id/session_id participate in the operation, leaving an agent to guess important calling details.

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

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

Schema description coverage is 0%, and the description does not explain any of the six parameters. The names learner_id, node_id, and misconception are self-explanatory, but severity's scale/range, the purpose of request_id/session_id, and the expected format of misconception are left entirely to inference.

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 ('Record') and a specific resource ('an active misconception' in its 'authoritative table'), so an agent can understand the core operation. However, it does not distinguish itself from closely related sibling tools such as resolve_misconception or assess_response.

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 intent is implicitly clear: use this when an active misconception needs to be recorded. There is no explicit guidance about when to prefer a sibling tool, nor any exclusion criteria, so usage context is only implied rather than stated.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does disclose an important side-effect trait ('Does not persist anything') and a design rule ('transfer and hint_dependency are excluded from the aggregate by design'). But it does not explain what 'validate' means in practice: what happens on invalid scores, whether errors are raised, or how the weighted overall_score is produced.

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 and front-loaded with the primary action. The second and third sentences add genuinely important behavioral details without padding. 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?

Given five parameters, a nested scores object, zero schema descriptions, no annotations, and no output schema, the description is not complete enough. It omits validation criteria, return shape, weight derivation, and the relationship to persisting alternatives like commit_assessment.

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

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

Schema description coverage is 0%, so the description must compensate. It adds only high-level meaning: dimension scores feed the aggregate, and transfer/hint_dependency are excluded. It does not clarify the shape of the scores object or the roles of session_id, raw_answer, assessor_type, or assessor_confidence.

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

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

The description opens with a specific verb-resource pair: 'Validate dimension scores and compute the weighted overall_score.' It also distinguishes itself from sibling persistence tools by stating 'Does not persist anything,' so an agent can tell this is a stateless scoring/validation step rather than a commit or generation 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 provides useful context about non-persistence and the deliberate exclusion of transfer and hint_dependency, which implies this is a calculation-only tool. However, it never explicitly states when to prefer this over related tools like commit_assessment or generate_assessment, nor does it name alternatives.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does convey the key non-mutating behavior ('without changing state'), which is essential. However, it does not disclose what the dry-run actually evaluates, what it returns, or whether it performs any validation-related side effects. Minimal but not misleading.

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

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

The description is a single, compact sentence with no filler. It front-loads the main purpose and the key safety property ('without changing state'). 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 tool with five parameters, no output schema, and no annotations, this description is too sparse. It explains the top-level intent but leaves the agent without enough context about parameter roles, return behavior, or how this interacts with the state guard. Significant gaps remain.

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

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

Schema coverage is 0% and the description provides no information about any of the five parameters. session_id, node_id, unit_tag, manual_override, and expected_state_version are all left unexplained, so an agent cannot infer how to set them correctly from either the schema or the description.

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 ('dry-run') and resource ('State Guard for an advance request') and explicitly notes that no state is changed, which distinguishes it from sibling tools like advance_unit. It would be a 5 if it named the alternative directly or clarified the 'State Guard' jargon, but the core purpose 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 'without changing state' phrase implies this is the safe/preflight variant of advance_unit, but the description does not explicitly say when to use this tool versus advance_unit or any related sibling. Usage guidance is implied rather than stated.

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

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

With no annotations provided, the description carries the full burden and discloses meaningful behaviors: it is a server-side mutation, raw_answer is stored for audit and never discarded, and mastery_probability is runtime-computed. This is solid for a write tool, though it omits reversibility and the optimistic-concurrency role of expected_state_version.

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, purpose front-loaded, no filler. The second sentence packs three distinct facts (mandatory params, audit retention, runtime computation) into a compact block, which is dense but not disorganized enough to penalize heavily.

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 13-parameter mutation tool with zero schema descriptions, no output schema, and no annotations, the description is under-specified. It explains the core intent and two parameters but leaves ten parameters, their value ranges, concurrency semantics, and the return shape unaddressed. An agent cannot confidently construct a correct call without guessing at most field meanings.

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

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

Schema coverage is 0%, so the description must compensate, but it only adds meaning for two of thirteen parameters. Worse, it introduces a discrepancy: it calls assessor_type 'mandatory' while the schema gives it a default and only attempt_id/raw_answer are required, and it references mastery_probability, which is absent from the schema entirely. The remaining ten parameters (transfer, confidence, correctness, reasoning_quality, etc.) receive no explanation.

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 (commit) and resource (assessment evidence), and discloses a side effect (update learner state server-side). This distinguishes it from evaluation tools like assess_response and generation tools like generate_assessment, though it doesn't explicitly name a sibling, and the boundary with submit_attempt is left 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?

No when-to-use guidance or exclusions are provided. The description implies this is the persistence step after assessment, but it never names alternatives (submit_attempt, assess_response, commit_pedagogical_decision) or states the condition that selects this tool over them. The mandatory-parameter note reads as parameter guidance rather than usage 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 disclosing effects. It only says the tool records for replay, but does not say whether it appends to a log, has side effects, is idempotent, requires prior session state, or returns a confirmation. This is a significant gap for a mutating commit operation.

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 a clear verb, object, and purpose, and no filler. The key constraint ('actually acted on') is front-loaded, so an agent can quickly understand the tool's intent.

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 an 8-parameter, no-annotation, no-output-schema mutation tool, one sentence is insufficient. Missing context includes durability of the record, what 'replay' entails, whether related records must exist first, and what the response or side effects will be.

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

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

Schema description coverage is 0%, and the description adds no parameter-level meaning beyond what the property names themselves imply. It does not explain which fields form a valid decision record, what node_id/request_id represent in this context, or how selected_action relates to selected_strategy; the description should compensate for the missing schema descriptions but does not.

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 ('Record'), a specific object ('the decision actually acted on'), and a purpose ('for later replay'). The phrase 'actually acted on' distinguishes it from sibling tools that evaluate or retrieve decisions, such as evaluate_pedagogical_policy and get_decision_log.

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 wording implies this should be called after a decision has been executed, not for hypothetical or evaluated options, but it never names alternatives or states when to prefer a sibling tool. There is no explicit when/when-not guidance or 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It reveals that the tool mutates session status, but it does not state side effects, whether the previous status is overwritten, whether the session must exist, or what the response looks like. This is thin disclosure 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 a single efficient sentence with no wasted words. The valid status values are placed inline, front-loading the most useful information. It could afford more behavioral detail, but as written it is appropriately sized.

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 mutating tool with no annotations, no output schema, and minimal parameter documentation, the description is incomplete. An agent is left to infer prerequisites, side effects, and the meaning of request_id. It is barely sufficient for a straightforward call and weak for confident decision-making.

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

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

Schema description coverage is 0%, so the description must compensate for explaining parameters. It does add meaning to 'status' by listing the accepted values, and 'session_id' is inferable from its name. However, 'request_id' is left entirely unexplained, and the default status of 'completed' is only discoverable from the schema, not described.

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 ('Set') and resource ('session status'), and explicitly enumerates the allowed states: active/paused/completed/abandoned. This makes the tool's function clear and distinguishes it from siblings like create_session or get_session_info. The name 'complete_session' is slightly narrower than the actual behavior, but the description resolves that ambiguity.

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 this tool is used when a session's status needs to be transitioned, which gives some usage context. However, it does not explicitly state when to use this tool versus create_session or when not to use it, nor does it mention prerequisites like whether the session must already exist.

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 and does add meaningful context: domain-grounding switches are stored per session, not globally, and the returned notice must be shown to the user before the grounding stage starts. This is valuable beyond the schema, though it does not cover all side effects or return behavior.

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 concise and front-loaded with the primary purpose. The extra behavioral details about domain-grounding and the user notice earn their place, though the phrase 'P0 is single-learner' is jargon that could be clearer.

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 6 parameters, no output schema, and no annotations, yet the description only partially clarifies session creation behavior. It does not explain return values, the meaning of topic, how request_id is used, or the full set of domain-grounding switches, so an agent has insufficient context to call it reliably.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies learner_id ('required, P0 is single-learner') and domain_grounding_warn_user ('returned notice must be shown to the user'). However, other parameters including topic, request_id, learner_name, and allow_skip_domain_grounding are not semantically explained, leaving significant gaps.

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 creates a learning session, using the specific verb 'create' and the resource 'learning session'. This naturally distinguishes it from sibling tools like get_session_info, find_session, and complete_session, which are read/find/complete operations.

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 prerequisite ('learner_id is required') but does not explain when to use this tool versus alternatives. It never names sibling tools or exclusion conditions, leaving the agent to infer that creating is different from fetching or completing.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal one key trait: node content is generated by the host agent's LLM, implying the tool only provides a structural template. However, it omits other important behaviors such as whether the tool saves anything, what the template format is, whether it modifies session state, or what the expected output looks like. This is a minimal disclosure for a tool with no annotation support.

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 concise, only two sentences, and front-loads the core action. However, it is under-specified – it lacks essential context that would justify its brevity. It is not verbose, but it also does not earn its place by providing sufficient information; it is simply too terse for the tool's complexity.

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 has 2 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain the purpose of the DAG template, how the topic parameter influences it, what session_id is used for, and what the expected return structure is. An agent cannot reliably invoke this tool without guessing.

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

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

Schema description coverage is 0%, meaning the schema provides no descriptions. The description also says nothing about the parameters 'topic' and 'session_id'. It does not explain what topic is for (presumably the subject to decompose), nor what session_id refers to. Without any parameter explanation, the agent cannot know how to populate these fields correctly, making this a critical gap.

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

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

The description states a specific action ('Return a DAG template') and a resource, which is more than a tautology. However, it does not clearly connect the action to the tool's name 'decompose_topic' – it fails to explain that this template represents a decomposition of the provided topic. It is not distinguished from any sibling because no sibling is similar, but the purpose remains ambiguous: does it just return an empty template, or does it structure the decomposition?

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

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

No guidance is given on when to use this tool versus alternatives. It does not mention prerequisites, conditions, or scenarios where this is preferred. The description is entirely silent on usage context, leaving the agent to infer from the name alone.

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 burden of behavioral disclosure. It does disclose a key trait—no decision is persisted—which is important and not inferable from the schema. However, it does not say whether the call is fully read-only, what side effects if any occur, whether permissions are required, or what the response contains.

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 that front-loads the action and the crucial non-persistence qualifier. There is no filler; every word contributes to the 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?

Even for a simple tool, the lack of an output schema and annotations means the description should explain the return value and parameter semantics; it does neither. The agent knows this evaluates without persisting but not what it receives back or how node_id/trigger_event influence the evaluation.

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

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

Schema description coverage is 0% and the description does not mention session_id, node_id, or trigger_event at all. It therefore adds no meaning to the parameter names, despite those names being somewhat 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?

The description names a specific action ('Evaluate') and resource ('the policy for the current state'), and explicitly sets it apart from commit_pedagogical_decision by saying no decision is persisted. It would be a 5 if it clarified what kind of result the evaluation yields, since 'policy' is otherwise ambiguous.

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

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

The phrase 'without persisting a decision' implies this is a dry-run or non-committing alternative to commit_pedagogical_decision, but it never names that tool or states when to prefer evaluation over other policy/strategy tools such as get_available_strategies. The usage context 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 burden of behavioral disclosure. It mentions the optional file-path behavior, but it does not state whether the tool returns JSON when no path is given, writes a file when a path is supplied, or what happens for invalid or missing sessions. This is a significant transparency gap for a tool with no annotation safety net.

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 sentence with no filler, and the core verb and resource are front-loaded. It is efficiently structured, though it sacrifices potentially useful guidance for brevity.

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 two-parameter export tool, the core contract—export the full session as JSON, optionally to a file—is minimally conveyed. However, without annotations or an output schema, return behavior, file-writing semantics, and error conditions remain ambiguous. It is adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It only clarifies 'output_path' as an optional file path; it does not explain 'session_id' beyond the property name. The property names are self-explanatory, but the description adds little meaning beyond what the schema already shows, which is insufficient at 0% 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 names a specific operation ('Export'), a specific resource ('full session bundle'), and a format ('JSON'), which clearly communicates what the tool does. It is distinguishable from siblings like get_session_info in that it exposes the full bundle, but it does not explicitly name a sibling it is not, so it stops short of top-level 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?

There is no guidance on when to use this tool versus alternatives such as get_session_info, list_artifacts, or complete_session. The phrase 'full session bundle' implies a broad export, but there are no explicit conditions, prerequisites, or exclusions, leaving the agent 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?

With no annotations available, the description carries the full burden. It clearly implies a read-only lookup of existing sessions and says the result is a session id, but it does not mention whether multiple sessions may be returned, what happens on no match, or any other behavioral details.

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. The core function is front-loaded, and the usage context is clearly separated 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?

For a simple two-parameter lookup with no nested objects or output schema, the description provides enough context: the purpose, the filter parameters, and the use case. It could be stronger by noting whether it returns one session id or a list, but the essential information is present.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain that learner_id is the primary filter and topic is optional, but it adds little beyond what the schema already encodes (required learner_id, topic with null default) and does not clarify matching semantics or return behavior.

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

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

The description states a specific verb ('Find') and a resource ('existing sessions') with clear search criteria ('by learner and optionally topic'). It also states the concrete outcome ('recover a session id'), which differentiates it from create_session and get_session_info.

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 second sentence gives a clear trigger condition: 'after a chat window is reopened.' This tells an agent when this tool is appropriate, though it does not explicitly mention 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?

No annotations are present, so the description bears the full burden of disclosing behavior. It only says 'Return ... blueprint,' which suggests a read-like operation, but it does not state whether anything is persisted, whether state is mutated, or what the side effects are on the session.

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 concise, front-loaded sentence with no filler, which is good. However, it is so brief that it omits necessary semantic detail, making it under-specified rather than efficiently complete.

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 four parameters, no output schema, no annotations, and a complex sibling set, this description is far from complete. It does not explain what the assessment blueprint looks like, how parameters shape the result, or whether the operation has side effects, so an agent lacks critical information for 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?

Schema description coverage is 0%, and the description adds no meaning for any of the four parameters (count, node_id, session_id, question_type). It does not explain what count controls, how node_id scopes the blueprint, or what question_type values are accepted, leaving the required session_id and optional params semantically opaque.

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

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

The description names a specific verb ('Return') and a specific resource ('assessment blueprint with the rubric dimensions to score'), which clearly conveys the tool's core function. It is likely distinguishable from siblings like generate_diagnostic or assess_response, but it does not explicitly differentiate itself.

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 choose this tool over siblings such as generate_diagnostic, generate_transfer_probe, or assess_response. No exclusions, prerequisites, or contextual triggers are provided, so the agent must infer when it 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?

With no annotations, the description carries the burden of behavioral disclosure, and it adds a valuable non-obvious behavior: the State Guard rejection and the precise bypass condition. It does not disclose whether a successful call has side effects or what the blueprint contains, but the disclosed constraint 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?

The description is short, front-loaded, and contains no filler. The first sentence states the purpose and the second adds a critical rejection condition, so 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?

For a simple two-parameter tool, the description conveys purpose and an important precondition, which is minimally viable. However, it leaves undefined what a 'diagnostic blueprint' is, how this relates to sibling diagnostic tools, and what the parameters mean, so an agent is left with noticeable gaps.

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

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

Schema description coverage is 0%, and the description says nothing about request_id or session_id. Because the coverage is low, the description needed to explain the parameters but did not, leaving the schema to do all 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?

The description uses a specific verb-object pair, 'Return a diagnostic blueprint,' so the basic purpose is clear. However, it does not distinguish this from similar siblings such as generate_assessment or get_diagnostic_result, so it stops 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 description gives a concrete precondition: the call is rejected until Domain Grounding is completed unless allow_skip_domain_grounding=true. This implies when the call is allowed, but it does not explain when to choose this tool over alternatives like submit_diagnostic or get_diagnostic_result.

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 full responsibility for behavioral disclosure. It reveals that the report separates evidence from estimates, but it does not say whether the tool persists anything, whether it can be run multiple times, what side effects occur, or what the output looks like. This is especially thin given the save_as_artifact parameter exists but is not mentioned.

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 core action comes first and the distinguishing behavior follows immediately. 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?

With no annotations, no output schema, and 0% parameter description coverage, this one-sentence description is not enough for an agent to confidently invoke the tool. The agent knows the report's purpose but not its side effects, return value, prerequisites, or how save_as_artifact affects behavior.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It does not mention session_id or save_as_artifact at all, and it adds no meaning beyond the bare parameter names and the default value in 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 clear verb-resource pair ('Generate the closing report') and adds the distinctive behavior of 'separating observed evidence from estimates,' which differentiates it from sibling reporting tools like generate_diagnostic, generate_assessment, and save_benchmark_report. An agent can understand what this tool does without needing 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?

The word 'closing' implies the tool should be used at the end of a session, but the description gives no explicit when-to-use or when-not-to-use guidance and does not name alternatives. Usage context is only implied, not 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?

With no annotations provided, the description carries full behavioral burden. It only discloses that it returns a blueprint, but does not explain whether it has side effects, requires a particular session state, or what the blueprint contains beyond a label. This is insufficient for a tool with no safety 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 description is a single, concise sentence that is front-loaded with the core action and resource. It contains no filler or redundancy, making it efficient for the agent 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?

Given that there is no output schema, no annotations, and minimal parameter documentation, the description should compensate with more detail about what a blueprent includes, how it relates to the session, and any relevant constraints. The current text leaves critical gaps for an agent 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?

Schema description coverage is 0%, and the description provides no additional meaning for the two parameters (session_id and node_id). Even though the schema has titles and one default, the description does not explain their roles, formats, or relationships, leaving the agent to guess.

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 verb 'Return' and the resource 'transfer-probe blueprint', specifying the four blueprint types (near / variation / far / integrated). This is specific enough to distinguish it from most sibling tools, though it does not explicitly differentiate itself from other generation tools like generate_assessment or generate_diagnostic.

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

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

There is no guidance on when to use this tool versus alternatives. It does not state prerequisites (e.g., a valid session) or indicate that node_id is optional. No mention of prefering this over record_transfer_result or other transfer-related tools is provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Fetch' implies a read-only operation, but the description does not mention return behavior, error cases, side effects, or the fact that a default of include_content=true exists in the schema. The behavioral exposure is minimal.

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 concise and front-loaded, with no wasted words. However, it is so sparse that it omits useful behavioral and parameter context, so it sacrifices completeness for brevity.

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

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

For a tool with no annotations, no output schema, and two parameters with zero schema description coverage, the description is too thin. An agent would not know what the response looks like, what include_content controls, or how this fetch differs from list_artifacts beyond the id criterion.

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

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

Schema description coverage is 0%, and the description does not compensate. It adds no meaning beyond the parameter titles: artifact_id and include_content. In particular, it does not clarify what artifact_id should look like or what effect setting include_content to false has on the returned artifact.

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 ('Fetch') and resource ('an artefact') with an explicit retrieval criterion ('by id'). It clearly distinguishes this tool from siblings like save_artifact and list_artifacts, so an agent can identify its core function immediately.

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

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

No guidance is given about when to use this tool versus alternatives such as list_artifacts or get_evidence. 'By id' implies a use case, but the description never states when this is the right choice, when it is not, or what prerequisites exist.

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 of disclosing behavior. 'Return' and 'past' imply a non-mutating read operation, and the mention of raw answers is useful, but the description does not explicitly state that the tool has no side effects or disclose any other behavioral details such as ordering or scope constraints.

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

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

The description is a single front-loaded sentence with no filler. Both 'past assessment results' and 'including the raw answer for audit' earn their place, conveying the core purpose and a distinctive feature concisely.

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 three parameters, no annotations, and no output schema, so the description must carry significant context. It does not explain parameter behavior, result structure, filtering semantics, or the meaning of limit/defaults, leaving an agent under-equipped to invoke it correctly in varied situations.

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

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

Schema description coverage is 0%, and the description does not compensate: it never mentions session_id, limit, or node_id. An agent cannot determine that session_id is the required scope, that limit controls the number of returned results, or that node_id filters by node.

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 ('Return') and a specific resource ('past assessment results'), and adds a distinctive detail ('including the raw answer for audit') that separates it from current-state or diagnostic getters. It is clear and unlikely to be confused with siblings, though it does not explicitly differentiate itself from 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 no guidance on when to use this tool versus alternatives, nor does it state any exclusions or prerequisites. The phrase 'for audit' hints at a use case, but there is no explicit routing based on need or scenario.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. The verb 'List' signals a read-only operation, but the description does not explicitly state that nothing is executed or modified, nor does it describe the output shape (names only versus detailed descriptions).

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 front-loads the verb and object with no filler or repetition. 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 zero-argument discovery tool, the description is largely sufficient: an agent knows what to expect and that no input is required. The lack of an output schema and the absence of detail about the exact form of the action list are minor gaps for such a simple 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?

The tool takes zero parameters, so the schema fully covers the invocation surface; the baseline is 4. The description adds context about the content of the result but lacks no argument-level information.

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 clear verb ('List') and names the resource ('concrete teaching actions the host agent may execute'), so an agent knows what the tool returns. It does not explicitly contrast itself with siblings such as get_available_strategies or get_plugin_info, but the object is specific enough to separate it from most other teaching 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?

No guidance is given about when to call this tool versus alternatives like get_available_strategies or get_plugin_info. The intended use is only implied by the tool name and the generic phrasing 'may execute.'

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 present, so the description carries the full behavioral burden. It only restates that the tool lists strategies and adds the policy-engine scope; it does not disclose return format, whether the list is dynamic, or any other operational details.

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 with no filler. It is appropriately sized for a zero-parameter list operation and every word contributes to the meaning.

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

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

For a very simple zero-parameter tool, the description is minimally sufficient to select and invoke it. However, without an output schema it omits the return structure, and it gives no relationship to sibling policy tools, leaving some gaps.

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 there is nothing for the description to clarify. The baseline for a 0-parameter tool is 4, and nothing in the description detracts from that.

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 ('List'), resource ('pedagogical strategies'), and scope ('available to the policy engine'), making the tool's purpose clear. It does not explicitly contrast it with similar siblings like get_available_actions, so it misses the full sibling-differentiation bar.

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

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

There is no when-to-use guidance, no mention of alternatives, and no exclusion criteria. With many sibling tools around policy evaluation, an agent is left to infer when this tool is the right choice.

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 full burden. It says 'Read' implying a non-destructive operation, but doesn't disclose response format, pagination behavior, or whether the log is ordered. The 'limit' parameter suggests pagination but that's not explained. Minimal transparency beyond the obvious read-only nature.

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

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

A single, short sentence with no fluff. It is front-loaded with the core action. However, it is too sparse, missing critical details, but for what it includes, it is concise and efficient.

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 two parameters, no output schema, and no annotations, making it moderately simple but not trivial. The description omits return format, ordering, limit bounds, and usage context. An agent knows it reads decisions but not what to expect from the response or how to use the parameters correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'for a session,' which hints that session_id identifies the session, but it does not explain the meaning of 'limit' or the format of session_id. No added value beyond what the parameter names suggest.

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 ('Read') and resource ('pedagogical decision history for a session'). Clearly distinguishes from siblings like get_assessment_history and get_session_info by specifying 'decision history,' though it doesn't name an alternative explicitly. It is specific enough for an agent to understand the 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 no guidance on when to use this tool versus alternatives. For example, it doesn't clarify whether this should be used after commit_pedagogical_decision or how it relates to get_session_info. The tool name implies a read operation, but context for when to invoke it is absent.

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 behavior on its own. It adds some context by saying the result is 'stored' and that all attempts are returned, which implies a read operation, but it does not state side effects, error behavior, or whether an existing session is required.

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 with no filler, and the most important information ('stored diagnostic summary plus every diagnostic attempt') comes first. It is appropriately sized for a simple 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?

The description states what is returned (summary plus all attempts), which is helpful because there is no output schema. However, it omits any prerequisite or error context and provides no output structure, so an agent has only a minimal picture for a tool with no annotations.

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 has one parameter (session_id) with 0% description coverage, and the description does not mention session_id at all. The parameter's role is inferable from its name, but the description adds no meaning about how the session is used or what makes a valid session.

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 ('Return') and names a precise resource: the stored diagnostic summary plus every diagnostic attempt. It is clear about what is being retrieved, though it doesn't explicitly contrast with sibling diagnostic tools such as generate_diagnostic or get_assessment_history.

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

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

No guidance is given about when to call this tool instead of sibling getters like get_review_state or get_assessment_history. The word 'stored' hints that it should be used after a diagnostic has been saved, but this is not made explicit and no exclusions are provided.

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

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

With no annotations provided, the description carries the full behavioral burden. It goes beyond a simple 'list' by disclosing that a non-empty result does not block new learning globally and that blocking is a per-node Policy + State Guard decision. This is genuinely useful behavior context, though it does not describe return format or side effects.

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 concise, front-loaded with the purpose, and every sentence earns its place. The behavioral note is packed with valuable information without 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?

The tool is relatively simple, but with no annotations, no output schema, and zero schema description coverage, the description does not fully equip an agent. It lacks parameter semantics and any explicit differentiation from closely related review-state tools, leaving some context gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It provides no explanation of learner_id, limit, or session_id. The parameter names are partially self-explanatory, but no additional meaning is added beyond what the schema already shows.

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: 'List due review items.' It clearly identifies what the tool returnscd. It does not explicitly differentiate from siblings like get_review_state or get_mastery_status, but the name and first sentence make the core 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?

The description implies use when review items are dueressed, and the second sentence provides contextual guidance about interpreting non-empty results. However, it does not explicitly state when to prefer this over alternatives such as get_review_state or recalculate_review_schedule, nor does it list 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Return' and does not state whether the operation is read-only, how node_id affects results, what happens when no evidence exists, or any limits on the returned 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?

The description is a single front-loaded sentence with no filler. Every word contributes meaning by naming the resource components and scope.

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?

While the tool is simple, the description leaves important gaps: node_id is undocumented, the return shape is only hinted at, and no usage constraints are given. For a tool with no annotations and no output schema, this is not fully complete for an agent deciding how to invoke 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 description coverage is 0%, and the description only adds general 'session' context. It does not explain the optional node_id parameter, its relationship to session_id, or the meaning of null defaults, so the agent cannot infer parameter semantics beyond their 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 clearly identifies the resource ('grounding report metadata, claims and sources') and the scope ('for a session') with a specific retrieval verb, 'Return.' It does not explicitly contrast with sibling getters, but the unique concept of 'grounding report' distinguishes it from tools like get_session_info or get_knowledge_nodes.

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 sibling retrieval tools such as get_teaching_context, get_knowledge_nodes, or get_review_state. The only implied context is that it is session-related, but no explicit when/when-not guidance or alternatives are provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'List' (implying read-only) and enumerates edge types; it does not mention session scoping, return structure, or pagination behavior.

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 that front-loads the action and resource, with the edge taxonomy in parentheses. No filler or redundant 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?

For a one-parameter list call this is close to adequate: the verb and edge types tell the agent what will happen. However, with no output schema or annotations, it does not explain session scoping or return shape, so some inference remains.

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

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

Schema description coverage is 0% and the description never mentions session_id. The single parameter's name and schema title are self-explanatory, so the gap is minor, but the description adds no semantic value beyond the structured 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 opens with the imperative 'List' and identifies the resource 'knowledge edges' with four concrete edge types. This clearly distinguishes it from siblings like save_knowledge_edges (write operation) and get_knowledge_nodes (different resource).

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 condition for when to use this tool or when to prefer alternatives such as save_knowledge_edges or validate_knowledge_dag. The agent must infer usage entirely from the tool name and sibling list.

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 present, so the description must carry the behavioral burden. It only implies a read operation, but says nothing about session_id validity, error behavior, pagination, or return structure, adding little beyond what the tool name already suggests.

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 short sentence, front-loaded with the core action and optional filter, with no filler. It is concise without being vague, though it omits necessary detail.

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

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

For a tool with a required session_id, no annotations, and no output schema, this is too sparse. The agent is not told what session_id refers to, what a knowledge node looks like, or what a 'teaching unit' should be in the filter.

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 phrase 'filtered by teaching unit' adds meaning to the unit_tag parameter beyond its title. However, session_id—the only required parameter—is never explained, and with 0% schema description coverage, the agent cannot infer what value to supply.

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 clear verb ('List') and resource ('knowledge nodes'), and 'optionally filtered by teaching unit' defines scope. It distinguishes itself from sibling writer tools like save_knowledge_nodes by being a read/list operation, though it doesn't name a specific 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 guidance on when to choose this over get_knowledge_edges, get_review_state, or other sibling tools. The optional-filter phrase gives a usage condition for unit_tag but not a decision rule for tool selection, so an agent must infer context from the name.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. The verb 'Return' signals a read-only action, which is useful, but the description does not go beyond that to mention response structure, errors, session validity, or any other behavioral context. It is adequate for a simple getter, but 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 description is a single, front-loaded sentence with no filler. It conveys the core purpose immediately and every word contributes 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 low complexity of a one-parameter getter, the description is mostly complete: it identifies the session and names the three kinds of returned information. However, without an output schema or annotations, a bit more detail about the return shape or potential failure conditions would make it fully self-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 0%, and the description does not explicitly explain the session_id parameter or its expected format/meaning. It only indirectly references it through 'session's'. For a single required parameter this is somewhat recoverable, but the description should at least tie session_id to the session being queried.

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 action ('Return') on a specific resource ('the session's active learning mode, overrides and preferences'). This is distinct from sibling tools like set_learning_configuration, which would modify rather than read.

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?

'Return' implies this is the read/get operation for learning configuration, but the description does not explicitly state when to use it over siblings like get_session_info or set_learning_configuration. The intended context is clear but no exclusions or alternative routing are provided.

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

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

No annotations are provided, so the description carries the full behavioral burden. It communicates a read-only retrieval action and clarifies the recency and session scoping, but it does not state what happens when no learning goal has been saved or whether an empty result 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?

One tight sentence with no filler. The action and object are front-loaded, and the recency qualifier is placed immediately where it matters.

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 simple shape and single parameter, the description is mostly adequate: it names the returned resource and its scope. However, with no output schema and no annotations, it would be more complete if it clarified no-goal behavior or the return form.

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

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

The input schema only provides 'Session Id' with no description, and schema coverage is 0%. The description's 'for a session' maps session_id to the session whose most recent goal is fetched, adding essential meaning beyond the schema. It is sufficient for a single required string parameter.

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: 'Return the most recently saved learning goal for a session.' The phrase 'most recently saved' adds precise scope and distinguishes this getter from the sibling save_learning_goal; an agent can tell what it 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?

The description gives clear context: use this when you need the latest saved learning goal for a given session. It does not explicitly name alternatives or exclusion criteria, but for a simple retrieval tool no competing sibling is obvious, so the implicit usage guidance 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?

No annotations are provided, so the description carries the full burden. It only says 'Return' and lists metric names; it does not disclose whether this is a pure read, whether the session must be completed, whether metrics are computed on demand, or what the response shape is. This is minimal behavioral context.

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

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

The description is two sentences with no filler. The main action is front-loaded, and the list of covered indicators is compact and helpful.

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 no output schema and no annotations, so the description should provide more context about return structure, parameter semantics, and usage conditions. An agent can guess the purpose but not confidently decide when to call this over a sibling or what to expect in the response.

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

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

Schema description coverage is 0%, and the description never mentions session_id or explains its meaning or required format. The only parameter is self-evident from its name, but the description adds no value 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 states a specific verb ('Return') and resource ('section 26.1 learning-outcome indicators') and enumerates the included indicator categories, which helps distinguish it from siblings like get_mastery_status or get_assessment_history. It does not explicitly name a sibling, so it is clear but not fully differentiated.

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 or when-not-to-use guidance. The description implies the tool is for retrieving learning-outcome indicators, but it does not mention prerequisites, what session state is required, or how it differs from related tools such as get_mastery_status or get_assessment_history.

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?

There are no annotations, so the description carries the full burden. It discloses that the result is server-estimated and implies a read-only action, but does not mention return shape, whether it reports per-node or whole-session knowledge, session validity requirements, or any side effects.

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 conveys the core operation with no filler. It is concise but somewhat under-specified, which keeps it below 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?

For a tool with no output schema and no annotations, the description leaves important context missing: what a 'knowledge state' contains, how the optional node_id affects results, and how this relates to the review/scheduling/assessment siblings. An agent could call it with the right session_id but cannot anticipate the response.

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

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

Schema description coverage is 0% and the description mentions neither session_id nor node_id. It fails to explain that session_id identifies the learner session and node_id optionally scopes the query to a specific node, with null likely meaning the whole knowledge state.

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 ('Return') and identifies the resource as 'server-estimated learner knowledge state,' making the operation's intent clear. However, it doesn't distinguish itself from sibling read tools like get_review_state or get_knowledge_nodes, so it loses the top score.

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

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

No guidance is provided about when to call this tool versus alternatives such as get_review_state or get_learning_metrics, nor any conditions or exclusions. The agent must infer usage from the tool name and sibling list alone.

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?

Even with no annotations, the description discloses a key behavioral trait: the runtime never reads or writes local vault files. It also labels the result as 'static,' indicating no live state. It stops short of describing the output format, so it does not earn 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?

Two sentences, front-loaded with the core action and a clarifying limitation, with no filler or redundant content.

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 parameterless read-only retrieval call, the description says what it returns and the key safety restriction. A fuller description of the specification's contents would improve completeness, but nothing needed to invoke the tool correctly is missing.

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

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

The tool has zero parameters, so the description cannot add parameter-level detail beyond the schema. Per the baseline for zero-parameter tools, this 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?

The description opens with the verb 'Return' and names a specific resource, 'static Obsidian vault specification.' The 'static' qualifier and the explicit 'runtime never reads or writes local vault files' clearly separate it from sibling read/write tools.

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

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

The 'Specification only' clause sets an explicit scope: this tool is for obtaining the static spec, not live vault state. It does not name alternative tools or provide a when-not condition, but the zero-parameter read-only nature makes the intended use 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. The verb 'Report' strongly suggests a read-only inspection, and the enumerated coverage adds useful context. However, it does not disclose whether the report reflects only current configuration, whether any hidden state is consulted, or what the exact output shape is.

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. The core purpose is front-loaded in the first sentence, and the second efficiently scopes the report's coverage. 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 zero-parameter, no-output-schema reporting tool, the description provides enough context for an agent to know when the tool is relevant and what broad areas it covers. It could include more detail about the report's format or how to interpret discrepancies, but invocation itself is unambiguous.

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)Skip schema coverage is irrelevant because there are no inputs to explain. The description adds value by clarifying the domain of the returned information, listing the six seam categories, so an agent understands what the report contains without needing parameters.

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 ('Report') and resource ('which implementation backs each pluggable seam'), and then lists the covered seam categories. It is clear about what the tool does, though it distinguishes itself from siblings only implicitly through the unique 'pluggable seam' concept rather than naming alternatives.

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 should be used when an agent needs to know which implementation is behind a pluggable seam, especially across the listed areas. However, it does not explicitly state when to use this tool versus related diagnostic tools like get_session_info or get_learning_configuration, and gives no 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 available, the description carries the behavioral disclosure burden. The verb 'Return' implies a read-only operation and the phrase 'current retrievability and due status' describes the response, but no side effects, authentication needs, or edge-case behavior are disclosed.

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 with no filler or repetition. Every word contributes to the agent's understanding of the operation's 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?

The definition is too sparse for an agent to select confidently among review-related siblings because it never says how get_review_state differs from get_due_reviews. It also omits the effect of the optional node_id parameter and any notion of learner scoping beyond the schema's required field.

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

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

Schema description coverage is 0% and the description adds no meaning to the parameters; learner_id and node_id are neither explained nor contextualized. The parameter names and titles are self-evident, but the description fails to compensate for the lack of schema documentation.

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 ('Return review items') and names the key output fields ('current retrievability and due status'), so the core purpose is clear. It does not explicitly distinguish itself from the sibling get_due_reviews, so it misses the top score.

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

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

No guidance is given about when to call get_review_state versus the closely related get_due_reviews, submit_review, or recalculate_review_schedule. The agent must infer the intended use from the name alone.

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 disclosing behavior. 'Return' implies a read-only operation, and the list of returned data adds transparency. However, it doesn't explicitly state there are no side effects, what happens for an invalid session_id, or whether the data is a snapshot. For a simple get tool this is adequate, though 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 description is a single, compact sentence that clearly front-loads the verb and immediately follows with the key outputs. Every word contributes; there is no filler or redundant 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?

For a simple read-only tool with one parameter, the description covers the main purpose and listed outputs. However, with no output schema, the agent is not told the return format or how errors are signaled (e.g., missing session). This is a moderate gap for an agent deciding whether to call the tool and how to 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?

Schema description coverage is 0%, so the description must compensate for the sole parameter, session_id. It does not mention the parameter at all, leaving the agent to infer its meaning solely from the name 'Session Id' in the schema. The description adds no semantic value beyond the schema field name.

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 ('Return') and lists concrete resources (session state, latest goal, node count, next lifecycle step). This clearly distinguishes it from sibling tools like get_learning_goal or get_review_state, making the tool's purpose immediately identifiable.

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

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

No guidance is provided on when to use this tool versus alternatives. The description only states what it does, without indicating when it is appropriate (e.g., for a high-level session overview) or when to prefer other tools like get_mastery_status or get_learning_goal. Given the large sibling list, this is a clear 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?

No annotations are provided, so the description carries the full disclosure burden. It only says the tool returns context; it doesn't state whether the call is read-only, what 'full teaching context' includes, how node_id affects the result, or what happens with invalid session_id.

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

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

A single sentence that is front-loaded with the action and the resource. The phrase 'to reduce round trips' is slightly redundant with 'in one call', but the description is compact and readable.

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

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

For a tool promising 'full teaching context', the description doesn't specify what that context contains, how node_id scopes it, or what the response looks like. With no output schema or annotations, an agent cannot predict the result shape or distinguish this from other getters, making the definition 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 description coverage is 0%, and the description adds no meaning for session_id or node_id. The parameter names hint that session_id selects a session and node_id may scope to a node, but their effects on the returned context are unexplained, so the description does not compensate for the schema gap.

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

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

States a clear action ('Return') and resource ('full teaching context'), and adds the aggregation benefit of reducing round trips. The term 'teaching context' is not defined, and the description doesn't differentiate it from narrower sibling getters like get_session_info, but the core purpose is recognizable.

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?

Provides no explicit when-to-use guidance or comparison with sibling tools. The phrase 'reduce round trips' implies a bulk-read use case, but it doesn't state when to prefer this tool over alternatives like get_session_info or get_review_state, nor 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 by disclosing that this is a static, side-effect-free retrieval and explicitly denying runtime generation/reading. It does not describe return format or errors, but the core behavioral profile is clear.

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 no wasted words. The primary purpose is front-loaded, and the clarifying sentence earns its place by preventing a common misinterpretation.

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 retrieval tool, this is sufficiently complete: it says what is returned and what is not, and there is no input schema or output schema requiring extra explanation. Minor gaps like return format are acceptable given the tool's simplicity.

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 no parameter documentation is needed. The description adds no parameter meaning, but none is required.

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 ('Return') and a distinctive resource ('static web-component specification'). The second sentence explicitly distinguishes it from runtime behavior, so an agent can tell it apart from front-end/runtime-related siblings.

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?

Implies usage through the 'Specification only' clarification and the statement that the runtime never generates HTML or reads front-end sources. However, it does not explicitly name alternatives or 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?

There are no annotations, so the description carries the full burden of disclosing behavior. 'List' implies a read operation, but the description does not mention return format, ordering, pagination, error handling, or side effects.

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 with no filler. The core action, scope, and optional filter are front-loaded and every word contributes to the meaning.

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

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

For a simple list operation with only two parameters, the description is minimally viable. Still, without an output schema or annotations, it would benefit from noting what the response contains or whether results are paginated.

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 description adds meaning by stating that the tool is scoped to a session and that filtering by type is optional. It does not name the artifact_type parameter explicitly or enumerate possible type values, but it does clarify the role of the optional parameter.

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 'List' with a clear resource ('artifacts for a session') and an optional filter. It is naturally distinguishable from sibling tools like get_artifact (singular retrieval) and save_artifact (creation).

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 the tool: when listing artifacts belonging to a session, optionally restricted by type. However, it gives no explicit guidance about when not to use it or which alternative to choose for single-artifact retrieval.

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 of behavioral disclosure. It says retrievability is recomputed but does not state whether this mutates stored schedules, whether it is idempotent, whether it affects due dates, or what the return value is. The word 'recompute' hints at a write-like operation but leaves the impact unclear.

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 concise sentence that front-loads the core action. It earns its place with no filler, though it could add a brief note about the 'now' parameter without becoming verbose.

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

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

For a tool with no annotations, no output schema, and a 0% schema description coverage, the description is too thin. An agent cannot tell whether this is a safe read-only calculation or a mutating operation, what the 'now' parameter does, or what the result means. Sibling tools like schedule_review and get_due_reviews suggest a scheduling workflow, but the description does not place this tool within 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 description coverage is 0%, so the description must compensate. It explains the learner_id parameter implicitly by saying 'of a learner', but the 'now' parameter is entirely unexplained in both the schema and description. The description adds some meaning for learner_id but not for now, so it only partially compensates.

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 ('Recompute') and resource ('retrievability for every review item of a learner'), which clearly identifies the operation. It does not explicitly distinguish it from siblings like schedule_review or get_due_reviews, but the recompute-all semantics are reasonably distinct.

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

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

No guidance is given on when to call this tool versus alternatives such as schedule_review, get_due_reviews, or submit_review. The description implies a batch recomputation use case but does not state prerequisites, side effects, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that a reflection is stored, but does not reveal whether the operation overwrites, appends, requires an existing session, or returns anything.

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 sentence with no wasted words, which is concise in the strict sense. However, it sacrifices substance: it conveys only a general purpose and omits details that an agent needs to invoke the tool correctly.

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 four parameters, zero annotation coverage, no output schema, and a sibling tool named save_artifact, this one-sentence description is materially incomplete. The agent is left guessing about required context, parameter semantics, and expected behavior.

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

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

Schema description coverage is 0%, and the description does not explain the meaning or format of session_id, reflection, node_id, or request_id. Even the 'reflection' parameter, which the description vaguely references, is not given a type or structure.

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 ('store') and resource ('learner reflection'), making the core purpose clear. However, it does not differentiate from the closely related sibling save_artifact, and the term 'artifact' is left undefined.

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

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

No guidance is given about when to use this tool versus alternatives like save_artifact or list_artifacts. The description does not mention any conditions, prerequisites, 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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It communicates the core intent of persisting a conflict rather than auto-selecting, but it says nothing about side effects, persistence semantics, idempotency, return behavior, or whether the operation overwrites existing conflict records.

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 sentence with no filler, and the important distinction 'instead of silently choosing one' is front-loaded. Its brevity is efficient, though it leaves important behavioral and parameter details unstated.

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 tool with no output schema and no annotations, the description is incomplete. An agent cannot determine the expected format of conflicting_sources, the meaning of uncertainty, or what a successful call returns, making reliable invocation difficult.

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

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

Schema description coverage is 0%, and the description does not explain any of the three parameters. 'claim_id' and 'conflicting_sources' are required but not described, and 'conflicting_sources' lacks a type in the schema, so an agent has no guidance on how to format the 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?

The description states a clear action and object: record conflicting sources. The contrast 'instead of silently choosing one' helps differentiate it from resolution-oriented tools like validate_claim or resolve_misconception, though no sibling is named 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 'instead of silently choosing one' implies the tool should be used when multiple sources disagree and the system should not pick a winner. However, it does not explicitly state when to use this tool versus alternatives or mention any 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says the tool records a result, which implies a write/persist operation, but it does not disclose whether the record overwrites existing data, whether it is idempotent, what side effects occur, or what the response looks like. This is a meaningful gap for a data-recording 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 a single sentence with no filler or repetition. The main action is front-loaded, and the transfer_type clarification is placed efficiently in a second clause. While it is short, conciseness itself is excellent; every word contributes meaning.

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

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

For an 8-parameter tool with no output schema and no annotations, this description is under-specified. It does not explain the relationship between transfer probes and recording results, what score values are valid, how optional fields like request_id or task_context are used, or what happens after recording. An agent would need to infer workflow context from sibling names like generate_transfer_probe and get_review_state.

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

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

Schema description coverage is 0%, so the description must compensate, but it only adds meaning to one parameter: transfer_type is clarified as 'near/variation/far/integrated.' The other seven parameters—learner_id, node_id, score, result, request_id, session_id, and task_context—receive no semantic elaboration beyond their property names, and the meaning of score is not explained.

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 clear verb-resource relationship: 'Record a transfer probe result.' This unambiguously identifies the action and object, and the mention of transfer_type values helps scope the tool. However, it does not explicitly distinguish itself from siblings like generate_transfer_probe or save_diagnostic_result, 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?

No usage guidance is provided. The description does not state when to call this tool versus alternatives, nor does it mention prerequisites such as having previously generated a transfer probe or having a learner_id and node_id available. The verb 'record' implies a post-generation workflow, but this is not made 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?

With no annotations present, the description carries the full burden and does disclose a state change and a cache-refresh side effect. However, it does not mention idempotency, permission requirements, or what happens if the misconception was already resolved, so the disclosure is only partial.

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 concise sentence that front-loads the primary action and then states the key side effect. Every word adds meaning and 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?

For a simple mutation tool, the description captures the core operation, but it omits usage context, parameter semantics, and response behavior. Since there is no output schema and no annotations, these gaps matter more and make the definition merely adequate.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It does not address misconception_id or session_id at all; while the names are somewhat self-explanatory, the role of session_id, default behavior, and interaction between the two parameters are left unexplained.

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 ('Mark... resolved') and resource ('misconception'), making the operation unambiguous. No sibling tool performs resolution of a misconception, so it is readily distinguishable 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?

No guidance is provided for when to use this tool versus alternatives, nor are prerequisites or expected call order mentioned. The description implies resolving an existing misconception but does not state conditions 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the core mutation but does not mention side effects, persistence, reversibility, prerequisites, or what happens to the session state after the rollback.

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 with no filler. Every word contributes to the core meaning, making it highly concise even though other dimensions suffer from the brevity.

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 that this is a stateful mutation with no annotations, no output schema, and four undocumented parameters, a one-sentence description is insufficient. An agent cannot determine how the rollback affects learning progress, review state, or whether reason/request_id are required in specific flows.

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

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

Schema description coverage is 0%, so the description needs to compensate. It partially clarifies target_node_id by implying it should be an earlier node, but it does not explain session_id, reason, or request_id, nor their roles or optionality.

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 ('Move'), a clear resource ('teaching focus'), and a precise direction ('back to an earlier node'). This makes the tool's purpose unambiguous and distinguishes it from siblings like advance_unit or start_unit.

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

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

No guidance is given about when rollback_unit should be used versus alternatives such as advance_unit, check_advance_unit, or start_unit. The word 'back' implies a reverse-navigation use case, but this is inference rather than explicit direction.

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 only discloses that an artifact is persisted. It does not describe versioning or overwrite behavior, the role of learner_id/session_id, side effects, or whether content must be supplied inline versus via path_or_uri.

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 tightly worded sentence with no filler, and the useful examples are front-loaded. It is easy to parse, though brevity comes at the cost of necessary detail.

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

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

This is an 8-parameter write tool with 2 required fields, no annotations, no output schema, and zero schema description coverage. A one-line description is not enough for an agent to reliably determine required values, parameter formats, or behavioral semantics, so the definition is materially 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 description coverage is 0%, and the description only minimally compensates by giving example values for artifact_type. The required learner_id, content, version, metadata, path_or_uri, request_id, and session_id are left unexplained, leaving significant ambiguity about how the artifact should actually be provided.

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, 'Save a learning artefact', and gives concrete examples like HTML, Markdown, chart, code, and report. This communicates the core operation clearly and distinguishes it from sibling save_* tools. It does not clarify whether saving creates a new artifact or updates/versions an existing one, but the basic purpose is unambiguous.

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

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

There is no guidance on when to use this tool instead of list_artifacts, get_artifact, or other save_* siblings, and no exclusions or prerequisites are mentioned. The only usage signal is the generic operation stated in the description.

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

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. The verb 'save' implies mutation, but it does not state whether the operation is idempotent, overwrites existing claims, requires specific permissions, or handles conflicting sources. No output schema is present to clarify what the agent should expect.

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 sentence with no fluff or redundancy. It is appropriately brief, though the brevity veers into under-specification rather than efficient completeness.

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 7 parameters, no annotations, and no output schema, this description is severely under-specified. It fails to explain what a 'benchmark claim' is, how it integrates with sessions, what conflicting_sources means, or how to construct a valid claim. An agent would struggle to use this tool correctly without external knowledge.

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 0% schema description coverage and 7 parameters, the description must compensate but only hints at source_id and confidence via 'source and confidence'. Other parameters like knowledge_scope, conflicting_sources, and request_id remain completely unexplained, leaving the agent to guess their semantics.

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 clear verb ('Save') and identifies the resource ('one structured knowledge claim'), and mentions 'source and confidence' which maps to two key parameters. It differentiates from siblings like save_knowledge_nodes (which likely saves multiple nodes) and save_benchmark_report (which saves a report) by emphasizing 'one claim', though it does not explicitly name alternatives.

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 provides no guidance on when to use this tool versus alternatives such as save_knowledge_nodes, save_benchmark_report, or record_source_conflict. There is no mention of prerequisites, conditions for selection, or scenarios where this tool is inappropriate.

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 disclosure burden. It reveals side effects: full text is stored as an artifact, structured claims are stored in benchmark_claims, and diagnostics are unlocked. It does not cover overwrite behavior, permissions, or whether calling it repeatedly is idempotent.

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 the main action front-loaded and no filler. Every sentence adds information about storage or downstream effects.

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 4-parameter tool with no output schema and no annotations, the description omits required parameter semantics, return behavior, and what 'unlock diagnostics' concretely means. It tells where data is written but not enough for confident 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 0% and the description only partially compensates: 'report_text' is implicitly tied to 'the full text,' but session_id, request_id, and source_refs receive no explanation. An agent would have to infer the meaning of source_refs and why session_id is required.

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?

Description states a specific action—save the agent's domain grounding report—and a notable effect, unlocking diagnostics. It also tells where data lands (artifact type agent_benchmark_report, benchmark_claims), which helps distinguish it from generic save_artifact or save_benchmark_claim, though it never names a sibling.

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

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

No explicit when-to-use or when-not-to-use guidance is given. The only implied guidance is 'when you have a domain grounding report to save,' and no alternative is named for saving structured benchmark claims separately.

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 burden of disclosure. It does reveal two important behaviors: persisting the diagnostic summary and marking the diagnostic phase complete. However, it does not disclose idempotency, overwrite behavior, whether it requires a prior generated result, or what happens on failure, so transparency is only partial.

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 sentence with no filler and names both the core action and the side effect. It is concise, though brevity comes at the cost of missing parameter and usage detail.

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

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

For a state-changing tool with no annotations and no output schema, this description is too thin. It does not explain the expected return value, error conditions, whether the operation is idempotent, or how it relates to submit_diagnostic and complete_session. The context provided is enough only for a very basic understanding.

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

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

Schema description coverage is 0%, so the description must compensate but barely does. The phrase 'diagnostic summary' loosely maps to the 'result' parameter, but session_id and the nullable request_id are never explained. The description adds minimal meaning beyond the parameter names themselves.

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 ('Persist') and resource ('the diagnostic summary'), and adds a distinct outcome ('mark the diagnostic phase complete'). This makes it clear the tool is a write/state-transition operation and separates it from retrieval tools like get_diagnostic_result, though it does not explicitly contrast with submit_diagnostic.

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 this is used at the end of a diagnostic workflow but does not state when it should be used relative to siblings like submit_diagnostic, generate_diagnostic, or get_diagnostic_result. There is no mention of prerequisites, ordering, or alternatives, leaving the agent to infer usage from the phase-complete wording.

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. It does disclose a meaningful trait: the DAG is validated first and invalid DAGs are rejected. However, it omits mutation semantics (overwrite vs merge), success/error behavior, and session requirements, leaving the persistence behavior only partly transparent.

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 tight sentences with no filler, and the main action is front-loaded. It earns its brevity, though it is slightly under-specified for a persistence tool with no schema-level parameter descriptions.

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 no output schema, no annotations, and 0% schema description coverage, the description is incomplete. It does not explain what an edge should look like, how session_id is used, what request_id is for, or how this relates to validate_knowledge_dag and save_knowledge_nodes. An agent would have to infer too much to call it reliably.

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

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

Schema description coverage is 0%, so the description must compensate. It adds only that 'edges' are knowledge edges forming a DAG, but does not define the edge shape, required fields, or the semantics of session_id and request_id. This is minimal compensation for an otherwise undocumented parameter set.

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 ('Persist') and resource ('knowledge edges'), and adds a distinguishing detail by noting the DAG is validated first. It is clear enough to separate from get_knowledge_edges and validate_knowledge_dag, though it does not explicitly contrast with save_knowledge_nodes.

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

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

No guidance is given about when to use this tool versus save_knowledge_nodes, validate_knowledge_dag, or get_knowledge_edges. The only usage signal is the action itself, with no scenarios, exclusions, or alternatives.

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

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

No annotations are provided, so the description must carry the full burden. It discloses a persistence action and adds a cryptic constraint about unit_tag and unit_concept_budget, but does not explain what those mean, what happens on success or failure, or any side effects. The constraint is a partial behavioral disclosure but lacks essential context.

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

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

The description is extremely short, but this is under-specification rather than conciseness. It front-loads the purpose but the single constraint sentence is cryptic and unhelpful. There is no wasted wording, but the description fails to include essential information, so it does not earn a high score for 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?

For a mutation tool with no output schema and free-form node objects, the description is drastically incomplete. An agent has no idea what a valid node looks like, what unit_tag and unit_concept_budget refer to, or what the tool returns. It lacks all necessary context to invoke it correctly.

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

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

Schema description coverage is 0%. The description does not explain the parameters at all. The schema defines nodes as an array of objects with additionalProperties true, so the structure is entirely opaque. The description adds no meaning to session_id, request_id, or the nodes format.

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 clear verb and resource: 'Persist knowledge nodes'. It distinguishes from read operations like get_knowledge_nodes and from save_knowledge_edges by naming the specific resource. However, it does not explicitly contrast with siblings or elaborate on scope beyond the resource name.

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

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

There is no guidance on when to use this tool versus alternatives. It does not mention when to prefer save_knowledge_nodes over save_knowledge_edges, nor any prerequisites or contextual triggers. The description provides no usage context whatsoever.

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 of behavioral disclosure, but it only says 'Persist.' It does not mention whether an existing goal is overwritten, whether the session must already exist, what happens when nullable fields are omitted, or whether there are side effects. The description is not misleading, just under-specified.

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 short sentenceholistic and front-loaded, which is efficient IA-wise. However, it is concise at the expense of useful context, and the unexplained 'lifecycle Stage 1' phrasing adds jargon rather than clarity for a tool with 11 parameters.

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 an 11-parameter persistence tool with no annotations, no output schema, and no parameter descriptions, this definition is incomplete. The agent cannot determine what Stage 1 means, what success/failure looks like, or how this tool relates to get_learning_goal and set_learning_configuration.

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

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

Schema description coverage is 0%, so the description needed to compensate, but it only references 'goal' and 'constraints' generically. It does not clarify time_budget, target_depth, request_id, assessment_requirements, or how the many nullable fields interact. The parameter names are self-explanatory to some degree, but the description adds little semantic 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?

The description uses a specific verb ('Persist') and a concrete resource ('the learning goal and its constraints'), and the lifecycle reference helps set it apart from the read-only sibling get_learning_goal. It is clear but stops short of explaining what 'persist' means operationally (create vs. update).

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 save_knowledge_nodes, set_learning_configuration, or complete_session. The 'lifecycle Stage 1' hint is unexplained, so the agent must infer context that should have been 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?

The description discloses a key non-obvious behavior: it creates a review item only if one does not already exist, implying idempotent behavior. With no annotations, though, it does not mention side effects, required permissions, or how existing schedules are affected.

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 tight sentence with no filler, and the conditional behavior is front-loaded. It is concise, though the brevity sacrifices detail that would help with a 5-parameter tool.

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

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

Given 5 parameters, no output schema, and no annotations, the description is too minimal to fully support tool selection and invocation. It does not clarify what 'review item' means, what the optional parameters do, or what happens after creation.

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

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

Schema description coverage is 0%, and the description only vaguely anchors 'node_id' by mentioning 'for a node'. The required learner_id and the optional item_ref, request_id, and session_id are not given any semantic explanation, leaving the agent to guess from 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 ('Create') and resource ('review item for a node'), and the conditional 'if one does not exist yet' clarifies the intent. It is clear and not tautological, though it does not explicitly differentiate itself from siblings like submit_review or get_due_reviews.

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 the tool: when a review item should be ensured for a node. However, it gives no explicit guidance about when to prefer this tool over alternatives like submit_review, recalculate_review_schedule, or get_due_reviews.

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 program is never modified, that the configuration is stored at session level, and that unrecognized requests are reported back. These are key behavioral traits beyond the bare action.

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 no filler. The purpose is front-loaded, and the examples are concise and illustrative. Every sentence adds value.

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 description covers the main action, storage behavior, and error handling for unrecognized requests. However, it does not clarify the relationship between `request` and `mode` when both are provided, nor the role of `request_id`. For a 5-parameter tool with no output schema, these gaps leave some ambiguity.

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

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

Schema coverage is 0%, so the description must compensate. It thoroughly explains `request` and lists recognized `mode` values, but leaves `overrides` and `request_id` unexplained. It hints at 'Policy Overrides' but does not describe the parameter usage, so compensation is partial.

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 ('apply'), a resource ('learning mode'), and scopes it to a learner's request. It distinguishes itself from the sibling get_learning_configuration by clearly being the write counterpart, and it enumerates recognized modes.

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 clear guidance on how to use the tool (pass the learner's own words in `request`) with concrete examples, and explains the fallback for unrecognized requests. It does not explicitly mention the alternative get_learning_configuration, but the intent is obvious from 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 only states 'Set the current teaching focus,' implying a mutation, but gives no details on side effects, reversibility, required context, or what happens to the previous focus. This is a significant gap for a state-changing 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 a single short sentence, which is concise, but it is under-specified. It lacks necessary detail and structure, making it insufficient for safe usage. The brevity is not effective conciseness but rather incompleteness.

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 has 4 parameters, no annotations, no output schema, and is a state-changing operation, the description is highly incomplete. It does not explain return values, prerequisites, or effects, making it impossible for an agent to use correctly without additional context.

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

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

Schema description coverage is 0%, and the description does not compensate. It mentions 'unit or node' which hints at node_id and unit_tag, but does not explain the distinction, when to use each, or the meaning of request_id and session_id. The description adds virtually no value beyond the bare 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 ('Set') and resource ('current teaching focus') with the object 'a unit or node.' It is clear about the action but does not differentiate from siblings like advance_unit or rollback_unit, which also modify teaching focus. The purpose is understandable but lacks explicit sibling distinction.

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

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

No guidance is given on when to use this tool versus alternatives such as advance_unit, rollback_unit, or get_teaching_context. There are no conditions, prerequisites, or exclusions mentioned, leaving the agent to infer appropriate 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 full burden of behavioral disclosure. It only mentions returning an attempt_id, but does not reveal side effects (e.g., does it modify session state?), prerequisites, failure behavior, or impact on assessment flows. This is minimal for a recording/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 a single concise sentence with no fluff, which is positive for conciseness. However, it is under-specified to the point of failing to inform the agent about critical usage details, so conciseness is not an advantage here. It earns a middle score.

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

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

For a tool with eight parameters, no output schema, and no annotations, the description is severely incomplete. It omits parameter meanings, return format details, side effects, and usage context. An agent cannot safely invoke this tool correctly based on this definition 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 description coverage is 0%, so the description must compensate by explaining the eight parameters, but it explains none. It does not clarify what answer, item_id, node_id, hint_level, request_id, response_time, or predicted_performance mean or how they affect recording. The single verb 'record' does not disambiguate any parameter.

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 verb 'Record' and the resource 'a learner attempt', and explicitly mentions returning an attempt_id for assessment. It is unambiguous about what the tool does, though it does not differentiate from sibling tools like submit_diagnostic or submit_review.

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

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

No guidance is provided on when to use this tool versus alternatives. Given the many submission-related siblings (submit_diagnostic, submit_review, submit_diagnostic_result), the description offers no context for when an 'attempt' is the appropriate choice, nor any 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Record' signals a write operation and 'one diagnostic answer' narrows scope, but the description is silent on persistence, permission requirements, side effects, or what happens after submission.

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 with no filler; the verb and object come first. It is concise and readable, though it is concise partly because it omits important context, which keeps it from being 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?

For a mutation tool with eight parameters, no output schema, no annotations, and 0% schema description coverage, one clause is far too little to select and invoke the tool reliably. The description does not explain the diagnostic context, the required session field, or the optional fields' roles, leaving significant gaps.

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

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

Schema description coverage is 0%, and the description does not compensate. It mentions 'answer' but provides no meaning for the other seven parameters such as session_id, item_id, node_id, hint_level, request_id, or response_time, forcing the agent to guess their purpose.

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 ('Record') and a clear resource ('one diagnostic answer as a learner attempt'), so an agent can tell this is the tool for persisting a single diagnostic answer. However, it does not explicitly distinguish it from sibling tools like submit_attempt or save_diagnostic_result, so it misses the top score.

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

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

The wording implies this should be used when an agent has a diagnostic answer to record as an attempt, rather than when creating a session or retrieving results. It does not explicitly state when to prefer it over the many sibling tools, nor does it mention alternatives or exclusions, so the 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.

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

With no annotations, the description must disclose behavioral effects; it does clearly indicate this is a mutation that submits a rating and reschedules. However, it does not explain side effects such as whether the current due state is consumed, whether submissions are idempotent, or what prerequisites must hold.

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 verb, resource, and rating scale inline. There is no filler, and every word contributes to understanding the tool's action.

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

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

For a mutation tool with four parameters, no annotations, and no output schema, one sentence is insufficient. It omits when to call the tool, prerequisites such as obtaining a review item, the meaning of session/request IDs, and what a successful response contains.

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

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

Schema description coverage is 0%, so the description must compensate. It does document the rating scale well, but it leaves review_item_id's origin/format and the purposes of request_id and session_id entirely to their names, so the agent cannot confidently determine how to fill optional parameters.

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

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

The description names a specific action (submit an FSRS rating), the resource (review), and the accepted rating scale, which makes the core purpose clear. It does not explicitly distinguish itself from similar sibling tools like submit_attempt or schedule_review, so it stops 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?

There is no guidance about when to use this tool versus alternatives such as get_due_reviews, schedule_review, or recalculate_review_schedule. The review context is implied by the wording, but no explicit usage conditions or exclusions are provided.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It only restates the operation and does not disclose the return type, whether the check is read-only, whether external evidence sources are contacted, or how failures are reported. The word 'Check' weakly implies read-only behavior, but this is not explicit.

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 with no filler or repetition, so it is structurally concise. It is somewhat under-specified, but the brevity itself is not a structural flaw.

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 no annotations, the description should tell the agent what the check returns and whether any state changes occur; it does neither. It also leaves the semantically non-obvious 'verified' parameter unexplained, making 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 description coverage is 0%, and the description does not explain the 'verified' boolean parameter or its default true value. It vaguely maps claim_id to the 'claim' being checked, but it adds no meaning beyond the raw 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 uses a specific verb ('Check') and names the resource ('a claim linked to a real evidence source'), making the core operation clear. It does not explicitly differentiate from sibling validate_knowledge_dag, but the claim-specific wording is sufficient to understand the tool's focus.

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