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

With no annotations provided, the description carries the full behavioral burden and does so well. It explicitly declares 'READ OPERATION - No confirmation needed. Safe to call freely,' and it discloses the return behavior: a simple yes/no with finding count and top topics. This is valuable transparency beyond the schema.

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

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

The description is well-organized and front-loaded with the core purpose, followed by useful sections for triggers, workflow, safety, parameters, and returns. Minor redundancy exists between 'AUTOMATIC TRIGGERS' and 'WORKFLOW POSITION,' both saying to call at the start of a task, but overall the structure is effective.

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 convenience tool with no output schema, the description is complete: it explains when to call it, what it returns, how to supply parameters, and that it is safe. An agent has enough information to invoke it correctly in the intended workflow.

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

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

Schema coverage is 0%, so the description must compensate for the lack of parameter documentation. It does provide meaningful semantics for both parameters: query is 'What you're about to work on' and project is 'Filter by project (optional).' The explanations are brief but sufficient for an agent to understand each parameter's role.

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 and resource: 'Quick check if relevant context exists before starting work' and 'returns a simple yes/no with relevant finding count and top topics.' It also differentiates itself from related tools by identifying itself as a convenience wrapper around search_fts, so an agent understands its narrow 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?

The description gives explicit when-to-use guidance: 'Call this at the start of ANY new task' and 'WORKFLOW POSITION: First tool to call when starting any task.' It does not explicitly state when not to use it or name alternative tools, but the simple yes/no return format implies when a more detailed search is needed.

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 full behavioral disclosure burden. It implies a read-only comparison operation, but does not describe the output format, return value, side effects, or any data requirements beyond accepting result dicts.

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 cleanly structured: purpose, automatic triggers, parameter. Every line contributes useful information and the decision contexts are front-loaded with no filler.

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

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

Since there is no output schema and no annotations, the description should clarify what the tool returns or how the comparison is presented, but it never does. It gives enough trigger information for selection, but not enough for an agent to know what to do with 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?

The schema only says 'array of objects' with 0% coverage, so the description adds useful meaning by distinguishing workflow result dicts from pre-evaluated result dicts. However, it does not specify the expected keys or what distinguishes a raw result from a pre-evaluated one, so compensation is only 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?

States a specific verb ('Compare') and resource ('benchmark results across workflow types'), and enumerates the three workflow types involved. This clearly distinguishes it from sibling tools like evaluate_co_scientist_run or get_co_scientist_benchmark_tasks.

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 explicit automatic trigger conditions, including the decision context of whether the simpler workflow should remain default. It lacks explicit when-not-to-use guidance or named alternatives, so it falls just short of a 5.

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

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

With no annotations provided, the description carries the full burden of disclosing side effects. It does this well by noting that the tool creates one co_scientist_report artifact and compact session summaries, and that mark_complete can move the run phase to complete. This gives the agent a meaningful behavioral picture beyond just 'create a report.'

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 well-organized with clear sections for triggers, workflow position, and parameters. Every section earns its place, and the core purpose is front-loaded. It is detailed but not bloated.

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 annotations and no output schema, the description covers prerequisites, side effects, parameters, and workflow context well. It is missing only minor details such as what the returned artifact reference looks like or the behavior when mark_complete is false, but the provided information is sufficient for an agent to invoke 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%, so the description must compensate. It provides a PARAMETERS section explaining run_id, created_by, and mark_complete, including the side effect that mark_complete moves the run phase to complete. This adds meaning beyond the raw schema, though run_id could include more detail on where to obtain or validate the run 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 states a specific verb and resource: 'Create the final Co-Scientist report artifact for a verified run.' This clearly differentiates it from sibling tools like get_co_scientist_report (retrieval) and export_co_scientist_findings (export), since this tool creates a durable report artifact.

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 explicitly lists automatic triggers and workflow position: after submit_verification has completed for every selected hypothesis, when the user asks for the final report, or before export/memory preservation. It tells the agent exactly when this tool should be called relative to other workflow steps.

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

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

With no annotations provided, the description carries the full burden. It does disclose the main side effect: it creates two linked sessions in one call and prevents transcript leakage between generation and verification. However, it does not clarify return behavior, whether the workflow runs asynchronously, resource costs, or any permission prerequisites, which leaves the behavioral picture incomplete.

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

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

The description uses clear section headers, front-loads the core action, and provides concise trigger conditions, workflow placement, and parameter semantics. Every sentence contributes meaningful guidance without extraneous 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 multi-session workflow creation tool, the description covers purpose, triggers, placement, and all parameters. It lacks any mention of return values or follow-up steps, and with no output schema present, that leaves a moderate gap. Still, for selecting and invoking correctly it is largely sufficient.

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

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

Schema description coverage is 0%, so the description must supply parameter meaning, and it does. Each of the four parameters receives a useful explanation beyond type/default information: topic is the research objective, constraints are optional limits or domain notes, created_by identifies the creator, and top_k specifies how many hypotheses go to verification.

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 precise verb and resource: 'Create a linked Co-Scientist generation and verification workflow.' It further clarifies scope by stating it creates both generation and verification sessions in one call, cleanly distinguishing it from related tools like start_hypothesis_verification or create_co_scientist_final_report.

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 'AUTOMATIC TRIGGERS' section explicitly states when to call the tool: when a user asks to start a Co-Scientist run, when two linked sessions are needed, or when hypotheses must be generated and verified without transcript leakage. It also notes the workflow position: use after confirming topic scope. However, 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?

The description clearly discloses that this creates a session and that the resulting session contains a structured plan plus rules, which goes beyond a generic create verb. However, with no annotations at all, it does not address behaviors such as whether creation is idempotent, what happens if the template id is invalid, or what the response contains. The core side effect is clear, but the full operational burden is not covered.

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 well structured with a one-line summary, trigger bullets, workflow positioning, and a parameter list. There is almost no filler, and the most useful routing information appears near the top. The parameter list duplicates schema names but adds value through examples and defaults.

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 create tool, it gives enough to make a reasonable call with known templates and example values. But it does not mention what the tool returns, how to discover valid templates, or what happens on failure. Given no output schema and no annotations, a sentence pointing to list_templates or describing the returned session would make this materially more 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 parameter list in the description is the main semantic source. It describes every parameter, gives example values for template_id, and notes the default for created_by. The main limitation is that it does not point to list_templates or get_template for discovering valid template identifiers or explain constraints on title and task_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 clearly states the action: creating a session from a predefined template, and distinguishes it from create_session by emphasizing the structured plan and rules. The examples of common workflows reinforce the purpose. This is a specific verb+resource pairing, not a tautology.

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 explicit automatic triggers with concrete conditions for when to call this tool, such as when the user asks for a template session or when a pre-built plan is preferred. It also names create_session as the alternative and gives the workflow-selection criterion: use this when a structured plan is desired. This gives clear guidance for tool selection.

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

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

With no annotations, the description carries the full burden. It does disclose that this is a creation step and the first action in a collaboration lifecycle, and it gives follow-up guidance. But it does not describe side effects, whether a session identifier is returned, persistence, permissions, or what happens on duplicate/conflicting session creation—so behavioral transparency remains 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 well-structured with clear sections: purpose, automatic triggers, workflow position, parameters, and follow-up. It is slightly longer than strictly necessary—some trigger bullets restate the opening sentence—but each section earns its place and the most important information is front-loaded.

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

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

Given no annotations and no output schema, the description should explain what the caller receives after creation, especially a session identifier needed by join_session and send_message. It explains when to call and the parameter semantics, but the missing return/result contract is a meaningful gap for orchestrating the next steps.

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 is the only source of parameter meaning. It compensates well by explaining every parameter: title and task_description are described, plan is defined as 'list of task dicts (step, task, assigned_to)', rules is defined as 'session rules (max_agents, require_assignment)', and created_by is identified as 'Your agent identifier' with its default. This adds substantial semantic 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 opens with a specific verb-object pair: 'Create a new collaboration session for multi-agent research.' It clearly names the resource (collaboration session) and separates this from sibling session tools by emphasizing 'multi-agent research' and positioning it as the first tool in a collaboration workflow.

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 explicitly states automatic triggers ('Starting a new multi-agent research task', 'User asks to set up a collaboration session', 'You need to coordinate work across multiple agents') and workflow position ('First tool in any collaboration workflow'). It also points to the next steps (join_session, send_message). However, it does not explicitly state when not to use this tool, such as when a session already exists.

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 fully carries the behavioral burden. It clearly states the operation is DESTRUCTIVE, PERMANENT, cannot be undone, requires confirm=True, and that the finding is permanently removed. It also instructs the agent to warn the user beforehand, going well beyond the bare schema.

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

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

The description is well-structured and front-loaded with the critical warning. While there is some repetition of the destructive/permanent message across multiple sections, the redundancy is arguably justified for a safety-critical destructive operation and does not obscure 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?

