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

Annotations declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false, covering the side-effect profile. The description adds no extra behavioral context (e.g., what 'bounded' means for output size or how results are aggregated). The verb 'build' could be misinterpreted as creating a persistent artifact, which slightly conflicts with the read-only hint, but it is not a direct contradiction. Overall, the description doesn't add significant value beyond 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, efficient sentence with no filler. It front-loads the core action and scope. It could be slightly more informative without losing conciseness, but as is, it is appropriately short and to the point.

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?

Although an output schema exists (so return format is covered), the description leaves crucial gaps: it doesn't explain what an 'evidence pack' comprises, what 'bounded' means in practice, or how this tool differs from the closely related medeval_search_project_evidence. With 5 parameters and no param descriptions, the description is too sparse to fully guide 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%, so the description must compensate. It implicitly relates to parameters: 'section-scoped' ties to section_id, 'CEP/CER' to document_type, 'bounded' to top_k, and 'evidence pack' to query and top_k. However, it doesn't explain what query is for or how top_k controls results, and project_id is not mentioned. The description gives a general context but lacks explicit parameter-level guidance.

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 ('Build') and a well-defined resource ('bounded, section-scoped evidence pack for one CEP/CER section'). It also implies a scoping constraint (section-level) that distinguishes it from broader search tools like medeval_search_project_evidence. However, it doesn't explicitly contrast with other siblings, 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 no guidance on when to use this tool versus alternatives. It doesn't mention that this is the tool to call for section-level evidence assembly, nor does it contrast with medeval_search_project_evidence or medeval_get_agent_context. The 'bounded, section-scoped' phrasing hints at a specific use case but provides no explicit when-to-use or when-not-to-use instructions.

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

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

Annotations already indicate this is a mutation (readOnlyHint=false). The description adds behavioral nuance: the workspace is 'isolated', and creation must follow an explicit user request, which provides guidance beyond the binary annotation flags. No contradiction exists; the description aligns with the mutation hint and adds meaningful 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 a single, extremely concise sentence with no fluff. It front-loads the key condition ('only after an explicit user request') immediately after the verb. Every word serves a purpose, achieving maximal information density in minimal space.

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

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

Given the tool is a simple create operation with an output schema available, the description alone is minimally sufficient: it states the action and when to perform it. However, the complete absence of parameter explanations means agents lack essential context for constructing a correct call. The description does not cover what happens after creation (e.g., returns workspace ID?) but the output schema likely covers that. Overall, it is serviceable but leaves notable gaps for a tool with unannotated parameters.

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 0% description coverage, and the description does not explain any of the three parameters (title, metadata, workspace_id). For a required parameter like 'title', there is no hint about what constitutes a valid title (e.g., format, length, purpose). The description carries zero parameter information, leaving the agent to infer semantics entirely from parameter names, which is insufficient for reliable invocation.

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 ('Create'), a clear resource ('isolated workspace'), and a specific condition ('only after an explicit user request') that distinguishes it from sibling read/list/get tools such as medeval_get_workspace and medeval_list_projects. The purpose is unambiguous and action-oriented.

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 a clear contextual condition by specifying 'only after an explicit user request' – which tells the agent when it is appropriate to call this tool. However, it does not name alternatives or explicitly state when NOT to use it (e.g., if a workspace already exists, perhaps use get_workspace). This is still strong guidance but lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a non-destructive, repeatable operation. The description adds 'bounded textual diff', implying the output is limited in size (relating to max_diff_characters). However, it does not disclose behavior like what happens if the diff exceeds the bound or if revisions are missing. Given that annotations cover the safety profile, the description adds minimal extra behavioral context, so a 3 is appropriate.

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, focused sentence that conveys the core purpose without fluff. It front-loads the action and resource, and the qualifier 'bounded' adds value. There is no redundant content, making it highly concise and well-structured.

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?

Since an output schema exists, the description does not need to explain return values. However, the tool has 5 parameters and the description only vaguely references the diff bound. It does not clarify the direction of comparison or how the parameters relate to the operation. For a relatively simple diff tool, the description is adequate but leaves some operational details implicit.

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 clarity. While parameter names (workspace_id, document_id, from_revision_id, to_revision_id, max_diff_characters) are self-descriptive, the description only vaguely hints at the diff limit with 'bounded'. It does not explain the significance of 'from' vs 'to' or the default behavior of max_diff_characters. The description fails to add meaning beyond the schema's basic titles.

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

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

