Dactic

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

Annotations already declare readOnly, non-destructive, idempotent, and closed-world; the description adds real context beyond them by naming the two answer channels and issuing an explicit privacy boundary ('never another user's data, even for org admins') that reinforces openWorldHint=false with an unstated edge case. It also states the empty-result behavior, which annotations cannot convey.

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

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

Three tight sentences with no filler, and the core purpose is front-loaded before the privacy caveat. The middle clause ('matches holds evidence... your_profile holds...') is dense and reads like output-field documentation squeezed into a purpose statement, but nothing is redundant.

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

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

An output schema exists, so the return shape needn't be re-explained, and annotations cover the safety profile. However, for a 4-parameter tool with 25% schema coverage, the description leaves source_type and limit entirely unexplained and gives no routing guidance among heavily overlapping siblings.

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

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

Schema description coverage is only 25% — just the board parameter is documented, and its filtering side effects (dropping non-Monday evidence) live in the schema, not the description. The description never explains source_type or limit, leaving two of four parameters undocumented in both places.

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: 'Answer a question from your own Dactic context,' and even sketches the answer's two sections (matches, your_profile). It is clear what the tool does, but it never names an overlapping sibling such as query_work_dataset, search, or check_against_policy, so an agent must infer differentiation from the schemas.

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

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

There is no guidance on when to choose this tool over the many retrieval siblings (search, query_work_dataset, get_entity_context, retrieve_similar_cases). 'When nothing matches, say so' is an answering behavior, not a routing rule, and no prerequisites or exclusions are given.

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

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

Annotations already declare this readOnly, idempotent and non-destructive, so the safety profile is covered. The description still adds real behavioral value: findings quote policy and draft verbatim with a suggested change, a count of policies checked is returned, and not_assessed is explained as a failure mode where applicable policies are listed instead. It does not discuss limits such as the 8000-character draft cap or latency.

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 purpose and the advisory framing are front-loaded, and the failure mode is appended last where it belongs. The sentences are dense but each carries information; the 'never a compliance sign-off' clause earns its place as a usage guardrail.

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?

An output schema exists, so the rich return-value detail need not be repeated here, and the not_assessed behavior is a useful addition. Against a four-parameter tool with zero schema descriptions, however, the missing guidance on context and categories leaves the definition incomplete 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%, so the description carries the full burden. It implicitly maps the three kinds (reply, plan, action) but says nothing about 'context' or 'categories', nor about the length cap on draft. Half the parameters remain undocumented in both the schema and the description.

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

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

The description gives a specific verb and resource — an advisory check of a draft reply, plan, or action against the department's Dactic policies — which is clearly distinct from retrieval siblings like get_policy. It does not explicitly name an alternative tool, so it stops short of full sibling differentiation.

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

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

Usage is implied by 'draft reply, plan or action' and the framing constraint that results must be presented as advice, never a compliance sign-off. However, there is no explicit when-to-use guidance nor any statement of when another tool (for example get_policy) would be the better choice.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds value beyond them by defining the output vocabulary (fresh/stale/empty/unknown), promising a recommendation for anything not fresh, and disclosing the org-admin gate on scope=org. Since an output schema exists, it correctly does not spend words on return formatting.

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

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

Two compact sentences with the core question front-loaded and the surface/status enumeration following immediately. The opening rhetorical question is slightly redundant with the title, and the parenthetical surface list is dense, but no sentence is wasted.

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

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

With a full output schema and rich annotations handling structure and safety, the description only needs to convey intent, verdict semantics, and the permission model—all of which are present. The one residual gap is that the third parameter, agent_id, is never explicitly connected to the "optionally one agent" surface.

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 carry parameter meaning and it only partly does: refs is explained as references sourced from other Dactic tools, and scope=org is tied to org admins, but the "me" value is left implicit and the agent_id parameter is never named—only the vague phrase "optionally one agent" appears. The maxItems=50 limit, the array element format, and the agent-vs-surface interaction are undocumented anywhere.

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 check operation and enumerates exactly what is inspected (app sync, confirmed knowledge, terminology, approved playbook, department policies, skills, optionally one agent) plus the four possible verdicts (fresh, stale, empty, unknown). That is far more concrete than the title's rhetorical framing, and it is distinguishable from neighbors like get_sync_status or get_context_delta, though no sibling is named explicitly.

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

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

"Pass refs from other Dactic tools to check specific items" and "scope=org is for org admins" give real usage conditions, including an authorization constraint. However, there is no guidance on when to prefer this over find_context_gaps, get_sync_status, or get_context_delta, which occupy adjacent territory; usage is implied rather than routed.

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?

Beyond the read-only, idempotent, and non-destructive annotations, it discloses the stored-artifact scope, accessibility constraint, comparison categories, and the important limitation that missing guardrails/parameters remain unknown. The explicit statement that it never rolls back or deploys is consistent with the annotations and clarifies the absence of operational side effects.

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

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

Three compact sentences front-load the operation and scope, then provide comparison details, a limitation, and a side-effect boundary. Every clause contributes useful selection or invocation information without 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?

Together with the safety annotations and output schema, the description supplies the essential scope, comparison content, and interpretation caveat needed to use the tool. The remaining gaps are operational: discovering valid versions and understanding when platform should be supplied are left to inference.

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

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

With 0% schema description coverage, the description partially compensates by establishing that the versions are stored artifacts and must belong to the same accessible agent/platform. However, it does not explain baseline/target semantics for from_version and to_version, how to discover valid version integers, or how agent_id interacts with the optional platform parameter.

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

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

The description precisely states that the tool compares two stored artifact versions of the same accessible agent/platform and identifies instruction diffs and skill additions/removals as the comparison content. Explicitly excluding rollback and deployment also distinguishes it from action-oriented siblings such as deploy_agent.

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 scope makes it clear to use this for a version-to-version artifact diff, while 'Never rolls back or deploys' supplies a useful when-not boundary. It does not name alternatives for deployment, rollback, or single-version inspection, or provide prerequisites for finding valid versions.

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?

Adds substantial context beyond the annotations: the call runs in the background and returns a task_id that must be polled via get_task_status, and the output is only a draft saved for review in the Dactic app, never deployed from here. That safely characterizes a non-destructive but state-creating operation far better than the bare destructiveHint=false. The remaining gap is that the idempotency and retry behavior implied by idempotentHint=false and the idempotency_key parameter is never discussed.

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?

Information is front-loaded: what it does, when to use it, what to collect first, then how it executes. Every sentence carries a distinct role, though the sequence of separate constraint statements at the end could be tightened.

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 nine-parameter, background-executing creation tool with an output schema, the description covers the essentials an agent needs: preconditions, task polling loop, draft-only outcome, and the platform limit (claude only; Monday agents are created in the app). Return-value detail is rightly omitted because an output schema exists.

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 does the heavy lifting; it supplies meaning for purpose, steps, trigger, resources, constraints, and the platform restriction on target_platform, which is most of the required semantic load. It leaves name, notes, and especially idempotency_key unexplained, so partial compensation rather than full.

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 ('Draft a new Dactic agent, and the new skills it needs') plus the input source ('from a process the user describes in this chat'). It explicitly distinguishes itself from the sibling synthesize_agent by noting that synthesize_agent only reuses existing skills, so an agent can route correctly without opening either schema.

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

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

Gives an explicit selection condition ('use this when the user's existing skills don't cover the work') and names the alternative it is not. It also spells out prerequisites: gather purpose, ordered steps, trigger, resources/tools, and prohibitions, then confirm the summary before calling.

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

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

Annotations already declare this is a non-read-only but non-destructive, idempotent, closed-world mutation. The description adds real context beyond that: prerequisite checks on skills, source approvals, and readiness/billing gates, plus the fact that it returns a background task rather than a completed deployment. It stops short of describing failure modes, error surfaces, or what the preview contains.

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

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

The two-phase confirmation instruction is front-loaded in the first sentence, and the remaining sentences each add a distinct fact (prerequisites, task-based return, idempotent lookup). It is dense but no sentence is filler; a slight trim of the gate list would make it tighter.

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

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

With an output schema present, the description needn't explain return values, yet it still tells the agent the result is a background task to poll via get_task_status. For a three-parameter mutation with a mandatory human-approval loop, the main gap is the provenance of definition_id and the expected shape of target_workspace.

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 carry meaning, and it does fully explain confirmation_code (omit for preview, supply to execute) and implies definition_id is a saved draft and target_workspace is the destination. However, it never says where definition_id comes from or what target_workspace expects as a value, leaving two required parameters partly undocumented.

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 plus a scope constraint: 'First deployment of your selected saved draft,' and clarifies that an existing deployment is identified without redeploying. That contrast separates it from sibling tools like invoke_agent, load_agent, and recommend_agent without requiring the schema to be opened.

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?

Prescribes the exact call sequence: call without confirmation_code for a preview, show the preview to the user, obtain authorization, then repeat with the same definition/target and the code. It also routes follow-up work to get_task_status for polling, so both when-to-use and what-to-do-next are 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety, repeatability and closed-world scope are fully covered structurally. The description adds only that the response is 'full text' plus 'a link to it', and since an output schema exists, return-shape detail carries limited extra value.

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

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

A single front-loaded sentence with the verb and resource first and the input source attached. Nothing is redundant and no sentence is wasted.

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

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

This is a simple one-parameter read tool with rich annotations and an output schema, so the description only needs to cover purpose and input source, both of which it does. It falls short of full completeness only in not noting what happens when the id is not found.

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% for the single 'id' parameter, so the schema alone does not say what the value is. The description partially compensates by specifying that the id is the one returned by search, which is meaningful provenance, but it gives no format, type, or failure behavior for an unknown 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?

States a specific verb and resource: fetch the full text of one Dactic item. The clause 'by the id search returned' implicitly separates it from the sibling 'search' (which produces ids rather than full text), so an agent can tell the two apart without opening either schema.

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

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

The phrase 'the id search returned' gives a workflow cue that this tool follows search, which is useful implied usage. However, there is no explicit guidance on when not to use it, nor any mention of near-neighbors like get_entity_context or retrieve_similar_cases that also return content, so routing among the many get_*/retrieve_* siblings is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine behavioral information beyond that: results are partitioned into blocking and nonblocking gaps, and the tool explicitly will not resolve unknown requirements or execution permissions. That second point is a real scope limitation an agent needs when interpreting a clean result, though nothing is said about cost, latency, or whether assessment is deterministic across repeats.

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

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

Two sentences, front-loaded with the operation, with no filler or repeated title text. The first sentence is dense with a comma-separated list that reads as a noun-phrase pile-up, but every clause still carries 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?

An output schema exists, so return values need no explanation, and the annotations cover safety. What remains missing is substantial: no explanation of the four inputs despite 0% schema coverage, and no guidance on when this assessment is the right call versus the many sibling tools that also inspect agent context. For a tool whose entire value depends on how the caller populates required versus available inputs, that gap is material.

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% across four parameters, so the description carries the full burden and largely fails it. It never mentions task, agent_id, required_inputs, or available_inputs, nor the distinction between what is required versus merely available — the very distinction that drives the gap analysis. The phrase 'available knowledge, skills, policies...' gestures vaguely at the input domain without mapping to any parameter.

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

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

The description names a specific verb ('assess task preparation') and an explicit resource scope: knowledge, skills, policies, terminology, and sync readiness. An agent can form a concrete picture of the operation and its output class (blocking vs nonblocking gaps). It does not, however, distinguish this tool from adjacent siblings such as check_freshness, get_sync_status, or check_against_policy, which cover overlapping surface area.

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

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

There is no when-to-use guidance, no precondition, and no named alternative. The closing clause about unknown requirements and permissions is a scope caveat, not a routing rule, so an agent has no signal for choosing this over check_against_policy or get_context_bundle.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description is not required to restate them. It does add genuinely non-obvious behavior: the response is deep and potentially large (complete instructions plus every skill's full procedure) and it enforces user-level isolation. It stops short of saying what happens when the id does not exist or is owned by someone else (empty vs error), which is the one behavioral gap that matters for calling it correctly.

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?

Effectively one dense sentence plus a short scoping clause, with the identifying key ('by id') and the returned payload front-loaded. The parenthetical breaking out skill sub-fields earns its space by telling the caller how deep the response goes. No filler or restatement of the title.

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

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

For a two-parameter read tool with an output schema and full annotations, the description covers the essential shape and even describes the return payload. However, it omits the undocumented 'enrich' flag and is silent on not-found/unauthorized behavior, both of which are decision-relevant for a per-user lookup. Reasonably complete, but short of what a lookup tool with a zero-coverage schema needs.

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 carries the full burden, and it only partially does so. 'By id' conveys the meaning of agent_id, but the second parameter, the boolean 'enrich', is never mentioned anywhere in the description or schema, leaving an agent to guess whether it expands skills, inlines procedures, or changes cost and payload size. Two undocumented parameters at 0% coverage is a material 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 gives a specific verb and resource ('Get one of your Dactic agents by id') and enumerates exactly what is returned: name, platform, status, complete instructions, and every skill with its full procedure. That is far more concrete than a generic getter. It does not explicitly distinguish itself from near-name siblings such as load_agent or get_entity_context, which keeps it at 4 rather than 5.

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

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

Usage is only implied: 'by id' tells an agent this is the direct-lookup path as opposed to list_agents or search, but the description never states when to prefer it over load_agent or when not to call it. The ownership note ('never returns another user's agent') functions as an implicit precondition rather than stated guidance. Adequate but leaves the agent to infer routing against several plausible siblings.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful behavior the annotations cannot: whole lower-priority items are dropped to fit token_budget and the dropped items appear in "omitted", and unresolved terms are listed rather than guessed. It does not mention failure modes or what happens when nothing matches the task.

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 purpose and the usage cue are front-loaded in the first clause, and every subsequent sentence adds a concrete content guarantee or truncation rule. The semicolon-chained middle is dense but not padded; 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?

An output schema exists, so return shape need not be explained, and the description still covers the key output semantics (omitted list, citations, freshness summary). For a four-parameter aggregation tool this is nearly complete, with only the task parameter's expected content and budget range left implicit.

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

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

Schema description coverage is 0%, so the description must carry the load, and it largely does: it explains the agent_id branch, the truncation behavior of token_budget, and its enumeration of content types maps onto the include enum values. The required task parameter (max 2000 chars) and the 1000-16000 budget range are left unexplained.

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

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

The description states a specific verb and resource ("get everything a task needs from Dactic in one call") and enumerates the payload: instructions/skills, confirmed knowledge, department policies with citations, confirmed term meanings, and a freshness summary. That is far beyond a restatement of the name. It loses a point because near-siblings such as get_context_delta, get_user_context, and get_entity_context are never named, so an agent must infer how this differs from them.

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

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

"Use it before doing a task, especially when running an agent" gives clear timing context, and the with/without agent_id branches tell the agent which mode to pick. There are no explicit when-not conditions or named alternatives, so it stops short of full routing 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?

Annotations already declare the read-only, idempotent, closed-world, non-destructive profile, so the description's added value is the delta semantics: snapshot differences rather than every intermediate event, and the fact that the host retains the cursor. It also discloses the invalidation conditions (expiry, changed scopes/permissions) that force a fresh baseline, which an agent cannot derive from annotations alone.

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

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

Three dense sentences with the core behavior front-loaded, then fallback behavior, then output-vs-event semantics. No filler or restatement of the title.

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

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

For a two-optional-parameter read tool with an output schema, this is nearly complete: it covers baseline fallback, cursor lifetime, invalidation, and the difference between snapshot deltas and change events. Minor gaps remain around default include behavior and whether the returned cursor is usable for the next call, though 'the host retains the cursor' mitigates the latter.

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

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

With 0% schema description coverage, the description must carry the parameter meaning, and it does: cursor is optional (omit for baseline), is host-retained, and can go stale or be invalidated by permission changes. 'Permitted knowledge and published policies' maps onto the include enum values. The 64-character bound and the default behavior when include is omitted are left only to 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 opens with a specific verb and resource ('Retrieve added/updated/removed permitted knowledge and published policies') and pins down the delta semantics ('since an actor-bound snapshot cursor'). It separates the tool from bundle/context siblings implicitly by framing it as a diff against a cursor, but it never names an alternative tool, so an agent must infer differentiation.

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

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

It gives clear operational guidance: omit the cursor for a bounded baseline, and re-baseline when the cursor expires or scopes/permissions change. That covers the main decision points and error recovery, but it offers no explicit routing against siblings like get_context_bundle or check_freshness.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. Beyond that, the description adds genuinely useful behavior: the traversal follows only *explicit stored* links, is 'bounded', and returns relationship bases, citations, and missing-link gaps — plus the strong negative rule that text similarity never establishes a dependency, which prevents an agent from misreading it as semantic search.

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

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

Three tight sentences with the core action front-loaded, then the return contents, then the key exclusion rule. Dense but every sentence carries information; the phrasing is jargon-heavy but not padded.

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

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

An output schema exists, so return values need not be fully specified, yet the description still summarizes them usefully. Scope, preconditions, and the semantic-similarity exclusion are covered; the only gap is that 'bounded' is never tied to the limit parameter or a concrete traversal depth.

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% for three parameters, so the description must compensate. It partially does by enumerating the entity types (board, agent/project, term), which maps directly onto the entity_type enum, but it says nothing about entity_id format or what limit controls and how 'bounded' relates to 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 states a specific verb+resource: it 'follow[s] bounded explicit stored links' from a board, agent/project, or term, which is a precise characterization of graph traversal rather than search. It is distinguishable from generic retrieval siblings like get_context_bundle or ask_knowledge, though it never names a specific sibling to contrast with.

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

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

Usage is implied through qualifiers like 'approved board', 'accessible agent/project' and 'confirmed term', suggesting these must be pre-validated before calling. However, there is no explicit when-to-use/when-not-to-use guidance relative to siblings such as find_context_gaps, get_context_bundle, or retrieve_similar_cases, leaving the agent to infer routing.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile needs no restating. The description adds one genuinely non-obvious behavioral note — that observed state transitions do not imply immediate agent change — which manages expectations in a way annotations cannot. It stops short of saying whether state is polled, final, or how stale it may be.

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

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

Two short sentences with the purpose front-loaded and the caveat trailing as a qualifier. No filler or repetition, though 'Follow' is a slightly imprecise verb choice where 'Get' or 'Check' would be sharper.

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?

An output schema exists, so return values need no explanation, and the tool is a simple one-parameter read. Still, the definition leaves both the parameter contract and the call context (when, how often, and after what) to inference, which is a noticeable gap even for a low-complexity 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?

Schema description coverage is 0% and the single parameter feedback_id has no description in the schema. The description gestures at provenance ('your submitted agent feedback'), which implies the ID comes from submit_agent_feedback, but it never says what form the ID takes, whether it must be one you own, or what happens with an invalid ID. With low coverage the description should compensate and largely does not, though the name itself carries most of the meaning.

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 resource (the recorded processing/application state of submitted agent feedback) and implies the natural pairing with the submit_agent_feedback sibling. The verb 'Follow' is softer than 'Get' or 'Retrieve', but the object of the lookup is unambiguous enough that an agent can tell this apart from submit_agent_feedback or get_task_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?

Usage is only implied: 'your submitted agent feedback' signals this is called after submit_agent_feedback, but the description never states that sequencing explicitly or names any alternative. There is no when-not guidance, so an agent must infer that this is a post-submission polling tool rather than a general status endpoint.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. On top of that the description adds genuinely useful behavior the annotations cannot convey: the confidence rubric per entity type and the guarantee that it "Never repeats evidence text", which tells the agent what the response will and will not contain. Missing is what happens for invalid or stale refs.

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

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

Purpose and scope are front-loaded in the first sentence, and the bulk of the text is a tightly structured, parallel rubric covering all seven entity types. The rubric is dense but every clause defines a distinct confidence tier, so it earns its space; a reader still has to parse a long single block to find the rule for one type.

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

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

With a trivial one-parameter input, a declared output schema, and full annotation coverage, the description supplies everything needed to call it correctly plus the interpretation guide for the returned confidence levels. The only omission is edge-case behavior for unknown or expired refs, which is minor for a read-only lookup.

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 lone `refs` property has no description in the schema, so the description must carry the load — and it does: it explains that refs are opaque identifiers obtained from other Dactic tools and that 1-20 are accepted. That is materially more than the bare array-of-strings schema conveys; only the per-item string format remains unspecified.

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?

"Describes each item's source and a confidence of high, medium or low ... with the rule that applied in `basis`" is a specific verb-plus-resource statement, and the phrase "For refs returned by other Dactic tools" positions it as a follow-up/provenance step rather than a primary retrieval tool like get_entity_context or fetch. It stops short of naming an actual sibling, so the differentiation is implied rather than explicit.

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

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

The description gives a clear trigger condition: call this when you hold refs produced by other Dactic tools, and it caps the batch at 1-20. It does not state when NOT to use it (e.g., when a ref is unknown or when freshness, not provenance, is the question) or point to alternatives for that case, which keeps it below 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?

Annotations already cover read-only, idempotent, non-destructive and closed-world, so the safety profile is handled. The description adds real behavioral context beyond them: results include the source document, a 'coverage' indicator discloses whether all policies or only closest matches were returned, and the not_found outcome when nothing is published is stated up front.

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

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

Three sentences, front-loaded with the core purpose before the query-mode caveat and the failure case. Dense but every sentence carries information; the parenthetical about 'all of them ... else closest matches' is slightly packed but earns its place by explaining coverage.

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?

An output schema exists, so return-value structure needn't be described, and the description still helpfully flags coverage and not_found. What is missing is any meaning for three of the four parameters and any sibling routing guidance, which leaves gaps for a tool sitting next to check_against_policy and ask_knowledge.

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

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

Schema description coverage is 0% and all four parameters are undocumented in the schema, so the description carries the full burden. It explains only 'query' (applicability matching, ranking behavior) and leaves policy_id, category and limit completely undefined, so an agent cannot tell whether policy_id fetches a single policy or how limit interacts with the 'all of them when few' behavior.

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

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

States a specific verb and resource ('Get your department's current policies with their source document'), which is far clearer than the bare name. It implicitly separates itself from check_against_policy (evaluation) and ask_knowledge (Q&A), but never names those siblings explicitly, so the differentiation is inferred rather than stated.

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 explains the two usage modes well: no query returns all current policies, a query returns applicable policies ranked by relevance with 'coverage' signaling whether the set is complete. However, it gives no guidance on when to choose this over check_against_policy or ask_knowledge, which is the main routing decision an agent faces among these siblings.

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 annotations already establish a read-only, idempotent, non-destructive, closed-world operation. The description adds useful scope and result detail through "your" skills and "full procedure," but leaves whether L3 is fixed or merely a default unclear.

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

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

The single sentence is compact and front-loads the retrieval action and resource. The ID and L3 details add specificity without filler, though the final clause could express default-versus-fixed behavior more clearly.

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?

Annotations and the output schema cover safety and response shape, so extensive return-value documentation is unnecessary. However, the description does not fully compensate for the undocumented parameters, particularly disclosure-tier behavior and skill ID discovery.

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

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

With 0% schema description coverage, "by id" adds little beyond the skill_id name, although "full procedure" usefully explains L3. The description does not explain the L1 or L2 enum values, the optional parameter's default, or where to obtain a skill 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 clearly states the action and resource: retrieve one Dactic skill by ID, including its full procedure at L3. It does not explicitly differentiate the tool from siblings such as list_skills or get_skill_usage.

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

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

The wording implies use when the caller already knows a skill ID and wants its full procedure. It provides no explicit routing to list_skills for ID discovery, get_skill_usage for usage information, or guidance on when another disclosure tier is preferable.

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

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

Annotations already declare readOnly, non-destructive and idempotent, yet the description adds real value: suggestions are advisory and never change anything, and history before data_since simply does not exist. That pre-empts the two most likely agent misreads (that it mutates state, or that it can look further back).

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

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

Three sentences, front-loaded with what is returned, then the read-only caveat, then the field-specific notes. No filler, though the opening sentence is dense enough that the scope and window details could be split for easier scanning.

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?

An output schema exists, so return shape need not be spelled out, and the description still usefully covers the data_since caveat and the advisory nature of suggestions. The only real gap is pagination behavior for limit/next_cursor, which matters for a list-style 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?

Schema description coverage is 0% across five parameters, and the description compensates only partially: it explains the 7/30/90-day window and that scope=org requires admin rights. limit, next_cursor and skill_slug are left entirely unexplained in both schema and 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 names the specific resource (Dactic skill usage) and the exact measures returned: listing/load counts by AI clients, live agents per skill, and a promote/keep/review/trim suggestion. It is clear what the tool reports; it just never names its nearest sibling (get_usage) to sharpen the boundary.

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?

Implicit guidance exists: choose a 7/30/90-day window, and scope=org is restricted to org admins. There is no statement of when to reach for this tool instead of get_usage, get_skill, or list_skills, so an agent must infer the choice.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description still adds real behavioral context by warning that 'credential linkage is not proof of current access,' telling the agent that reported data may overstate actual access. This is a substantive caveat beyond the structured metadata.

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

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

Two compact sentences, front-loaded with the reported fields, followed by the caveat. Every clause carries information, though the phrasing 'Report recorded sync progress' is slightly dense and the list of fields could be punctuated more clearly.

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?

An output schema exists, so return structure need not be explained, and the description covers scope plus the important limitation about credentials versus live access. The only gap is the absence of routing guidance relative to sibling status/freshness tools.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly does not waste space restating an 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 names a specific resource (sync status) and enumerates exactly what is reported: recorded progress, last successful sync, approved source coverage, and recovery guidance. It is clear what the tool returns, though it does not explicitly distinguish itself from nearby siblings like get_freshness or get_feedback_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?

Usage is only implied — an agent can infer this is the tool to call when it needs to know how far a sync got or whether coverage is complete. There is no explicit when-to-use statement and no mention of when to prefer get_freshness or check_against_policy 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety needs no restating. The description adds genuinely non-obvious behavior beyond that: strict ownership scoping ('Only your own tasks') and the resulting not_found outcome for anything else, plus the fact that a failed task carries error_message rather than raising.

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

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

One sentence, front-loaded with the resource and its state space, followed by the scoping caveat. No filler and nothing an agent must read twice.

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?

An output schema exists, so return structure needn't be documented, and the description still usefully sketches the state machine and error field. For a single-parameter getter this is nearly everything an agent needs; only polling behavior on an in-flight task is left unstated.

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

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

Schema description coverage is 0%, so the schema only tells the agent that task_id is a required string up to 64 chars. The description compensates partially by implying the id originates from the start call that launched the task and that ownership is checked, but it gives no format or provenance detail beyond that.

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

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

States a specific verb and resource ('Status of a background task') and immediately scopes it to tasks 'you started', naming the producer sibling synthesize_agent. The enumerated outcomes (queued, running, succeeded, failed) tell an agent exactly what this returns, distinguishing it from every other get_* 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 parenthetical '(e.g. synthesize_agent)' links this tool to the async operation that precedes it, which is the key usage cue. It does not explicitly say how often to poll or what to do if the task is still running, but the retrieval context is clear and no competing alternative exists among the siblings.

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?

Beyond the annotations' read-only, non-destructive profile, the description discloses the trailing time window, operation-level aggregation, and org-admin requirement. These are useful behavioral and access details for a simple reporting 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 single compact sentence front-loads the metric, aggregation, and time window, then adds the admin restriction without unnecessary wording. Every clause contributes actionable 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 low-complexity, two-parameter read tool with annotations and an output schema, this supplies nearly enough context to select and invoke it correctly. Missing parameter defaults and a brief distinction from get_skill_usage keep it from being 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?

With 0% schema description coverage, the description usefully connects days to the N-day lookback and explains who may use scope=org. However, it does not state the default scope, the default or allowed range for days, or explicitly describe scope=self, which matters because neither parameter is required.

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

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

The description clearly identifies the resource and result: Dactic AI token usage, grouped by operation, over a trailing N-day period. It also distinguishes personal and organization scopes, though it does not explicitly differentiate the tool from the sibling get_skill_usage.

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 statement that scope=org is for org admins gives concrete guidance on selecting that scope and signals an authorization restriction. There is no explicit comparison with alternatives such as get_skill_usage, but the token-usage context is otherwise 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description does add real value with the pagination note for the knowledge section and the disclosure that unconfirmed files are counted but not shown, plus the admin-privacy constraint — though it says nothing about the size or shape of the knowledge list or cursor 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?

It is one long semicolon-chained sentence: dense and front-loaded with the core identity of the tool, but the run-on structure makes the section inventory harder to scan than a short bulleted or sentence-per-area form would be.

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?

An output schema exists, so return values need not be explained, and the description covers content areas and the privacy boundary adequately for a read-only self-profile tool. What it lacks is any routing guidance versus the many context-retrieval siblings, which is the main thing an agent needs beyond the 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?

Schema description coverage is 0%, so the description must carry parameter meaning, and it largely does not. The word 'paginated' hints at limit/cursor for the knowledge section only, but neither limit (max 50) nor cursor is explained, and the sections enum values are only loosely echoed by the content-area list without stating that selecting sections is what filters the response.

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 inventories exactly what the tool returns (profile fields, work context, confirmed knowledge, connections, tools) and states the privacy scope ('Only ever your own data, even for org admins'), which implicitly separates it from org-wide siblings like get_entity_context. It is clear but never names a sibling alternative by name, so differentiation relies on inference.

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

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

Usage is only implied by the phrase 'for personalising answers' — there is no explicit when-to-use statement and no guidance on when to prefer get_entity_context or get_context_bundle instead. An agent can infer this is the self-profile call, but must reason about it rather than read 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description still earns credit by disclosing the advisory-only nature, that estimates derive solely from user-confirmed measurements, and that missing measurements trigger a clarifying question rather than a guess — behavior no annotation conveys.

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

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

Purpose is front-loaded and the length is modest, but the prose is dense with abstract noun phrases ('provisional platform capabilities,' 'Separates source, execution-platform and host connectors') that cost reading effort without resolving meaning. The closing constraint sentence is the most useful and could have been placed earlier.

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?

An output schema exists, so return values need no explanation, and the read-only constraints are well covered. The gap is input-side: for an 8-parameter tool with a nested measurement object and zero schema descriptions, an agent cannot know what to supply for the non-required fields without trial and error.

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% across 8 parameters including a nested measurements object with ten typed fields, so the description must carry the explanatory load and largely does not. It hints at `measurements.confirmed` ('user-confirmed measurements') and gestures at context gaps and sync readiness, but `goal`, `where_stuck`, `manual_steps`, `target_platform`, `required_inputs` and `available_inputs` are never explained.

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

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

The description gives a specific verb and resource ('Build advisory human-reviewed workflow options') and enumerates the inputs it reasons over (accessible agents, context gaps, connection/sync readiness, platform capabilities). It also implicitly separates itself from execution siblings via 'Never executes, connects, schedules or deploys,' though it never names a concrete sibling 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 'Never executes, connects, schedules or deploys' clause establishes a clear when-not boundary, which is valuable in a family containing deploy_agent, create_agent_from_process and invoke_agent. However, it never says positively when to reach for this tool versus recommend_agent or create_agent_from_process, leaving the agent to infer the routing.

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

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

Annotations already declare non-read-only, idempotent, non-destructive, closed-world, so the safety bar is partly covered; the description adds genuine context beyond that by explaining the execution path differs by agent type and that the response always contains the agent's full instructions and skills. The idempotency sentence largely restates idempotentHint=true, but it specifies the observable effect (same run returned rather than a new one).

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?

Four short sentences, front-loaded with the core action, then agent-type routing, then response content, then retry semantics. Little waste, though the idempotency sentence partly duplicates the annotation and could have been spent on parameter guidance instead.

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?

An output schema exists, so return-value detail is not required, and the description correctly summarizes that instructions and skills are returned. For a tool with a nested free-form payload and zero parameter documentation, though, the description leaves the caller guessing about the shape of "input" and the effect of "include_context", which is the main completeness 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?

Schema description coverage is 0% for four parameters, including a free-form nested "input" object, an "idempotency_key" with a 128-char cap, and an "include_context" boolean. The description only hints at idempotency behavior and never explains what "input" should contain, what "include_context" changes, or the format of agent_id, so the documentation gap is largely unfilled.

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?

"Run one of your deployed Dactic agents" gives a specific verb and resource, and the follow-up sentence splits behavior by agent type (Claude = Managed Agent session, Monday = board automation), which is material detail an agent cannot get from the schema. It does not explicitly contrast itself with the nearby siblings load_agent, get_agent, or deploy_agent, so the differentiation is implicit rather than stated.

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

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

Usage is implied by "deployed" agents, and the description says retrying the same request returns the same run, which tells the caller how to safely retry. However, it never states when to invoke_agent versus load_agent or get_agent, nor any precondition such as the agent being deployed or permissions required.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond that with sort order, the field set returned, and the not_found behavior for an empty account. It does not mention pagination behavior despite a cursor parameter, which is the main remaining gap.

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

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

Three short sentences, front-loaded with what is listed and in what order, followed by return fields, alternatives, and the empty case. No filler or repetition of the title.

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?

An output schema exists, so the brief return mention is sufficient, and the read-only annotations make a permission discussion unnecessary. However, with four undocumented optional parameters and a cursor-based pagination mechanism that is never mentioned, an agent that needs to page or filter is left to guess.

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% for all four parameters, so the description carries the full burden and does not compensate. It never explains limit, cursor, enrich, or the target enum (monday/claude/all), leaving the filtering and paging semantics entirely opaque.

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

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

States a specific verb and resource ("List the Dactic agents"), scopes it to the signed-in user, and specifies ordering ("newest first") plus the returned fields (id, name, platform, status). It is clearly distinguishable from get_agent (details) and load_agent (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?

Explicitly routes the agent to sibling tools: load_agent to run one, get_agent for details, implying this tool is for discovery/enumeration only. It also covers the empty case ("Returns not_found when you have none"). It gives no guidance on when to use the filtering or enrichment parameters, so it stops short of full when/when-not coverage.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds real context beyond that: what each disclosure tier returns, and that not_found is returned when the caller has no skills — a non-obvious empty-state behavior rather than an empty list.

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

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

Three short sentences with the core purpose front-loaded, then the tier semantics, then the alternative and the empty-state. Every sentence adds information; nothing restates the title or the annotations.

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?

An output schema exists, so return-value shape needn't be explained, and the tier semantics are a genuine addition. However, for a four-parameter list tool the description leaves most parameters uninterpreted and doesn't address pagination or ordering via limit, which an agent needs to call it correctly.

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

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

Schema description coverage is 0%, so the description carries the full burden for four parameters, but it only explains disclosure_tier. The meaning of limit, query (free-text search? exact match?), and approved_only (presumably filters to approved procedures) is left entirely to inference. One of four parameters documented is a substantial gap for a low-coverage schema.

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

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

States a specific verb and resource ("List your active Dactic skills") and immediately defines what a skill is ("procedures derived from your interviews"), which resolves an otherwise ambiguous domain term. It also names the sibling get_skill as the single-item counterpart, so an agent can separate the two without opening either schema.

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

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

Explicitly routes single-skill lookups to get_skill, which is the main branching decision an agent faces. It also explains the tier trade-off (L1 catalog vs L2/L3 with procedure), which functions as usage guidance. It stops short of saying when to raise the tier or when to combine with query/approved_only filters.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description earns credit for adding failure semantics the annotations cannot: "not_ready" for unapproved instructions, "not_found" for no match, and the atomicity guarantee that it "never returns a partial agent." It does not address permissions/scoping on agents or any throttling, which keeps it out of 5 territory.

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

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

Two tight sentences, front-loaded with the action and the lookup mechanism, then failure modes. "Follow them exactly" is an instruction to the consuming model rather than a property of the tool, so it is slightly out of register, but it costs almost nothing in length.

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

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

The tool is simple (two optional string params, closed-world, output schema present), so the description need not explain return payloads — and it correctly focuses on the error contract instead. The remaining gap is the mutual-exclusivity/omitted-parameter behavior, which matters given zero required parameters and no schema descriptions.

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 carry the parameter semantics and only partly does. It clarifies that agent_name must be an exact match, which is genuinely useful for a 0%-coverage schema, but it never states whether the two identifiers are mutually exclusive or what happens when neither is supplied despite required_parameters being empty.

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 and resource ("Load one of your Dactic agents") and states the outcome ("so you can run it in this chat: returns its complete instructions and skills"). That is far more than the title restates. It does not, however, distinguish itself from close siblings like get_agent or invoke_agent, which an agent would reasonably confuse it with.

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?

"so you can run it in this chat" implies the use context, and "by agent_id or exact agent_name" gives the two lookup modes. But there is no explicit when-to-use versus get_agent (inspect metadata) or invoke_agent (execute), nor guidance on which identifier to prefer when both are available. Selection against siblings is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: typed row returns, pagination, explicit sync/coverage limits, the caveat that older syncs may lack structured columns, and the no-SQL constraint. It stops short of describing pagination mechanics or what the coverage limits look like in practice.

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?

Four short sentences, front-loaded with the core verb and resource, then field syntax, then return behavior, then caveats. Every sentence carries information; the only minor inefficiency is that return-shape details are partly redundant with the output schema.

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

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

For a 9-parameter, fully optional query tool, the description covers field syntax and aggregation but omits the meaning of board_id, cursor, and limit constraints. The existence of an output schema excuses it from explaining return values, and the sync/coverage caveat is a useful completeness touch, but parameter-level gaps remain.

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

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

With 0% schema description coverage across 9 parameters, the description carries the burden and partially meets it by defining the field-reference convention (base identifiers or column:<stored-column-id>), which is essential for filters, sort, fields, and group_by. It also constrains filters to scalar and aggregation to count/sum. But it says nothing about limit bounds, cursor semantics, board_id, or the view enum, leaving several parameters documented only by raw schema shape.

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: query the approved synced Monday item view, with named capabilities (scalar filters, sorting, grouping, count/sum aggregation). The resource is distinct enough from siblings like search, fetch, or get_entity_context that an agent can route without opening the schema, though no sibling is named explicitly.

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

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

Usage is implied by the scoping language ("approved synced Monday item view") and by the constraint "Never accepts SQL", which rules out an approach an agent might otherwise attempt. However, there is no explicit statement of when to prefer this over search, fetch, or get_entity_context, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety bar is low; the description still adds real value by disclosing that matching is based on stored instructions and skills and that results include candidate evidence and limitations. It also explicitly rules out side effects (no execution, no creation). It omits any mention of the accessibility/permission scoping mechanics or ranking confidence.

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

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

Two tight sentences with the core action front-loaded and the negative scope statement trailing as a guardrail. No filler or redundant restatement of the title.

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

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

For a two-parameter read-only tool with rich annotations and an output schema, the description covers purpose, matching basis, return nature, and absence of side effects. The remaining gap is the undocumented 'limit' parameter and the 'accessible' scoping rule, which is a minor but real 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%, so the description must carry parameter meaning, and it only loosely implies what 'task' is by reusing the word 'task' in the sentence. The 'limit' parameter (1-10) is never mentioned, nor is the expected length/detail of the task string, leaving half the parameters unexplained in both schema and prose.

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 ('Match a task to accessible deployed agents') plus the matching basis ('stored instructions and skills'), which separates it from list_agents, recommend_new_agents, and invoke_agent. The closing clause 'never runs or creates an agent' further disambiguates it from invoke_agent and create_agent_from_process.

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

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

The description gives a clear use context: picking among already-deployed, accessible agents for a given task, which implicitly contrasts with recommend_new_agents and create_agent_from_process. It also negates two adjacent use cases (running and creating). It does not explicitly name the alternative tool or state a 'when not to use' condition, so it stops 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?

Annotations only mark this as a non-read, idempotent, non-destructive write; the description goes well beyond that by disclosing asynchronous execution ('Returns a background task; poll get_task_status'), the dedupe outcome key ('existing_agent_covers'), the proposal cap of three, and the guarantee that nothing is deployed. These are the operationally important traits an agent needs before calling 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?

Four dense sentences, front-loaded with the precondition and the core action before constraints. Minor waste in the unexplained 'Monday synthesis' clause, which reads as internal jargon without context for the reader.

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?

Async return handling and the dedupe result path are covered, and an output schema exists so return shape need not be restated. However, for a five-parameter mutation with 0% schema coverage, the missing explanation of idempotency_key, target_platform, and previous_iteration_id leaves a real 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?

Schema description coverage is 0%, so the description must carry the parameter burden, and it only gestures at goal and priorities. idempotency_key, target_platform, and previous_iteration_id are never mentioned, leaving three of five parameters with no explanation anywhere in the definition.

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 concrete verb and object: save a new recommendation iteration of validated draft proposals derived from the user's own skills/context. That is specific enough to separate it from siblings like recommend_agent or synthesize_agent, though it does not name those siblings explicitly to sharpen the distinction.

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

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

Gives a clear precondition ('After confirming the user's goal') and rules out adjacent behaviors ('Never deploys', 'Monday synthesis is unavailable in this path'), which implies which path to take instead. It never explicitly names the alternative tool to use for synthesis or single-agent recommendation, so routing is inferred rather than spelled out.

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

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

Annotations already cover read-only, idempotent, and closed-world safety, so the bar is lower. The description adds a real behavioral trait beyond them: unconfirmed terms are returned in 'gaps' rather than resolved, which tells the agent how to interpret an incomplete response. It does not mention auth or rate limits, but the key response 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?

Two short sentences, the capability statement first and the constraint second, with no filler. 'Never guess their meaning' is the only instruction sentence and it earns its place as agent guidance.

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?

An output schema exists, so return values needn't be described, and the safety profile is annotation-covered. However, the unexplained 'team' parameter and the absence of any sibling routing leave gaps for a tool sitting among many retrieval alternatives.

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 carry parameter meaning and it largely does not. It never explains that 'terms' is a list of strings to resolve nor what the optional 'team' parameter scopes or how it changes results.

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 ('look up what company-specific terms mean') and constrains the source to confirmed organizational terminology, which separates it from generic lookup siblings like search or ask_knowledge. It does not name a sibling directly, so differentiation is implicit rather than explicit.

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 'never guess their meaning' implies the intended situation (encountering unfamiliar org-specific terms), but the description never states when to choose this over ask_knowledge, get_entity_context, or search. No exclusions or prerequisites are given.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world, non-destructive), yet the description still adds real behavioral context: results include summaries/outcomes, citations and uncertainty, missing actions or outcomes stay unknown, and past outcomes are not predictive. The one gap is that it never explains the ownership scoping as a hard filter versus a hint.

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

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

Three short sentences with the core scope stated first and no filler. The final caution sentence earns its place as an epistemic caveat, though the middle sentence is a slightly dense run-on mixing three separate facts.

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?

An output schema exists, so return values needn't be spelled out, and the description usefully sets expectations about uncertainty and gaps. For a two-parameter retrieval tool, however, it leaves the semantics of `situation` and `limit` entirely undocumented, which is the main thing an agent needs before invoking it.

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

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

Schema description coverage is 0%, so the description carries the full burden for two parameters, and it does not meet it. The required `situation` field's expected content (free-text description of the current case?) is only obliquely implied by "comparable," and `limit` (1-20) is never mentioned at all.

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 gives a specific verb-resource pair: find comparable recent runs or resolved feedback, with ownership scope ("owned by you"). It clarifies the ambiguous name word "cases" as runs/feedback, so an agent can distinguish it from siblings like search or ask_knowledge, though it never names an alternative directly.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative despite many plausible overlaps (search, ask_knowledge, query_work_dataset, get_feedback_status). Any selection signal must be inferred from the word "comparable" alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds useful context beyond that: it names the knowledge sources searched and summarizes the result shape (id, title, link) plus the retrieval path for full text, which is the kind of behavioral detail annotations cannot convey.

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

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

Two sentences, front-loaded with the action and scope, then the result shape and follow-up call. No filler; every clause carries information.

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

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

An output schema exists and rich annotations are present, so return-value and safety explanation are not strictly required, yet the description summarizes both. Given a one-parameter tool, the remaining gap is only the semantics of the query string.

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

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

There is a single required 'query' parameter with 0% schema description coverage, and the description says nothing about its expected form, such as whether it accepts natural language, keywords, or filters. With such low coverage, the description needed to compensate and does not, leaving the one input underspecified.

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 ('Search') and an enumerated resource scope (skills, agents, approved playbooks, confirmed terminology, department policies), which tells an agent what corpus is covered. It distinguishes itself from fetch by naming it as the follow-up for full text, but does not clearly differentiate from close siblings like ask_knowledge or resolve_terms.

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

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

Gives clear usage direction: search here, then 'call fetch with an id for the full text,' which establishes the search-then-fetch workflow. It stops short of exclusions, e.g. when to prefer ask_knowledge for direct question answering or resolve_terms for terminology lookup.

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?

Adds substantial behavior beyond the annotations: the first call persists nothing and returns a preview plus confirmation_code, the write only lands at the agent's next refresh rather than immediately, and the user must explicitly confirm. That is exactly the kind of non-obvious mutation semantics an agent needs before calling.

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

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

Front-loads what the tool does and why, then the confirmation workflow, then the async timing caveat. Dense but every sentence carries operational weight; only "Quote the user's words in detail" feels slightly padded against the schema's maxLength.

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?

Complete for a nine-parameter mutation whose return values are covered by an output schema (the preview) and whose safety profile is covered by annotations. The remaining gaps are field-level meanings rather than behavioral risks, and the critical persistence/confirmation semantics are fully spelled out.

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% across nine parameters, and the description only clarifies confirmation_code (the confirmation handshake), detail (quote the user's words in detail), and agent ownership. It says nothing about target/section/skill_slug, category, severity, expected_behavior, or idempotency_key, so much of the contract remains guesswork.

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 ("File feedback about one of your own Dactic agents") with a concrete example of the kind of input expected, and scopes it to the caller's own agents, which separates it from siblings like get_feedback_status or compare_agent_versions.

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

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

Gives an explicit two-phase procedure (call without confirmation_code, show preview, ask user, call again with the code) plus the restriction "Only for your own agents." It does not name an alternative tool for feedback about other agents or for checking submission status, so it falls short of full when-not 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?

Goes well beyond the annotations by disclosing asynchronous execution (returns a task_id immediately, poll with get_task_status until succeeded or failed), the non-destructive outcome (draft saved for review, never deployed from here), and the two named terminal result states. Annotations only flag readOnly/destructive/idempotent/openWorld flags; the description supplies the actual workflow semantics an agent needs.

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

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

Front-loads purpose, then async behavior, then the two result-state branches, so an agent can stop reading early. It is information-dense with no filler, though the later sentences are long and semicolon-heavy, which slightly slows scanning of the conditional branches.

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?

An output schema exists, so return-value documentation is unnecessary, and the description correctly spends its budget on routing, async polling, and the non-deployment guarantee instead. The only gaps are the unmentioned 'name' and 'idempotency_key' parameters, which matter given the annotation declares idempotentHint=false.

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% across four parameters, so the description carries the burden. It does add real value for target_platform by narrowing the three-value enum to 'claude only for now', and it frames task_description as the user-described task, but 'name' and 'idempotency_key' are never mentioned, so half the parameters remain semantically opaque.

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

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

States a specific verb and resource ('Draft a new Dactic agent') plus a decisive scope constraint: built only from the user's own Dactic skills, policies and work context. It distinguishes itself from the two nearest siblings, create_agent_from_process and deploy_agent, by saying the result is a draft that is never deployed from here.

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

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

Gives explicit routing rules rather than vague context: on a not_enough_material result, offer create_agent_from_process; on existing_agent_covers, use create_agent_from_process only for a genuinely new process. It also sets a procedural precondition ('Confirm the task with the user before calling') and scopes the platform ('claude only for now'), leaving little to inference.

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