The description is complete for this tool's complexity: it covers the action, required parameter, confirmation safety gate, permanent consequences, user-warning duty, and excludes misuse cases. No output schema exists, but a delete operation with this guidance does not require additional return-value explanation.

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?

Despite 0% schema description coverage, the description documents both parameters: finding_id as the required ID to delete, and confirm as a mandatory safety gate that must be True. This adds meaningful semantics beyond the schema's bare type/default declarations, especially clarifying the confirm parameter's behavioral role.

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 and resource: 'Delete a finding by ID.' It clearly contrasts with sibling operations like get_finding, save_finding, and list_findings, and even identifies update as the correct action for duplicates. An agent can immediately understand what this tool does and how it differs from nearby 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 gives explicit call conditions under 'AUTOMATIC TRIGGERS' and explicit exclusions under 'DO NOT CALL for,' including naming 'update instead' for duplicate cleanup and forbidding calls without explicit user confirmation. This is exemplary when-to-use vs. when-not-to-use guidance.

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

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

With no annotations provided, the description carries the full behavioral burden and does a good job: it discloses that the tool saves a summary, optionally searches for findings to persist, prevents knowledge loss, and returns session end status and export results. It does not discuss reversibility or potential side effects on related data, but the key behaviors are 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 well-structured and front-loaded with the core purpose, followed by triggers, workflow position, parameters, and return value. There is minor redundancy ('ALWAYS call this when user indicates work is done' partly repeats the first trigger bullet), but overall every section 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 composite tool with no output schema and no annotations, the description supplies triggers, workflow position, parameter guidance, and return behavior, which is sufficient for an agent to select and invoke it. It could be more complete with failure modes or a clearer contrast against session_end, but the core context is well covered.

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

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

Schema description coverage is 0%, so the description must compensate fully. It does: session_id is tied to start_research or session_start, export_to_library explains its conditional effect and default, and project is described as optional. Each parameter receives semantic meaning beyond the raw 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 clearly states the tool ends the current session with automatic knowledge preservation and calls out that it is a composite tool. It distinguishes itself by combining session_end with artifact export, but does not explicitly contrast with siblings like terminate_session or leave_session.

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 explicit trigger conditions ('User indicates work is done', 'Research or analysis is complete', 'About to start unrelated work') and workflow position ('Last tool in any research/analysis workflow'). However, it lacks guidance on when to use an alternative such as terminate_session, leave_session, or session_end instead.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful state information ('completed or in-progress') and the kinds of metrics measured, but it does not state whether evaluation is read-only, whether it persists anything, or what it returns. This leaves important behavioral traits unstated.

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 well organized with a one-line purpose, a scannable trigger list, and a parameter list. It is longer than strictly necessary because the parameter section duplicates schema information, but that duplication is justified by the need to add semantics.

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

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

For a five-parameter tool with no output schema and no annotations, the description covers triggers and parameter meanings but omits return value/format, side effects, and prerequisites such as whether the run must already exist. The overlap with compare_co_scientist_workflows also leaves a selection gap. It is adequate but not 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%, but the description compensates fully with a PARAMETERS section that explains each field: run_id as the run identifier, token_count/cost_usd as optional resource usage, human_edits_needed as report edit count, and expert_accepted as a user/expert acceptance flag. This gives clear meaning beyond the bare schema 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 opening sentence names a clear verb and resource ('Evaluate a completed or in-progress Co-Scientist run') and the trigger bullets specify measurable goals such as traceability, citation coverage, and cost. However, the third trigger, 'Comparing the two-session workflow against simpler baselines,' overlaps with the sibling compare_co_scientist_workflows, so the description does not fully distinguish itself from that 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?

The description explicitly provides 'AUTOMATIC TRIGGERS - Call this when' with three concrete scenarios, giving clear context for invocation. It does not state when not to use the tool or point to an alternative for comparison, so it misses 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 burden of behavioral disclosure. It usefully indicates that the operation runs on a test dataset and measures recall/precision, which conveys an offline evaluation context. However, it does not disclose the output format, whether any files are written, or whether this operation has side effects on configuration or logs.

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 well structured, front-loaded with the core purpose, and uses a scannable trigger list followed by parameter definitions. There is minor redundancy between 'For developers testing improvements' and 'This is a development/evaluation tool, not needed for normal usage,' but the content is otherwise economical.

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 with no required parameters and defaults for both, the description provides enough information to invoke it: what it does, when to use it, and what the parameters mean. The main gap is the absence of any explicit statement about the return value or output format, which matters more because there is no output schema.

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

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

The input schema provides only types and defaults, with 0% description coverage, so the included PARAMETERS section is essential and fully compensates. It clearly defines dataset_path as the path to the JSON test-query file and final_k as the number of results per query to evaluate. This gives the agent enough meaning to invoke the tool correctly.

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

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

The first sentence clearly states a specific action and resource: 'Run retrieval evaluation metrics on a test dataset.' It also adds audience context ('For developers testing improvements') and explicitly positions the tool as a development/evaluation tool rather than normal usage. It does not explicitly differentiate from sibling tools like search_knowledge or evaluate_co_scientist_run, so it stops short of 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 AUTOMATIC TRIGGERS section lists concrete conditions under which to call the tool, such as evaluating retrieval quality after configuration changes and measuring recall/precision. The line 'not needed for normal usage' provides a clear exclusion. It does not name an alternative tool to use instead, so guidance is good but not fully 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 present, so the description carries the disclosure burden. It is transparent about filtering behavior ('intentionally skips inconclusive, contradicted, and unsafe/out-of-scope hypotheses') and the destination library. It could still mention duplicates/overwrite behavior or return values, but core side-effect selection 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?

Well-organized with AUTOMATIC TRIGGERS, WORKFLOW POSITION, and PARAMETERS sections, and the core purpose is front-loaded. The skip/unsupported idea is repeated a couple times, but the overall length is reasonable and every section 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?

For a moderate-complexity tool with no annotations or output schema, the description covers what it does, when to call it, which parameters to provide, and what it intentionally excludes. Missing return/error details are a minor gap, not a blocker 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 coverage is 0%, but the PARAMETERS section compensates by explaining each parameter's meaning and optionality ('created_by: Session orchestrator agent_id or model (required)', 'project: Optional...'). This adds practical meaning beyond the bare JSON schema, though run_id could use a bit more format detail.

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 ('Export ... claims into the main knowledge library') and identifies the resource type ('supported Co-Scientist claims') and destination. This wording differentiates it from generic library or finding tools by tying it to Co-Scientist claims and their supported status.

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 explicit automatic trigger conditions ('A final Co-Scientist report exists...', 'user explicitly asks...') and places it in the workflow ('Use after final report review'). It also tells what will be skipped, but it does not name alternatives or explicitly state when not to use it compared to sibling tools.

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

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

With no annotations, the description carries the burden, and it adds useful behavioral context: the operation 'permanently store' and 'Afer a session completes' indicates persistence and timing. However, it does not disclose potential side effects, authorization needs, idempotency, or error behavior, so it only partially covers behavioral transparency.

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

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

The description is front-loaded with a one-sentence purpose, then organized into trigger bullets, workflow position, and parameter list. It is slightly repetitive ('Afer a session completes' appears twice), but overall each section 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 7 params, no output schema, no annotations, and many similar sibling tools (save_finding, save_finding_auto, export_co_scientist_findings), the description covers triggers, workflow position, and params but does not distinguish from those siblings or explain what the call returns. It is adequate but leaves routing and return behavior 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 description includes a dedicated PRAAMETERS section explaining the meaning and defaults for all 7 parameters, e.g., 'artifacts_ids: Specific artifacts to export (None = all)' and 'project: Project name for findings (defaults to session title)'. This exceeds the schema, which has 0% description coverage, by adding functional semantics and defaults context.

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

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

The description states a specific verb and resource: 'Export session artifacts as findings in the main OpenLMLib library.' The explicit mention of session artifacts and main library differentiates it from generic save_finding and export_co_scientist_findings, and the automatic-trigger context reinforces its 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?

The description provides explicit 'AUTOMATIC TRIGGERS' with conditions like 'A collaboration session is completed' and workflow position 'Afer session termination, before starting new work.' It lacks explicit alternatives or when-not-to-use guidance, hence not a 5.

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

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