The description clearly states a specific verb ('Compare'), the resource ('two immutable revisions'), and the nature of the operation ('bounded textual diff'). It distinguishes from siblings like medeval_read_document_revision (which reads a single revision) and medeval_list_document_revisions (which lists revisions) by focusing on comparison. The purpose is unambiguous.

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

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

The description implies when to use the tool (when a diff between revisions is needed) but provides no explicit guidance on when not to use it or alternatives. It doesn't mention other tools like read or list for comparison. The phrase 'immutable revisions' hints at safety, but there is no exclusionary language. The guidance is derived rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds only the term 'bounded context receipt', giving a slight hint about the returned data but nothing else. It is consistent with annotations (no contradiction), but it adds minimal behavioral context beyond what annotations already provide.

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

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

The description is a single, short sentence with no wasted words. However, its brevity borders on under-specification; it is concise but lacks substance that would be valuable for selection and invocation.

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 is severely incomplete for a tool with three required parameters and an output schema. It does not explain what a 'bounded context receipt' is, what data it returns, or how the parameters relate. Even with an output schema, the description fails to give enough context for an agent to confidently call this tool.

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

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

The schema has zero descriptions for the three parameters (workspace_id, run_id, agent_id), and the description provides no additional information about their meaning or formats. The parameter names are somewhat self-explanatory, but the description does not clarify their role or constraints, so it fails to compensate for the missing schema descriptions.

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 ('Read') and a specific resource ('bounded context receipt for one agent in a selected run'). However, 'bounded context receipt' is domain jargon that is not explained, and the description does not clearly distinguish it from related tools like medeval_build_section_context. It is reasonably specific but leaves room for 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?

No guidance is provided on when to use this tool versus the many sibling tools. It does not mention any alternative, prerequisite, or condition for selection, leaving the agent to infer usage from names 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool reads progress, output metadata, and adopted artifacts, which is useful context beyond the annotations. However, it does not disclose any additional behavioral details like pagination, rate limits, or what 'adopted artifacts' entails, so it adds only modest value per the lower bar set by the annotations.

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

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

The description is a single, front-loaded sentence with no redundant words or fluff. It is concise and structured, but it is arguably too terse—leaving out details that could be added without much verbosity. A 5 would require a bit more substance while maintaining conciseness.

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

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

Given the tool's simplicity (one parameter, output schema present, annotations covering safety), the description is partially complete. It does not explain how to obtain a valid task_id or what 'generation task' specifically refers to, and it lacks usage context relative to siblings. The output schema covers return values, so that is not needed. Overall, it falls short of being fully self-contained for an agent.

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 only one parameter, task_id, with zero description coverage (0% schema_description_coverage). The description does not mention task_id at all, nor does it clarify that task_id identifies the generation task. Since schema coverage is low and the description fails to compensate, the agent must infer the parameter's meaning from the tool name and context. This is a notable 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 clearly states a read operation on a generation task, specifying three aspects: progress, output metadata, and adopted artifacts. The verb 'Read' and resource 'generation task' are explicit. However, it does not distinguish itself from sibling tools like medeval_get_task_progress or medeval_get_run, which could overlap in purpose. A 5 would require naming the distinct resource or excluding 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 alternative tools. There is no mention of prerequisites, such as how to obtain a task_id, nor any exclusions. The agent must infer usage from the name and sibling context, which is not explicitly stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not restate safety. It adds value by specifying exactly what data is returned (agents, actions, retrievals, warnings, outputs), which is helpful behavioral context beyond the annotations. However, it does not describe pagination, size limits, or error behavior, though the presence of an output schema mitigates this.

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, well-structured sentence that front-loads the verb and resource and lists the key data types. It contains no superfluous words or repetition, making it efficient and easy to parse. It is slightly under-specified for parameter guidance, but that is a content issue, not a conciseness problem.

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 an output schema present and comprehensive annotations, the description covers the return values and safety profile. However, the lack of parameter semantics and usage guidance leaves the tool partially incomplete. An agent would need to infer how to obtain run_id and workspace_id from other tools (e.g., list_runs) and decide when to use this tool. For a read operation with an output schema, this is moderately complete but not fully self-contained.

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 two required parameters, run_id and workspace_id. It does not mention them at all; the only meaning comes from schema titles 'Run Id' and 'Workspace Id', which are minimal. There is no explanation of their format, how to obtain them, or any relationships between them. This is a significant deficiency given the agent must correctly supply both.

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 'Read' and the resource 'one run', and enumerates the data types returned: agents, actions, retrievals, warnings, and outputs. It distinguishes itself from list_runs (which presumably lists summaries) by focusing on a single run's detailed contents, and from other tools that inspect specific aspects. However, it does not explicitly name sibling alternatives, leaving some differentiation to inference.

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

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