No annotations are provided, so the description must carry the behavioral burden. It does so by disclosing important constraints: requesting_agent_id 'Must be same agent id/model identity (own history only)' and agent_id 'matches ephemeral ids via agents.model.' It does not describe return structure or side effects, but as a read-only query this is a minor gap rather than a serious omission.

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 well-structured: a one-sentence summary, a bulleted trigger list, and a compact parameter section. Every section adds decision value, and there is no filler or repetition beyond the acceptable 'Track agent's work history' purpose statement.

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 what the tool does, when to call it, and all parameter semantics, including the own-history restriction. However, there is no output schema and the description does not touch on return format or how the response supports 'continuing work,' so it is not fully complete for an agent needing to interpret results.

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, making the PARAMETERS section essential. The description explains all three parameters meaningfully: agent_id format and ephemeral ID matching, requesting_agent_id ownership restriction, and status filter values ('active', 'completed', 'terminated'). This fully compensates for 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 action and resource: 'Get all sessions an agent has participated in' and adds purpose 'Track agent's work history.' This is clear, but it does not explicitly differentiate from sibling tools like list_sessions or search_sessions; the agent must infer the distinction from 'participated in' and the triggers.

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 'AUTOMATIC TRIGGERS - Call this when' section lists concrete scenarios: 'what sessions have I been in?', 'Looking for past work by a specific agent', and 'Finding related sessions to continue work.' This provides clear when-to-use guidance but offers no exclusions or comparisons to alternative session-related tools.

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

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

No annotations are provided, so the description carries the full burden. It discloses the retrieval (read) nature and the constraint that agent_id must belong to the session, which is useful. However, it does not mention error behavior, access requirements, or return shape—gaps that would help an agent anticipate edge cases.

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 organized into clear sections—purpose, triggers, workflow, and parameters—with a one-line summary up front. Every section contributes useful information, and there is no redundant fluff.

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

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

For a simple read tool with three required string parameters and no output schema, the description is sufficiently complete: it states what the tool does, when to call it, and what each parameter means. It stops short of describing the response format or error conditions, but those are less critical for this straightforward retrieval operation.

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 compensates by explaining all three parameters: session_id as the containing session, artifact_id with a concrete example format, and agent_id with a membership constraint. This adds meaningful guidance beyond the bare parameter titles 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?

The description states a clear verb and resource: 'Get the full content of a specific artifact' and clarifies that artifacts are saved analyses or reports. It does not explicitly differentiate from siblings like get_finding, but the scope is specific enough that an agent can understand what the tool 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 'AUTOMATIC TRIGGERS' section lists three concrete conditions for calling the tool, and the 'WORKFLOW POSITION' section provides ordering guidance relative to list_artifacts. It lacks explicit when-not-to-call or alternative tool routing, but the trigger list gives clear 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 provided, the description carries the behavioral burden. It indicates a read-only retrieval ('Get') of a 'built-in' and 'fixed' task set, implying no mutation or side effects. This is sufficient for a zero-parameter getter, though it does not describe the return format.

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 definition is compact and well-structured: one clear purpose sentence followed by a focused AUTOMATIC TRIGGERS bullet list. It is front-loaded and every line contributes decision-relevant information.

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

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

For a simple zero-parameter getter with no output schema, the description adequately covers what the tool returns and when to call it. It could explicitly state the return shape, but the tool's simplicity makes this a minor omission.

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 zero properties and 100% coverage, so there are no parameter semantics to document. The baseline for a 0-parameter tool is 4, and the description adds no unnecessary argument 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 opens with a specific verb and resource: 'Get the built-in Phase 9 Co-Scientist benchmark task set.' This clearly identifies what the tool does and distinguishes it from sibling workflow-oriented tools like compare_co_scientist_workflows and evaluate_co_scientist_run.

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 AUTOMATIC TRIGGERS section gives explicit call conditions: setting up benchmarks, needing fixed research tasks for repeatable comparison, and deciding whether Co-Scientist should be the default. It does not provide when-not-to-use guidance or name alternatives, so it falls just short of the top score.

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 implies a read operation via 'Get' and 'current synthesized state,' but it does not state whether this call has side effects, whether it can trigger generation/verification, or how it behaves for missing, incomplete, or still-running runs.

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, starts with a one-sentence purpose, and uses scannable bullets for triggers. The parameter line mostly restates the schema, but there is no padding and the structure is easy to parse.

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

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

This is a simple one-parameter tool with no output schema, so the description is the only source of behavioral and return context. It covers primary triggers but leaves the report's structure and content ambiguous, and it does not distinguish this tool from report-generation/evaluation siblings enough for an agent to confidently prepare a final summary.

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, run_id, and the description adds 'Co-Scientist run ID.' That is minimal semantic context beyond the schema's 'Run Id' title, but with 0% schema description coverage, the description does not adequately compensate by explaining the ID's format, source, or how to obtain it.

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 a specific verb and resource: get the current synthesized state of a Co-Scientist run. This is more precise than a vague purpose, though it does not explicitly compare itself to sibling tools like create_co_scientist_final_report or evaluate_co_scientist_run.

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 'AUTOMATIC TRIGGERS' section lists concrete cases for calling this tool: inspecting generation and verification progress, checking hypothesis reports, and preparing a final summary. This is clear guidance for when to use it, but it does not mention when not to use it or 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?

No annotations are present, so the description carries the full behavioral burden. The verb 'Get' and the repeated 'Returns' strongly imply a read-only operation, and the return-content summary is useful. However, the description never directly states that this call has no side effects, requires no special authorization, or is safe to invoke at any time.

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: a one-line purpose sentence, three concise trigger bullets, one workflow-position line, and a short return summary. Every sentence earns its place and no padding is present.

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

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

There is no output schema, so it is important that the description names the returned categories, which it does. It also clarifies when and where to call the tool. It stops short of detailing the exact structure or format of the policy items, but for a zero-parameter, low-complexity policy lookup, the coverage is 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?

The input schema is an empty object with zero parameters, so there is no parameter ambiguity for the agent to resolve. This meets the zero-parameter baseline, and the description adds useful context by summarizing what the returned policy will contain.

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 an unambiguous verb+resource pairing: 'Get the Phase 0 Co-Scientist scope and safety policy.' It also enumerates the exact output content (accepted domains, blocked domains, approval-required actions, Phase 0 limits) and provides a workflow position, making it easy to distinguish from siblings like screen_co_scientist_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?

It provides explicit 'AUTOMATIC TRIGGERS' with three specific conditions and a 'WORKFLOW POSITION' note. It does not explicitly state when not to use the tool or name alternatives, so it falls just short of a 5.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. 'Get' implies a read-only retrieval, and the description adds context about the returned content ('accepted support/refute/neutral labels', 'deterministic evidence quality levels'). However, it does not explicitly state side-effect-free behavior, auth requirements, or return format, leaving moderate ambiguity.

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 well-organized with a short summary, an 'AUTOMATIC TRIGGERS' section, and a workflow-position note. Every line adds decision-relevant information, and the formatting makes it easy for an agent to scan.

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

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

For a parameterless lookup tool with no output schema, the description is complete: it names the artifact, explains its contents, gives explicit trigger conditions, and states workflow position. Nothing critical is missing for an agent deciding to 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 tool takes zero parameters and schema coverage is 100%, so there are no parameter semantics for the description to clarify. The baseline for a zero-parameter tool is 4, and the description adds useful context about the returned rubric even though no parameters are involved.

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 ('Get') and a specific resource ('Phase 6 Co-Scientist evidence labels and quality rubric'). It clearly identifies the artifact being retrieved and distinguishes this lookup tool from mutation or search siblings by focusing on the rubric/criteria artifact.

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 explicitly lists automatic trigger conditions and positions the tool in a workflow: 'Use before writing hypothesis evidence or verification reports that will be promoted to verification.' This gives an agent clear, actionable guidance on when to 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?

The description clarifies the core behavior of retrieving a specific finding and implies retrieval of full details, but it does not go deeper into consequences, error behavior, or any read-only guarantees. With no annotations provided, the description carries the burden, yet it mostly restates the operation rather than adding richer 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 concise and well-structured, with the core action front-loaded followed by an organized trigger list and a helpful alternative pointer. The trigger bullets are slightly repetitive but each line serves a practical purpose for an agent deciding when to invoke the 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?

For a single-parameter fetch tool with no output schema, the description covers the main inputs, when to use it, and how to obtain the required ID. It does not describe the exact return shape, but stating that it provides 'full details' is arguably sufficient for a simple getter, and the guidance to use search_findings fills the main contextual gap.

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

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

The schema provides only the parameter name 'finding_id' with no description, and schema coverage is 0%. The description adds some meaning by indicating the ID comes from search results or list and by telling the agent to use search_findings if the ID is unknown, but it does not describe the ID format or naming convention in any detail.

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

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

The description states a specific verb and resource: 'Get a specific finding by its ID.' This clearly distinguishes the tool from siblings like list_findings, search_findings, and delete_finding, which have different actions and scopes.

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

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

The 'AUTOMATIC TRIGGERS' section explicitly lists when to call the tool, such as when the user references a finding ID or when full details are needed. It also names search_findings as the alternative to use first when the ID is not already available, making the decision logic clear.

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

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

With no annotations, the description carries the full burden. It clearly states that the tool returns a 'JSON-compatible schema description' and clarifies the artifact-first scope of the packet. It also provides workflow context that helps an agent understand the tool's role, though it does not discuss side effects or access requirements, which are less critical for a getter.

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

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

The description is well-structured with clear trigger lists and workflow positioning, and the main action is front-loaded. It is slightly repetitive with phrases like 'hypothesis packet' appearing multiple times, but every section serves a useful 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 zero parameters and no output schema, the description sufficiently explains what the tool returns and when to call it. It could go deeper into what the schema covers, but the tool's entire purpose is to deliver that schema, so listing its contents here would be redundant.

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

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

The tool has zero parameters, so the baseline is 4. There is no parameter-specific meaning to add, and the description correctly focuses on what the schema contains rather than trying to document nonexistent arguments.

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 begins with a specific verb and resource: 'Get the Phase 1 Co-Scientist hypothesis packet schema.' It clearly distinguishes this from sibling tools by focusing on the schema of hypothesis packets rather than validation, submission, or scope policy.

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 AUTOMATIC TRIGGERS section explicitly lists when to call the tool, and the WORKFLOW POSITION adds ordering context ('after scope screening and before saving or sending'). However, it does not mention when not to use it or name alternative tools for related needs, so it stops short of a full 5.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only operation via 'Get' and states what information is returned, but it does not explicitly confirm there are no side effects, nor does it mention authentication, rate limits, or what happens for an invalid model_id. This is acceptable for a simple getter but not fully 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 well-structured: a brief main sentence, a focused trigger list, a cross-reference to list_models, and a parameter detail section. Every sentence adds value and the most important information is front-loaded. Length is appropriate for the functionality.

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

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

For a single-parameter getter with no output schema, the description covers the core use cases, the parameter format, and the relationship to list_models. It could be more complete by describing the exact return structure or error handling, but the tool's simplicity keeps the requirement reasonably low.

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 only specifies that model_id is a string. The description adds the crucial semantic: 'Full model ID' and provides a concrete example ('anthropic/claude-sonnet-4'). This fully compensates for the 0% schema description coverage and prevents an agent from passing a partial or incorrect 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 states a specific verb ('Get') and resource ('detailed information about a specific OpenRouter model') and lists the key content (Pricing, context, description). This clearly distinguishes it from list_models, which lists model IDs, while this tool fetches details for one model.

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 'AUTOMATIC TRIGGERS' section explicitly enumerates when to call this tool: when you have a model ID and need full details, when checking pricing/context limits, or when evaluating suitability. It also directs the agent to use list_models first to find model IDs, which is clear guidance on how it relates to a sibling tool.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses deprecation, 'most expensive layer', and that it returns 'complete observation data', which is useful. However, it does not clarify side effects, error behavior, or whether the deprecated tool may be disabled or behave inconsistently.

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 well structured with sections, front-loaded deprecation notice, and a clear trigger list. Slight redundancy exists between 'Get full details' and 'Returns complete observation data', but overall every part 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 single-parameter get tool with no output schema and no annotations, the description covers purpose, usage, triggers, cost, and parameter semantics. It lacks explicit detail about the return shape or what happens when called despite deprecation, but the core context needed to use the tool correctly 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 coverage is 0%, so the description must fully explain the parameter. It does: 'ids: List of observation IDs from search_memory or memory_timeline' adds provenance and meaning beyond the bare array-of-strings schema.

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

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

States a specific verb and resource: 'Get full details for specific memory IDs', and labels itself 'Layer 3', clearly distinguishing it from search_memory and memory_timeline. It also names query_memory as the replacement, making the tool's role easy to understand.

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 explicit automatic trigger conditions ('Call this when...'), an explicit exclusion ('Use query_memory instead'), and sequencing guidance ('filter first with search_memory'). This gives an agent clear when-to-use and when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly indicates a read-only operation by saying 'Get' and 'returns raw structured data', and it specifies the returned categories. It could go further with auth or failure behavior, but for a read-state tool this is solid.

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

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

The description is well-organized with clear sections for purpose, triggers, differentiation, and parameters. Every section earns its place, and the most decision-relevant information is front-loaded in the first sentence.

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

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

For a simple read tool with no annotations and no output schema, the description is complete enough: it covers what the tool returns, when to call it, how it differs from the main alternative, and the meaning of both required parameters. An agent has everything needed 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?

The input schema provides no descriptions and schema coverage is 0%, so the description must compensate. It does: session_id is explained as the session identifier, and agent_id is described as 'your agent ID' with a must-belong-to-session constraint. This adds meaningful guidance beyond the bare schema fields.

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

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

The description clearly states a specific action ('Get the current state of a collaboration session') and identifies the returned content: tasks, agents, and session state. It also distinguishes the tool from session_context by highlighting that this returns raw structured data rather than a formatted narrative.

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 includes an explicit 'AUTOMATIC TRIGGERS' section listing concrete situations for calling this tool, and it names the alternative session_context with a clear differentiation. This gives an agent strong guidance on when to select get_session_state over its closest sibling.

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. 'Get details' implies a read-only operation, and the note to 'see the plan and rules before using' hints at additional context, but the description does not explain return format, side effects, or prerequisites in concrete terms.

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 organized into a clear summary sentence, a trigger list, and a parameter note. It is concise and front-loads the core purpose, though the instruction to 'see the plan and rules before using' is somewhat vague and could be more actionable.

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 one required parameter and no nested objects, the description covers invocation and typical use cases well. However, there is no output schema and the description does not describe what the returned template details look like, which is a noticeable gap for an agent deciding whether this tool meets its need.

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

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

Schema description coverage is 0%, and the schema only provides the title 'Template Id' for the required parameter. The description compensates by defining template_id as a template identifier and supplying concrete examples like 'deep_research' and 'code_review', adding 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 clearly states that the tool 'gets details of a specific session template,' identifying both the action and the resource. It distinguishes itself from list-oriented siblings like list_templates by emphasizing 'specific,' but it does not explicitly name or contrast a sibling 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 description provides an 'AUTOMATIC TRIGGERS' section with concrete cases: reviewing a template before creating a session, checking tasks in a template's plan, or responding to user questions about a specific template. It gives clear guidance on when to use the tool, though it does not mention when not to use it or suggest 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 available, the description carries the behavioral disclosure burden. It clearly communicates what the tool returns (automatic call rate, paramerer hallucination rate, per-tool breakdown, etc.) and explicitly frames it as a development/evaluation tool. It does not explicitly state 'read-only' or side-effect behavior, but the 'Get...Returns metrics...' framing strongly implies a non-mutating analytic 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?

The description is well-organized with clear section headers, automatic triggers, return metrics, and parameter explanations. It is thorough without wasted words; each bullet adds useful information for an agent deciding whether and how to invoke the 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?

For a simple analytics tool with no output schema and no annotations, the description covers purpose, usage context, parameter meaning, metric output, and exclusions. An agent receives all important information needed to decide whether to call it and how to set the two optional 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?

Schema description coverage is 0%, so the description must compensation for the schema. It provides meaningful semantics for both parameters: 'days: Look back N days (default: 7)' and 'tool_name: Filter by specific tool (optional)'. This adds real value beyond the raw type/default information in the input 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 'Get tool usage analytics and optimization metrics', stating a specific verb and resource. It clearly distinguishes itself as a development/evaluation tool, which sets it apart from the many session, memory, and knowledge tools in the sibling list.

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 contains an explicit 'AUTOMATIC TRIGGERS' section with concrete call scenarios, such as measuring optimization effectiveness and tracking automatic vs explicit call rates. It further states that this is a development/evaluation tool and 'not needed for normal usage', which provides clear when-to-use and when-not-to-use guidance.

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

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

No annotations are provided, so the description must carry the burden. It implies a read-only search over artifact content and scopes the search to a session, which is helpful. However, it does not disclose what is returned, whether matching is case-sensitive, whether metadata is included, or any rate or access limitations.

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 well-structured with a one-line purpose, a trigger list, and a parameter list. It is concise and scannable, though there is minor redundancy between 'Search artifact content by keyword' and 'Find saved work by topic or term'.

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 purpose, triggers, and parameter semantics, which is strong for a search tool. However, it lacks information about the return format or result contents, and does not clarify how this tool differs from related search tools such as search_knowledge or grep_messages. Given no output schema exists, some return-behavior guidance would improve 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%, but the description compensates with a 'PARAMETERS' section that explains each parameter: session_id is 'Session to search', pattern is 'Search term (use simple keywords)', agent_id is 'Your agent ID', and created_by is an optional creator filter. This adds practical meaning beyond the raw 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 a specific verb and resource: 'Search artifact content by keyword' and clarifies it finds 'saved work by topic or term'. This clearly explains what the tool does, though it does not explicitly differentiate itself from sibling search tools like search_findings or search_knowledge.

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 'AUTOMATIC TRIGGERS' section gives concrete call conditions: when looking for artifacts mentioning a topic, needing prior analysis, or searching across saved work products. This provides clear context for when touse the tool, but it does not state when not to use it or name preferred 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 behavioral disclosure burden. It adds meaningful context: FTS5 semantics, OR/AND support, the agent_id membership requirement, a 100-result cap, and msg_types filtering. It does not describe the return format or ordering, which is a moderate gap for a tool without an output schema.

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

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