The description implies usage when you have a specific run_id and want its detailed contents, but it provides no explicit guidance on when to choose this over related tools like medeval_list_runs or medeval_get_task_progress. There is no mention of prerequisites (e.g., that a run must exist) or how to obtain run_id/workspace_id. With many sibling tools, this lack of routing guidance is a notable 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?

Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description carries a low burden here. It adds modest value beyond the annotations with 'lightweight' (cheap/fast) and 'live' (near-real-time snapshot), which are useful behavioral cues not present in structured data. No mention of rate limits or auth, but that is acceptable given the annotations already disclose the operation is safe and non-mutating.

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 zero filler. The verb and primary benefit ('without resubmitting') are front-loaded, and every word earns its place. This is exemplary conciseness.

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

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

The tool is simple (one self-evident parameter), annotated for safety, and has an output schema covering the return shape, so the description need not explain results. The main gap is the missing distinction from medeval_get_generation_task and the unspecified provenance of task_id. Adequate but not complete for a tool whose key ambiguity lies in its siblings.

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%, putting the burden on the description to explain the task_id parameter, but the description says nothing about it. The parameter is self-explanatory by name, and the output schema exists, so some effort is spared, but the description should at least note that task_id is the identifier returned by a submission tool like medeval_start_generation. It does not compensate for the zero-coverage schema.

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

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

States a specific verb ('Read') and resource ('lightweight live status snapshot' / task progress), which is consistent with the readOnlyHint=true annotation. The phrase 'without resubmitting the task' hints at contrast with submission-oriented siblings like medeval_start_generation and medeval_start_evaluation. However, it does not distinguish itself from the closely-named medeval_get_generation_task, which an agent could easily confuse with this tool.

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

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

The phrase 'without resubmitting the task' implies the tool is for checking on an already-submitted task rather than re-triggering one, which is a weak contextual signal. But it names no alternative tool, gives no explicit when-to-use/when-not-to-use guidance, and fails to clarify when to pick this over medeval_get_generation_task or medeval_get_run. Usage context is left to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it reads a summary and integrity counters, which is useful context beyond the schema. However, it does not elaborate on what integrity counters are or any side effects (though none expected). It does not contradict 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 leads with the primary verb and object. It includes the essential noun phrase and no filler. This is appropriately brief for a simple read operation, with zero wasted words.

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

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

For a read-only tool with an output schema already defining return values, the description touches the core behavior. However, it lacks any mention of how to identify the workspace or what 'integrity counters' entail. Given the tool's simplicity and the presence of annotations, this is adequate but minimal—nothing critical is missing, but more context could be added.

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

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

The only parameter, workspace_id, is required but has no description in the schema (coverage 0%). The description does not explain what a workspace_id is, how to obtain it, or any format expectations. While the name is self-explanatory, the description fails to compensate for the missing schema documentation, which is a real deficiency for a single-parameter tool.

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

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

The description states a clear verb ('Read') and resource ('workspace summary and integrity counters'), indicating it retrieves workspace-level information. This differentiates it from siblings like medeval_get_run or medeval_get_task_progress, though 'integrity counters' is somewhat vague. Overall, the purpose is understandable and 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 provided on when to use this tool versus alternatives. It does not mention prerequisites, when it is appropriate, or any exclusions. The description only states what it does, leaving the agent to infer usage from context. Given the large sibling set, this is a notable 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to restate those. It adds the 'local' scope and 'bounded capability summary' details, which provide extra context about the tool's behavior without contradicting the annotations. This goes beyond a tautology and gives the agent a clearer picture of what to 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, tight sentence starting with the actionable verb 'Check'. It is front-loaded and contains no fluff, making it easy for an agent to grasp quickly. Every word serves a 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?