The description is well-organized into core purpose, triggers, search tips, and parameter notes, with the main purpose front-loaded. It is slightly repetitive around the 'use simple keywords' advice, but each section earns its place and supports correct usage.

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 parameters, triggers, and search syntax well, which is strong given no annotations and 0% schema coverage. However, there is no output schema and the description does not explain what the search result looks like, how results are ordered, or how pagination beyond the limit field behaves; this leaves an agent to infer the return structure.

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 fully compensate, and it does. Every parameter is explained with practical guidance, including the session scope, simple-keyword advice for pattern, the 'must belong to the session' requirement for agent_id, the default/max for limit, and an example for msg_types.

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 and resource: 'Search session messages by keyword' and clarifies the mechanism via FTS5 full-text search. The AUTOMATIC TRIGGERS section further distinguishes this tool from sequence-based message readers by stating it is for when you remember keywords but not the sequence number.

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 AUTOMATIC TRIGGERS section explicitly lists three situations that warrant calling this tool, such as looking for an earlier decision or checking whether a topic was discussed. It provides clear context for when to use it, though it does not explicitly name alternatives or state 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 behavior burden. It discloses the tool is a health check and what it returns (database size, finding count, vector index status). The 'Check' wording implies a non-destructive read-only operation, though it does not explicitly state that no mutations occur.

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

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

The description is concise and well-structured: a one-sentence purpose, a clear trigger list, and a short return summary. Every section earns its place, and the most important information is front-loaded.

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

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

For a zero-parameter diagnostic tool with no output schema, the description fully equips an agent to know when to call it and what to expect back. No critical context 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 and schema coverage is 100%, so there is no param semantic burden on the description. Baseline 4 is appropriate; no param explanation is needed.

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

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

The description states a specific verb ('Check') and a specific resource ('OpenLMlib database and vector index health'), and further clarifies the tool's purpose with return values. The automatic trigger list makes it clear this is a diagnostic/status tool, distinct from session or context checkers.

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 'AUTOMATIC TRIGGERS' section explicitly lists three concrete situations when to call this tool (debugging, system status queries, verifying initialization). It lacks explicit 'when not to use' or alternatlive mentions, so it does not fully meet the 5-level bar, but provides strong guidance.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the two behavior modes and states the return type: 'Dict with tool descriptions and usage information.' It does not detail error cases for unknown tool names, but for a help tool this level of transparency 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 compact and well-structured, with a clear first sentence, numbered call patterns, an Args section, and a Returns section. Every sentence adds practical value and the front-loaded purpose makes it easy to scan.

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

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

For a simple one-optional-parameter help tool with no output schema, the description covers invocation modes, parameter semantics, and return type. Nothing material is missing for an agent to select and call the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate for the schema's bare tool_name property. It explains that the parameter is optional, selects a specific tool, and provides a concrete example. This gives the agent enough semantic grounding to use the parameter correctly without enumerating all valid tool 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 opens with a specific verb+resource: 'Get help about all collab MCP tools or a specific tool.' This clearly distinguishes it from sibling help_library (library-focused) and makes the scope immediate. It also clarifies the two main invocation modes, leaving no ambiguity about the tool's 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 explicitly tells the agent when to call with no arguments versus with a tool_name, and gives an example ('create_session'). It does not explicitly contrast with help_library, but the 'collab MCP tools' scope and the name handle most of that differentiation. Some exclusion guidance would push this to a 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses the dual-mode behavior and the return type ('Dict with tool descriptions and usage information'), which is helpful for a non-destructive help tool. But it doesn't cover what happens with an invalid tool_name, whether output is markdown or plain text, or any error 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 tightly packed and front-loaded: a one-sentence purpose, two short usage-mode lines, then compact Args/Returns sections. Every sentence earns its place, and the examples make it actionable without bloat.

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 one optional parameter, no annotations, and no output schema, the description is largely complete: it explains both invocation modes, the parameter semantics, and the return shape. Minor gaps remain, such as behavior for an unknown tool name and the display format of the returned help, but nothing critical to a correct call.

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, and it does: it names the parameter, marks it optional, explains its effect, and gives concrete examples ('save_finding', 'create_session'). It stops short of explaining invalid-name handling or case sensitivity, but for a single optional parameter the meaning is well conveyed.

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

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

The description states a specific verb and resource: 'Get help about all OpenLMlib MCP tools or a specific tool.' It clearly identifies the two operation modes (no-arg summary vs. specific-tool detail). However, it doesn't explicitly differentiate from the sibling `help_collab`, so an agent might not immediately know which help tool to pick.

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 explicit call patterns: 'Call this with no arguments to see all available tools' and 'Call with a specific tool_name to get detailed usage instructions.' This is clear contextual guidance for both modes. It doesn't mention alternatives or exclude cases (e.g., when help_collab should be used instead), so the full when/when-not guidance 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 carries the full burden of behavioral disclosure. It only claims 'Auto-ingest' and 'NO manual logging needed', revealing nothing about side effects, required git access, data persistence, permissions, or error behavior. It reads as a value statement rather than a behavioral specification.

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 very short and front-loads the core action in the first sentence. The second sentence is somewhat redundant with 'Auto-ingest' but is brief and not bloated, earning its place as a clarifying emphasis. Brevity is fine, though it sacrifices 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?

For a tool with three parameters, no output schema, and no annotations, this is insufficient. An agent cannot determine how time_window_hours affects ingestion, what include_uncommitted covers, what session_id should reference, or what side effects to expect after the call.

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 mentions none of the three parameters. The meanings of session_id, time_window_hours, and include_uncommitted are left entirely to inference from names and defaults, adding no semantic value over the schema.

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

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

The description names a specific verb ('ingest') and a concrete resource ('session activity from git history'), making the tool's function immediately clear. It also differentiates itself from sibling tools like log_observation and save_finding_auto by its unique source (git history), even without 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?

The phrase 'NO manual logging needed!' implicitly positions this tool as the automated alternative to manual logging, suggesting when it might be used. However, it gives no explicit conditions, prerequisites, or comparison with specific sibling alternatives, leaving usage context mostly 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 provided, the description carries the full behavioral burden, and it succeeds: it discloses that the tool creates persistent resources, that initialization is permanent, and that calling it multiple times is safe because it will skip if already initialized. It does not claim read-only behavior or hide its mutating 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?

The description is appropriately structured with a one-sentence summary, explicit trigger lists, and a do-not-call list. Every sentence adds operational value and the most important guidance ('Call this ONCE') is front-loaded.

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

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

For a zero-parameter init tool with no output schema, the description covers everything an agent needs: when to invoke it, what it does, what resources are created, and its idempotent behavior. There is no missing context that would prevent correct invocation.

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

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

The tool has zero parameters and the input schema is empty, so there is nothing to document. The description correctly avoids inventing parameter details, and the baseline for zero-parameter tools is an appropriate 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 clearly identifies the tool as an initialization step: 'Initialize the OpenLMlib knowledge base' and explicitly states it creates 'the SQLite database, vector index, and required directories.' This distinguishes it from the many sibling tools that operate on an existing knowledge base, and the 'before using any other tools' directive makes its role unmistakable.

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 explicit automatic triggers (first use, database errors, user request) and explicit non-triggers ('Normal tool usage', 'Each session start'). It clearly tells the agent when this tool should be called and when it must not be called, which is exactly the usage guidance an agent needs for an initialization-only tool.

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

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

With no annotations, the description carries the full transparency burden. It discloses that up to 50 observations are retrieved, that query is optional and falls back to session focus, and that the call can happen mid-session. It does not detail potential side effects such as context-window consumption or whether repeated injections stack, which prevents a 5.

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

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

The description is well-structured with clear sections for triggers, workflow position, and parameters, with the core purpose front-loaded. There is slight redundancy between the triggers and workflow-position lines, but no meaningless 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?

The description covers purpose, triggers, parameter semantics, and retrieval behavior sufficiently despite having no output schema or annotations. It could more thoroughly differentiate from other retrieval-related siblings such as search_knowledge or retrieve_context, but the essential call path is 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%, but the description's PARAMETERS section adds meaningful semantics for all four parameters: session_id identity, query's optionality and fallback behavior, limit's default, and user_id's isolation purpose. This fully compensates 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?

The description clearly states the tool auto-injects relevant context from past sessions at any point during work. It explicitly contrasts with session_start, making the tool's mid-session purpose unmistakable and differentiating it from a key 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?

The description provides explicit automatic trigger conditions: needing a refresher, starting a new subtask, or being asked about prior learnings. It also notes that unlike session_start, inject_context can be called mid-session, giving clear usage guidance relative to an alternative.

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

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

No annotations are provided, so the description carries full behavioral burden. It does state the joining action and gives follow-up steps ('read the session_context above... then use read_messages'), but it does not disclose side effects such as whether joining mutates the session participant list, whether it is idempotent, or what happens with invalid session IDs.

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 well-structured with clear sections: purpose, automatic triggers, workflow position, parameters, and next steps. Every sentence adds operational value, and the core action is front-loaded. There is no redundant or filler text.

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

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

For a 3-parameter tool with no output schema, the description gives a complete invocation recipe: when to call, why, what parameters to provide, and what to do after joining. It does not explicitly describe return values or side effects, but these are not covered by an output schema and the join action is reasonably self-explanatory.

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 explain all parameters. It does so effectively: session_id is 'ID of the session to join', model is shown with examples, and capabilities is marked as optional with an example array. It does not explain the impact of capabilities on the session, which prevents a 5.

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

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

The description opens with a specific verb+resource: 'Join an existing collaboration session as an agent.' This clearly distinguishes it from sibling tools like create_session, leave_session, list_sessions, and read_messages without requiring schema inspection.

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 explicit AUTOMATIC TRIGGERS ('assigned work', 'need to participate', 'starting work as a worker or specialist') and a WORKFLOW POSITION ('after session is created and you have the session_id'). It gives clear context for when to call, though it does not explicitly state when not to call or 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, the description carries the behavioral burden. It adds 'gracefully' and 'clean exit' to set expectations, and notes that the reason helps other agents understand, implying the reason is visible to others. However, it leaves implicit what state changes occur, such as whether the session continues or whether other agents are notified.

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 well-structured with a lead sentence, a trigger list, a sibling-differentiation section, and a parameter list. Every section adds needed guidance without redundancies.

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 low-complexity tool with no output schema, it covers the action, when to use it, parameter semantics, and the key sibling distinction. It does not describe return values or failure behavior, but these are not essential for a straightforward leave operation.

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 provides no parameter descriptions (0% coverage), so the description fully compensates. It explains session_id as the session to leave, agent_id as the caller's ID, and reason as optional with a clear purpose of helping other agents understand.

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 ('leave a collaboration session') and an explicit design scope ('Clean exit for an agent'). It also differentiates itself from terminate_session, so an agent can tell this apart from the related session-ending sibling 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?

Lists concrete automatic triggers: tasks complete, moving to other work, or user request. It also explicitly states that this is for individual agents leaving and that only the orchestrator should call terminate_session, removing ambiguity about which session-ending tool to use.

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 transparency burden. It makes the read-only behavior clear by using 'List' and 'Browse', and it discloses that artifact content is not returned here by directing content retrieval to get_artifact. It also states the access constraint that agent_id must belong to the session, but it does not mention ordering, pagination, or result limits.

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 well-structured in short labeled sections and every sentence adds value: purpose, trigger conditions, routing to get_artifact, and parameter semantics. 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?

The description covers purpose, triggers, parameters, and the content/get_artifact distinction, which is strong for a filtered read-only list tool with no output schema. It does not describe the exact return shape or mention grep_artifacts as the alternative when searching artifact contents, but that is a minor gap rather than a critical omission.

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 provides 0% description coverage, but the description's PARAMETERS section fully explains each parameter: session_id as target, agent_id with the session-membership constraint, created_by as an optional creator filter with a natural-language example, and artifact_type with concrete allowed-type examples. This substantially compensates for the empty 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 a clear verb and resource: 'List artifacts in a session.' It also gives concrete artifacts ('work products, analyses, and summaries') and distinguishes itself from get_artifact by explicitly routing content retrieval there.

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 has an explicit 'AUTOMATIC TRIGGERS' section telling an agent exactly when to call it: checking saved work, finding an analysis, or avoiding duplicates before creating a new artifact. It also points to get_artifact when artifact content is needed, giving a clear alternative.

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

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

No annotations are provided, so the description carries the transparency burden. It adds useful behavioral context by stating findings are 'recent' and that the tool is for browsing, not targeted search. However, it does not define what 'recent' means, whether full findings or summaries are returned, or explicitly confirm there are no side effects, which would push it higher.

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 opens with a one-sentence summary, then uses labeled sections for triggers, search alternatives, and parameters. Every section contributes actionable information without filler. The structure is easy to scan and front-loads the most important context.

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 tool with two optional parameters, the description covers purpose, triggers, alternatives, and parameter semantics. The absence of an output schema means return fields are not described, and 'recent' is left undefined, leaving some uncertainty about ordering and response content. It is sufficient for correct 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?

The input schema provides only type and default values with 0% description coverage. The description fully compensates with a PARAMETERS section: 'limit: Max findings to return (default: 50, max: 200)' adds the maximum bound, and 'offset: Offset for pagination (default: 0)' explains its purpose. Both parameters are clearly and completely 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 states a specific verb and resource: 'List recent findings in the library.' It further clarifies the tool's scope with 'Use for browsing, not targeted search,' which distinguishes it from search_findings and retrieve_findings. The purpose is immediately clear and 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 includes an 'AUTOMATIC TRIGGERS' section with three explicit conditions: when the user asks to see all findings or browse, when wanting a sense of stored content, and when checking library contents after initialization. It also explicitly routes targeted search to search_findings or retrieve_findings. This provides both strong inclusion and exclusion guidance.

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

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

No annotations are provided, so the description carries the transparency burden. It conveys that results are compact summaries and that status relates to verification packets, implying a read-only listing behavior. However, it does not describe output shape, ordering, or any limitations.

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 terse and well-organized: a one-sentence summary, a trigger list, and a parameter list. Every section earns its place with no filler or redundant restatement.

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 list tool with no output schema, the description covers purpose, triggers, and parameter meaning. It still omits the set of valid status values and any detail about the returned summary fields, which an agent may need to interpret results effectively.

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 PARAMETERS section adds needed context: run_id is identified as a Co-Scientist run ID and status as an optional packet status filter. This surpasses the bare schema titles, but no allowed status values are given, leaving an important semantic 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 opens with a specific verb and resource: 'List compact hypothesis summaries for a Co-Scientist run.' It clearly identifies what the tool returns and the domain, and is distinct from sibling tools like start_hypothesis_verification or submit_hypothesis.

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?

An 'AUTOMATIC TRIGGERS' list explicitly states when to call this tool: inspecting generated hypotheses, selecting for verification, and checking which packets were sent. It does not mention when not to use it or name alternative tools, but the given triggers are concrete and actionable.

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

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

With no annotations, the description carries the full burden. It discloses the OPENROUTER_API_KEY requirement, one-hour result caching, and force_refresh bypass behavior. The word 'browse' implies a read-only operation, though pagination, rate limits, and exact return format are 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?

The description is front-loaded with purpose, followed by a compact AUTOMATIC TRIGGERS block, then requirements and a terse parameter list. Every section earns its place, and there is no filler or redundant prose.

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 and no output schema, the description covers purpose, triggers, prerequisites, caching, and all parameter semantics. It could be more complete by stating the exact return shape or pagination behavior, and by pointing to siblings like get_model_details for single-model details, but it is sufficient 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%, but the description's PARAMETERS section fully compensates by explaining all six parameters: search scope, provider examples, combined input+output price semantics, minimum context length, free-only filtering, and cache-bypassing force_refresh. This adds meaning well beyond the raw 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 clearly states a specific verb and resource: browse available models from the OpenRouter API, with filtering by provider, price, or context size. It does not explicitly differentiate from sibling tools like get_model_details or recommended_models, but the scope is evident and distinct enough for basic selection.

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

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

The description gives explicit automatic triggers: call when the user asks what models are available, when choosing a model for a collab session, or when comparing pricing/context limits. It does not mention when not to call or name alternative tools, but the usage context is clear and actionable.

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

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