Given the simplicity of the tool (no parameters, read-only, idempotent), the description is fully sufficient. It states what the tool does and what it returns. The output schema is present, so the description doesn't need to detail return values. Nothing an agent needs to call this 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?

With zero parameters, the description doesn't need to explain any input requirements. The schema covers 100% (empty object), and the tool's purpose is fully captured by the description. There is nothing missing regarding 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 clearly states the verb 'check' and the resource 'local backend', producing a specific, unambiguous purpose. It distinguishes itself from all sibling tools, which are data operations on projects, workspaces, docs, etc., by being the only health/status tool. The output 'bounded capability summary' further clarifies the tool's role.

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

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

The use case is implied by the nature of a health check—likely to verify backend availability before other operations—but the description provides no explicit when-to-use or when-not-to-use guidance, nor does it reference any alternatives. While the tool's name and purpose make it obvious, the lack of explicit usage context leaves some ambiguity about when an agent should invoke 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?

All annotations are false, so the description must carry behavioral disclosure. It mentions immutability and 'allowed' files, giving some context about side effects (new session) and constraints. However, it does not disclose potential validation steps, permissions needed, or what happens to existing data. Given the mutation nature, more detail is expected.

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 or repetition. It is front-loaded with the core action. However, it is so brief that it sacrifices necessary detail, but the dimension is about conciseness, not completeness, and it achieves that well.

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 six parameters, none explained, and minimal behavioral detail, the description is incomplete. The output schema exists, so return values are covered, but an agent would struggle to know which parameters are required, their formats, or constraints. Important context like allowed file types and session creation details is missing.

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

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

Schema coverage is 0% and the description provides no explanation for any of the six parameters. It only vaguely refers to 'allowed local files' but does not clarify file_paths, platform, device_hint, pdf_read_mode, workflow_mode, or model_selection. With no parameter details, the description fails to compensate for the schema's lack of descriptions.

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

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

The description clearly states the action ('Upload'), the resource ('allowed local files'), and the destination ('a new immutable cleaning session'). This is specific and distinguishes it from sibling tools like 'medeval_start_generation' or 'medeval_list_projects', which involve different actions and resources.

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 'new immutable cleaning session' implies it's for starting a fresh session, but the description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions (e.g., not for existing sessions). No alternative tools are named or contrasted.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds 'immutable' as extra context about the revisions, which is helpful, but doesn't disclose any edge cases (e.g., behavior when document not found, pagination, or ordering). Since annotations already carry the main behavioral load, this is adequate 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?

A single, tightly-worded sentence that leads with the action and resource, with no redundancy. Every word earns its place, and the description is easy to parse quickly.

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 a simple list operation with only two common parameters. An output schema exists to define the return structure, so the description doesn't need to explain that. The description covers the core purpose and scope, making it sufficient for an agent to call the tool correctly. Minor omissions like ordering or error handling are not critical given the 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?

Schema description coverage is 0%, so the tool description must compensate for parameter explanation. It doesn't explicitly describe document_id or workspace_id, but the phrase 'for one document' implicitly maps to document_id, and workspace_id is a common contextual parameter across siblings. The parameter names are self-explanatory, so this is minimally sufficient, though it doesn't fully elaborate on workspace_id.

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

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

The description uses a specific verb ('List') with a clear resource ('immutable revisions and the current head') and scope ('for one document'). It precisely distinguishes this from sibling tools like medeval_read_document_revision (read a specific revision) and medeval_diff_document_revisions (compare revisions), so an agent can immediately understand its function.

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 clear context that this tool lists revision history for a single document, which implicitly tells an agent when to use it. However, it doesn't explicitly name alternatives or state when not to use it, though the scope constraint ('for one document') is a useful boundary.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the 'installed in the local MedEval backend' detail, which provides minor location context but no new behavioral traits beyond 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?

A single, efficient sentence that front-loads the primary action and object. No redundant phrasing or filler; every word contributes.

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 list operation with rich annotations (readOnly, idempotent, non-destructive) and an output schema, the description is mostly complete. It could briefly mention that these templates are used by generation tasks (e.g., medeval_start_generation), but that is implied by the tool name and sibling context, so the absence is not critical.

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 schema has nothing to document. Baseline is 4 for parameterless tools, and there is no additional parameter semantics 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?