With no annotations provided, the description carries the full burden. It discloses the scope ('sessions you've participated in'), explains the semantic distinction between 'terminated' and 'completed' statuses, and adds the limit maximum of 100 not present in the schema. It implies basic listing behavior by pointing to session_context for details but does not fully describe return format or pagination.

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 well-organized with clear sections for purpose, triggers, and parameters, and the core purpose is front-loaded. It is somewhat longer than strictly necessary because the trigger list contributes to usage guidance more than purpose, but each section earns its place with useful content. Minor redundancy in the first two sentences is acceptable as it clarifies 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?

For a simple tool with two optional parameters and no output schema, the description covers the key aspects: what it lists, when to call it, how to filter, and where to get further detail. It doesn't explicitly state the response shape or whether session IDs are returned, but the pointer to session_context implies that. Given the tool's low complexity, this is reasonably 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, and it largely does. It explains the allowed status values and their meanings, and clarifies the limit parameter's maximum, which the schema omits. The only minor gap is not explicitly stating the effect of a null status, though the default null implies no filtering.

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

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

States a specific verb and resource ('List collaboration sessions') and narrows scope with 'Browse sessions you've participated in.' The automatic triggers further clarify the tool's purpose, and the scope helps distinguish it from sibling tools like search_sessions or get_agent_sessions even without 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?

Provides an explicit 'AUTOMATIC TRIGGERS' section listing three clear scenarios for calling this tool, and directs agents to session_context for session details, which is an explicit alternative. However, it does not say when *not* to use this tool or mention alternatives like search_sessions for broader searching, so it falls short of a full 5.

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

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

With no annotations, the description carries the burden of indicating safety and side effects. 'List' and 'available' imply a read-only operation and the triggers clarify purpose, but the text never explicitly states that it does not modify state or what the response contains. This is adequate but leaves some behavior implicit.

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 one-line purpose is front-loaded, followed by a compact, scannable trigger list and a useful handoff to create_from_template. Every sentence adds value without redundancy.

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

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

For a zero-parameter read-only list tool, the description covers what it does, when to invoke it, examples of the expected workflow items, and the follow-up action. There is no output schema, but the return concept (a list of template names) is self-evident and well supported by the workflow examples.

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

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

The tool has zero parameters, so the baseline is 4 and there are no parameter semantics to document. The schema already exhaustively covers the empty 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 opens with a specific verb+resource ('List available session templates') and clarifies the domain ('Pre-built plans for common research patterns'). It also points to create_from_template as the next step, which implicitly distinguishes listing from creating and from get_template.

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

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

It provides explicit AUTOMATIC TRIGGERS covering the main call contexts: new session planning, explicit template requests, and recommended workflows. It does not explicitly state when not to use it or contrast it with get_template, so it falls short of a full 5.

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

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

No annotations are provided, so the description carries the full burden of explaining behavioral impact. It discloses that the tool captures tool outputs, that observations will be 'compressed and summarized for future retrieval,' and that this builds session memory. This gives the agent a clear model of the write side effect and downstream 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 well-structured with sections and front-loaded intent, but it repeats the same instruction multiple times: 'Call this after significant tool executions' appears in the triggers, workflow position, and general guidance. Some redundancy could be trimmed without losing 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 logging tool with no output schema and no annotations, the description covers purpose, parameters, trigger conditions, workflow position, and post-logging behavior. It does not mention the return value, but for a fire-and-forget observation logger this is a minor gap rather than a critical omission.

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%, but the PARAMETERS section compensates fully by defining every parameter in plain language. It explains session_id as coming from session_start, gives examples for tool_name, and clarifies what tool_input and tool_output represent. This adds meaning well beyond the bare schema titles and types.

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

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

The opening sentence clearly identifies the verb and resource: 'Log an observation from tool execution to build session memory.' This distinguishes it from sibling retrieval tools like query_memory and search_memory, which read memory rather than write it. The purpose is explicit and actionable.

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 explicit trigger conditions: call when a tool execution produces important or surprising results, when you want to remember what happened, or when building context for a session summary. It also provides a negative guideline: 'Don't log every single tool call - only significant ones with novel insights.' It does not name alternative write tools, but the when/when-not guidance is strong.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses useful traits beyond structured data: '~200 tokens/result' (output size/cost), the window behavior, and its 'Layer 2' pipeline position. However, it never states whether the operation is read-only or has side effects, and it offers no failure behavior or rate-limit context; the repetitive phrasing also dilutes the signal.

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 section layout (triggers, sequencing hint, parameters) is well organized and front-loaded with 'Layer 2.' But the same idea is stated three times: 'Get chronological context,' 'Returns narrative flow around observations,' and 'Provides timeline context for how observations relate to each other,' and the trigger bullets partially repeat this as well. It could lose ~30% of its words without losing information.

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

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

For a simple tool (2 flat params, 1 required, no output schema, no annotations), the description covers the essentials: purpose, when to invoke it, both parameter semantics, and a result-size hint. The main gaps are the absence of an explicit read-only/no-side-effects declaration and a precise return shape — but the tool's low complexity makes this close to 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%, so the description must compensate — and it does. It explains ids as 'List of observation IDs from search_memory' (tying the parameter to its upstream source) and window as 'Time window for context around each observation (default: "5m")' (semantics plus default value). Both parameters gain real meaning beyond the bare schema titles 'Ids' and 'Window.'

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+resource: 'Get chronological context for memory IDs' and clarifies the return as 'narrative flow around observations' and 'timeline context.' It distinguishes itself by positioning as 'Layer 2' to be used after search_memory, which separates it from siblings like topic_context, search_memory, and get_observations. An agent can readily tell what this tool does and how it differs from nearby 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 'AUTOMATIC TRIGGERS' section gives concrete when-to-use conditions: having observation IDs from search_memory, needing event sequence, or needing temporal relationships. It also gives the procedural hint 'Use AFTER search_memory to understand sequence.' It lacks explicit when-not-to-use guidance or named alternatives (e.g., when to prefer topic_context), so it falls just short of a 5.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states that the tool BLOCKS until messages arrive or timeout expires, and explains its role in continuous collaboration. It could add what happens on timeout or whether messages are consumed/destroyed, but the most important behavior is 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 well-structured and front-loaded, but repetitive: 'AUTONOMOUS LOOP tool', 'primary mechanism for agents to run continuous collaboration', and 'WORKFLOW POSITION: Main loop tool' all convey the same idea. The usage pattern is useful, but the text could be tightened without losing 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 polling tool with no annotations and no output schema, the description covers when to use it, how to use it, the blocking behavior, and all parameters. It lacks explicit details about timeout response behavior and differentiation from read-focused siblings, but overall it provides enough context for an agent to select and call the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does: all six parameters are listed with concise functional meaning, defaults for timeout and limit, and a special note that timeout=0 means no wait. Some entries like 'msg_types: Filter by message types' are terse, but sufficient for correct 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?

The description identifies a specific action ('Wait for and read new messages from a session') and clearly frames the tool as the main autonomous-loop communication mechanism. It is unambiguous about what the tool does, though it does not explicitly contrast itself with sibling tools like read_messages or tail_messages, which keeps it from 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 explicit trigger conditions: running an autonomous loop, waiting for other agents, and needing real-time collaboration. It also provides a concrete usage pattern with send_message and a repeat loop. However, it does not mention alternatives or state when not to use this tool, so it stops short of full exclusion guidance.

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

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

There are no annotations, so the description carries the behavioral burden. It discloses meaningful behavior: automatic 3-layer progressive retrieval, fast search, expansion of high-confidence hits, and chronological context for the periphery. It does not explicitly state the absence of side effects or describe the exact output shape, but it is far from opaque.

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 well-structured with trigger bullets, a short algorithm explanation, and a parameter list. It is readable and front-loads the key replacement fact. Some minor redundancy exists between the opening phrase and the later algorithm description.

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

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

Given the absence of an output schema, the description leaves the return format only vaguely implied ('expands...', 'provides chronological context'). It also does not help the agent choose among several closely related memory/retrieval siblings beyond search_memory. Triggers and parameters are covered, making it adequate but not 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 does: 'limit' is clarified as an internal fetch limit, and 'filters' comes with a concrete example. 'query' is only restated as 'Search query', so not every parameter gets equally substantive 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 clearly labels the tool as an auto-expanding retriever for memory and states its function: searching observations from past sessions and retrieving context on a topic. It also distinguishes itself from a sibling by explicitly declaring it 'REPLACES search_memory'.

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

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

It provides explicit automatic trigger conditions ('Call this when...') for the two main use cases. It also alerts the agent that this tool replaces search_memory, which gives clear selection guidance for that sibling, though it does not contrast with other related memory/retrieval tools.

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

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

With no annotations, the description carries the full burden. It discloses key behaviors: inclusive start_seq, exclusive end_seq, 500-message maximum, and agent_id session membership. It does not describe error cases or return format, but for a read-only range retrieval tool the coverage is solid.

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

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

The description is front-loaded with a one-sentence summary, followed by scannable trigger bullets and a compact parameter list. No filler or redundant content; each section earns its place by helping selection or 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?

Given the tool's moderate complexity and absent output schema, the description covers purpose, triggers, sibling differentiation, and all parameter semantics. It does not explicitly describe the return shape, but 'Read messages' clearly implies the returned content, and nothing needed to select or invoke the tool is missing.

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

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

Schema description coverage is 0%, but the inline PARAMETERS section fully compensates. Every parameter gets meaningful guidance: start_seq should come from message metadata, end_seq is exclusive with a max range of 500, and agent_id must belong to the session. This adds significant 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 opens with a specific verb and scope: 'Read messages in a specific sequence range'. It clearly distinguishes itself from read_messages by focusing on range-based retrieval rather than 'new' messages, so an agent can differentiate it from related message 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 'AUTOMATIC TRIGGERS' section explicitly lists when to call the tool (e.g., 'A message references an earlier seq number', 'review a specific exchange between agents'). It also names the alternative read_messages and explains the difference, giving clear when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description carries the transparency burden and does disclose important behavior: offset-tracking, returning only unseen messages, immediate return, and authorization/offset role of agent_id. It could go further by stating whether reading consumes/marks messages as seen and what happens when no messages exist, but the core behavior 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?

The description is front-loaded with the core definition, then organized into scannable sections (AUTOMATIC TRIGGERS, DIFFERENCE, WORKFLOW POSITION, PARAMETERS). Each section adds distinct value and no sentence is redundant.

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

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

The description covers purpose, usage context, sibling differentiation, and all parameters, which is strong for a read operation. The only notable gap is the absence of any return-shape information, which matters because there is no output schema, though the message model is likely known.

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 fully compensates by explaining every parameter's role: session_id, agent_id's authorization/offset purpose, limit's default/max, msg_types with an example, and from_agent filtering. This is far 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 operation ('Read new messages from a session') and a key behavioral differentiator ('Returns only unseen messages (offset-tracked)'). It is clearly distinguishable from sibling tools like poll_messages, tail_messages, and read_message_range.

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

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

It provides explicit AUTOMATIC TRIGGERS with concrete situations, names the relevant alternative (poll_messages), and explains when to choose that alternative ('blocking waits in autonomous agent loops'). Workflow position further clarifies when the tool fits.

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 returns 'pre-filtered best choices,' but does not clarify whether this is a read-only operation, what the result format looks like, whether it reflects real-time availability, or whether any side effects or prerequisites exist. For a simple retrieval tool this is thin.

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 well-structured with a one-line summary, automatic triggers, task types, and a parameters note. It is easy to scan and front-loads the core purpose. Slight redundancy exists between 'Get recommended' and 'Pre-filtered best choices' and between the first trigger and 'User asks for model recommendations,' but it remains tight.

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, no annotations, and no output schema. The description explains what the tool does and what input to provide, but it does not describe the return shape or what the agent should do with the results, such as whether it returns model IDs, names, or full metadata. This leaves an agent guessing about downstream use.

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 provides only the parameter title 'Task Type' with no description, so the description must compensate. It does so by explaining task_type as 'What the model will be used for' and listing valid values: research, coding, analysis, writing, summarization, orchestrator, worker. This adds meaningful guidance beyond the raw 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 a specific verb and resource: 'Get recommended OpenRouter models for a specific task type.' It clearly differentiates this from sibling tools like list_models by framing it as pre-filtered recommendations rather than a full catalog browse. The listed task types further anchor what the tool covers.

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 an explicit 'AUTOMATIC TRIGGERS' section with concrete scenarios such as 'What model should I use for X?' and 'Choosing models for a session without browsing the full catalog.' It gives clear context for when to call, though it does not explicitly mention when not to call or name alternative tools such as list_models.

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 clearly discloses the sanitization behavior and injection-risk avoidance, which is the most important behavioral trait. It does not explicitly state read-only/no-side-effects status or output shape, but 'Retrieve' and the sanitization context cover the primary 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 front-loaded with the core purpose and then organized into clearly labeled sections for triggers, distinction, error recovery, and parameters. It is scannable and mostly free of fluff, though the trigger bullet list is slightly redundant and 'Use retrieve for raw data' could be worded more precisely.

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 5-parameter tool with no output schema or annotations, the description provides usage triggers, sibling differentiation, a no-results fallback, and parameter semantics. It could add more detail about the return block format and whether tags are comma-separated or repeated, but the essential call-time guidance 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. The PARAMETERS section names all five parameters and adds meaningful details: query is required, project/tags/confidence_min are filters, and final_k has a default of 10. It stops short of describing types or formats for tags and confidence_min, so it is not a 5.

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

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

States a specific verb and resource: 'Retrieve findings and return them in a sanitized format safe for LLM context.' It also explicitly differentiates from retrieve_findings by contrasting 'sanitized context block' with raw data. An agent can understand what this tool does and how it differs from its closest 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?

Provides an explicit 'AUTOMATIC TRIGGERS' list with concrete scenarios. It also distinguishes this tool from retrieve_findings and gives a fallback instruction to use search_findings when no results are returned. The only minor ambiguity is 'Use retrieve for raw data,' but context makes clear this refers to retrieve_findings.

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 behavioral disclosure burden. It explicitly states this is a READ OPERATION, requires no confirmation, is safe to call freely, and automatically combines semantic and lexical search with reranking. This is valuable transparency, though it does not mention return format, pagination, or potential edge cases.

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 well structured with clear headings, bold labels, and front-loaded purpose. It is longer than minimal but each section earns its place by providing selection triggers, parameter semantics, and safety context. Minor redundancy exists around the read-operation and safe-to-call messaging.

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 nine parameters, no annotations, and no output schema, the description does substantial work: it explains the retrieval mechanism, when to call it, parameter semantics, and confirmation status. It is missing return-value details and the date-range parameters, but overall it is sufficiently complete for an agent to select and invoke 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%, so the description must compensate. It explains query, project, tags, confidence_min, final_k, and the advanced semantic_k/lexical_k parameters, including defaults and purpose. However, created_after and created_before are not described at all, leaving two parameters without semantic 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 opens with a specific verb and resource: 'Run intelligent retrieval combining semantic similarity and keyword matching.' It clearly distinguishes this tool from simple keyword search by highlighting the combined semantic and lexical mechanism, and the AUTOMATIC TRIGGERS section further clarifies its role.

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

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

The description provides explicit when-to-use triggers and workflow position: use when keyword search returns insufficient results, for concept/topic exploration, or for a research question. It names search_fts as the alternative, though that exact sibling is not present in the provided sibling list, which introduces slight ambiguity; otherwise the usage guidance is strong.

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

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

With no annotations provided, the description carries the behavioral transparency burden. It usefully discloses that artifacts are stored as files with metadata indexed in SQLite and that shared=True saves to a shared directory. However, it does not mention overwrite behavior, return value, idempotency, or potential failure modes, which would be valuable for a write 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 well-structured with clear sections for triggers, workflow position, and parameters, making it easy to scan. There is minor redundancy between 'AUTOMATIC TRIGGERS' and 'WORKFLOW POSITION', but overall each section 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?

The description provides enough context for an agent to decide when to use the tool and how to fill parameters. It lacks output schema information and does not clarify the relationship with save_finding, but for a save operation the provided details are largely sufficient.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. All seven parameters are listed with concise but meaningful explanations, including artifact_type examples and the effect of shared=True. This adds value beyond the raw 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 clearly states the tool saves a research artifact (finding, analysis, summary) to the session, with specific examples and automatic trigger conditions. It is unambiguous about the action and resource, though it does not explicitly distinguish itself from the sibling save_finding 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 description provides explicit trigger conditions for when to call the tool, including completing significant analysis, writing important code/documentation, and saving detailed analyses. It also gives a clear exclusion ('not for inline messages'), though it does not mention alternative tools like save_finding for comparison.

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 responsibility and does so thoroughly. It discloses the duplicate-check behavior with a similarity threshold, the confirmation requirement, session awareness warnings, and that this creates persistent data. These are meaningful behavioral traits beyond the input schema.

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

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

The description is long but exceptionally well organized into labeled sections: automatic triggers, exclusions, workflow, read-before-write, session awareness, confirmation tier, and parameters. Each section adds necessary information without filler, and the most important usage guidance is front-loaded.

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

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

For a complex 11-parameter write tool with no annotations and no output schema, the description covers triggers, exclusions, parameter semantics, duplicate handling, confirmation, and session dependencies. It falls slightly short by omitting three parameters and not specifying the success response shape, but overall it is nearly 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 is the only source of parameter meaning. It explains most parameters well with usage guidance (confidence scale, confirm safety gate, evidence/reasoning/caveats purpose). However, it omits full_text, finding_id, and proposed_by, leaving their semantics undocumented, which keeps this from a 5.

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

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

The description opens with a specific verb and resource: 'Save critical research findings, discoveries, and insights to persistent library.' It clearly differentiates from siblings by listing automatic triggers and explicit DO NOT CALL cases, so an agent knows this is for persistent insight storage rather than temporary notes or tool outputs.

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 explicit when-to-call triggers, a DO NOT CALL list, workflow positioning, and a tip to use search_findings first for deduplication. This gives strong, unambiguous guidance on when to invoke this tool versus alternatives.

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