The description states a specific verb (List), a resource (generation templates), and a scope (installed in the local MedEval backend). This clearly distinguishes it from sibling list tools like medeval_list_projects and medeval_list_runs, which target different resources.

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

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

The description implies usage (call this when you need to see available generation templates) but does not provide explicit context or mention alternatives. It lacks any 'when not to use' guidance or hints about prerequisites, such as needing templates before starting a generation task via medeval_start_generation.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), lowering the bar. The description adds minimal extra context, such as the scope 'one project evidence repository', but does not disclose pagination behavior, ordering, or how 'raw and retrieved' documents might differ in returned format. It provides some context but leaves gaps.

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

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

A single, front-loaded sentence with no filler that states the action and object clearly. Every word earns its place, and the structure is immediate and scannable.

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 is adequate for a simple list operation, especially with an output schema and safety annotations present, but it lacks guidance on how limit works, what 'raw and retrieved' means, and when to select this over closely related siblings. Additional context would improve correct selection and 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%, so the description must compensate, but it does not elaborate on project_id or limit beyond their names and defaults. The phrase 'raw and retrieved documents' relates to output, not parameter meaning, leaving the agent without additional semantic guidance for 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 (List) and resource (raw and retrieved documents) scoped to 'one project evidence repository', which clearly differentiates it from workspace-level or global listing tools. However, it doesn't explicitly name sibling alternatives, so it's 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?

No guidance is provided on when to use this tool versus siblings like medeval_search_project_evidence or medeval_list_workspace_documents. The description only states what it does without context, exclusions, or hints about when it's 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the safety profile. The description adds the qualifier 'local' and 'chat projects/workspaces,' which narrows scope meaningfully. However, it doesn't disclose pagination or filtering behavior beyond the bare action. Since annotations cover the main behavioral guarantees, the description adds modest extra context, warranting a score of 3.

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 that front-loads the action and purpose. Every word contributes value ('List local chat projects/workspaces; use before selecting a workspace'), with no redundant phrasing. It is optimally concise and structured.

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

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

The tool is a simple list operation with an output schema, so return values are covered. The description explains the primary purpose and usage timing. However, the absence of any parameter documentation leaves the agent without guidance on how to paginate or filter, which is a notable omission for a tool with three parameters. The description is adequate for basic invocation 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% – the description provides no information about the three parameters (limit, query, cursor). These are common pagination/filtering parameters, but the description does not explain them or their defaults. With zero coverage, the description must compensate, and it fails to do so. This is a significant 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 ('List') on a specific resource ('local chat projects/workspaces'), which clearly conveys its purpose. It distinguishes itself from sibling tools like create/get workspace by indicating it lists existing items, though it doesn't explicitly name alternatives. The 'use before selecting a workspace' adds functional context, but the purpose is clear without it.

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

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

The description provides a clear usage instruction: 'use before selecting a workspace.' This indicates when to invoke it relative to other actions. It doesn't explicitly state when not to use it or mention alternative tools, but the directive is actionable and unambiguous. Given the simplicity of the tool, this is sufficient.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the qualifier 'observable' which may imply a filtering or subset of runs, but it does not explain what 'observable' means. This adds minimal context beyond the structured hints, so a 3 is appropriate.

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 extraneous words. It is appropriately concise and front-loads the action and resource. It earns a 5 for efficiency.

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 an output schema, so the description need not explain return values. However, the description omits details like pagination (limit) behavior, what 'observable' means, and any prerequisites. With only two parameters, it is not highly complex, but the lack of context around 'observable' and limit leaves some gaps. A 3 reflects moderate completeness.

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 both parameters. The description only indirectly references workspace_id via 'for one workspace', but it does not explain the meaning of the limit parameter. No additional details on formats, defaults, or behavior are provided. This partial compensation is insufficient; a 2 reflects the incomplete guidance.

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

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

The description clearly states the action (List) and the resource (observable workflow runs and agent progress) scoped to one workspace. It is specific enough to distinguish from sibling tools like medeval_get_run (singular run) and medeval_list_projects (different resource), though it does not explicitly name a sibling or contrast with them. The scope 'for one workspace' adds clarity.

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. There is no mention of conditions, exclusions, or when to prefer medeval_get_run or medeval_get_agent_context. According to the rubric, no guidance earns a 2.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context that the documents are 'generated/versioned' and scoped to 'one workspace', which is beyond annotations. However, it doesn't disclose any additional behavior like pagination, sorting, or what exactly a 'document head' entails. With annotations covering the main traits, this is adequate.

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 zero filler. It front-loads the verb and immediately specifies the resource and scope. Every word earns its place, and it's appropriately concise for a simple list operation.

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

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

The tool has a single required parameter, an output schema exists (so return format is covered elsewhere), and annotations handle safety. The description covers the key aspects: what is listed, the type of documents, and the workspace scope. It doesn't mention potential pagination or ordering, but for a straightforward list tool this is acceptable. It's nearly complete, slightly lacking detail on what 'document heads' entails.

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 workspace_id parameter. The phrase 'in one workspace' directly clarifies the role of workspace_id, indicating which workspace the documents belong to. This adds meaning beyond the schema's bare type definition, making the single parameter's intent clear.

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 (list), a specific resource (generated/versioned document heads), and scope (one workspace). It distinguishes from sibling tools like list_project_documents by mentioning 'heads' and 'workspace', though it doesn't explicitly name the alternative. Still, the purpose is clear and specific.

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

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

There is no guidance on when to use this tool versus alternatives like medeval_list_project_documents or medeval_list_document_revisions. The description says nothing about contexts where this is preferable or when not to use it. It provides no exclusions or comparison, leaving the agent to infer from sibling names.

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

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

Annotations already indicate a write operation (readOnlyHint=false) and non-destructive nature (destructiveHint=false). The description adds the crucial behavior of appending rather than overwriting, which clarifies that it does not modify existing revisions and preserves history—a trait not fully captured by the annotations. However, it does not disclose error behavior on optimistic-lock conflicts or any side effects beyond the append guarantee.

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 front-loads the action and its key guarantee. Every word contributes meaning—'append' and 'never overwrite' are specific and avoid redundancy. There is no filler or repetition.

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

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

Given the complexity of five required parameters, no schema descriptions, and no explanation of the operations array or instruction semantics, the description is grossly incomplete. The output schema exists, but the agent still needs to know how to form a valid patch request, what base_revision_id represents, and what happens on conflict—none of which are addressed. This falls far short of what a mutation tool with this parameter count requires.

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% coverage, meaning no parameter descriptions exist, and the tool description makes no attempt to explain the five required parameters (workspace_id, document_id, base_revision_id, operations, instruction). The description is entirely silent on what 'operations' entails or the role of 'instruction', leaving the agent with no semantic guidance for constructing valid calls.

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 ('Append one optimistic-lock revision') and a resource (revision), and clearly distinguishes itself from read-only siblings like list_document_revisions and read_document_revision by emphasizing the write-append nature. The constraining clause 'never overwrite revision history' further clarifies its unique purpose among the revision-related 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 description implies a usage scenario (creating a new revision with optimistic locking) but does not explicitly state when to use this tool versus alternatives such as read or diff tools. The constraint 'never overwrite revision history' suggests a safe append operation, but there are no direct exclusions or alternative tool references, leaving the agent to infer the appropriate 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds mild context ('immutable' confirms reads don't alter snapshots; 'bounded page' implies results are capped/paginated) but does not go much beyond the annotation baseline.

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, scannable sentence with zero filler. The core action ('Read a bounded page') is front-loaded, followed immediately by the object ('one immutable Markdown revision'). No redundancy with the schema.

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

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

With 6 parameters at 0% schema coverage, the pagination boundary semantics and the current-vs-revision_id selection logic are left unexplained, so an agent cannot determine from the description how to read a non-current revision. The output schema covers return values, but the selection behavior gap 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%, so the description must compensate, yet it explains neither parameter's meaning. The critical ambiguity between the 'current' flag (default true) and revision_id (default '') — how an agent targets a specific non-current revision — is entirely unaddressed. 'Bounded page' only faintly hints at start_char/max_chars.

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 ('Read') with a precise resource ('one immutable Markdown revision') and a scope qualifier ('bounded page') that signals pagination. This is clearly differentiable from siblings like medeval_patch_document_revision (a writer) and medeval_diff_document_revisions (a comparator), though it stops short of naming 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?

There is no guidance on when to use this tool versus medeval_list_document_revisions or medeval_diff_document_revisions, nor any workflow context such as 'list revisions first, then read a specific one.' No exclusions or when-not-to-use conditions are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a useful caution about source reliability, but does not disclose other behavioral traits like result ordering, pagination, or filtering behavior. With annotations covering the main risks, this is acceptable 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 extremely short (8 words) but this is under-specification rather than effective conciseness. It front-loads the core purpose but omits essential operational details, so it does not earn its 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 search tool with 8 parameters, a cautionary note, and no schema descriptions, the description is far from complete. It does not explain what results look like (despite having an output schema), how filters combine, or what 'bounded local evidence' means in practice. An agent would struggle to call 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?

Schema description coverage is 0%, so the description must compensate for the 8 parameters. It provides no explanations for ambiguous ones like node_type, source_kind, evidence_type, or hide_low_confidence. Only query, project_id, and top_k are somewhat self-explanatory by name, but the description adds no value to 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 states 'Search bounded local evidence' which is a verb+resource, but 'bounded local evidence' is vague and doesn't specify what kind of evidence or how it relates to a project. It doesn't differentiate from siblings like medeval_build_section_context, which likely also deals with project evidence.

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, no exclusions, and no mention of preferred use cases. The caution to 'inspect sources before factual use' is a general reliability note, not a usage guideline.

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?

All annotations are false, so the description carries the full burden for behavioral disclosure. It only mentions the authorization prerequisite, which is an invocation condition, not a behavioral trait such as side effects, the nature of the started process, or its non-idempotency. It does not contradict the annotations but adds 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 one short sentence, which is concise in length but not effective in structure because it conveys almost no functional information. It front-loads the authorization condition but fails to structure the tool's purpose or any usage details. The brevity is not a substitute for the missing substance.

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 a tool with 12 parameters, no schema descriptions, and no helpful annotations, this description is grossly incomplete. It does not explain what the evaluation does, what the parameters mean, or what the output will be, even though an output schema exists. An agent cannot correctly invoke this tool with only this description.

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

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

The schema has 12 parameters with 0% description coverage, and the description provides no explanatory text for any of them. Parameters like 'evidence', 'indication', 'alternatives', and 'device_name' are entirely unexplained, leaving the agent without any semantic understanding beyond raw field names. This is a severe compensation failure.

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 ('Start evaluation') and a condition ('only after explicit authorization'), giving the core purpose. However, it is vague about what 'evaluation' entails and does not differentiate from the sibling tool 'medeval_start_generation', so an agent might confuse the two. It avoids tautology but lacks specificity beyond the generic start 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 a single usage prerequisite—explicit authorization—which is a valid when-to-use condition. Yet it offers no guidance on when not to use this tool, nor does it mention alternatives like 'medeval_start_generation' or any context for choosing this over other start-related siblings. This leaves the agent without enough decision support.

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

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

Annotations are sparse (readOnlyHint false, no destructive hint), so the description should disclose behavioral traits. It mentions that 'segmented generation is the safe default', which hints at a strategy difference but does not explain what happens during generation, whether it creates a task, or what side effects exist. This is minimal additional value over the annotations.

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

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

The description is a single short sentence, which is concise and front-loaded with the primary action. However, it lacks essential information, so it is under-specified rather than efficiently complete. The brevity is appropriate but not sufficient.

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 six parameters, no schema descriptions, and an output schema present, the description should provide context on what generation entails, what the parameters mean, and what the return value represents. It does none of this, making it inadequate for an agent to invoke 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 for the six undocumented parameters. It does not explain any of them; 'segmented generation' could relate to generation_strategy but is not explicitly linked. The description adds no meaning to 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 states the action ('Start generation') and a precondition ('after explicit authorization'), which is clear enough given the tool name. However, it does not explicitly distinguish from the sibling 'medeval_start_evaluation', which could be confused, but the resource (generation vs evaluation) is implied by the 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?

The description does not indicate when to use this tool versus alternatives like medeval_start_evaluation. It mentions 'explicit authorization' as a prerequisite but provides no context on when generation is appropriate or when another tool would be better. No exclusions or alternatives are mentioned.

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