TeamShared

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

With no annotations, the description carries the burden and does disclose meaningful behavior: it writes a shared file, attaches it as an artifact, and returns '{changed: false}' and does not comment when the picture is unchanged. Yet it leaves ambiguity about what happens when the picture has changed, failure modes, and whether the create-once work item must already exist, which are important for safe invocation.

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 sentences, each carrying distinct information: the target resource, the file structure and attachment point, the conditional no-op behavior, and scheduling context. No filler or redundancy; concise yet complete.

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

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

The tool has an output schema, so return values don't need explanation, and the description covers the core behavior. However, it omits important context such as prerequisites (whether the create-once work item must exist), what happens when the picture has changed, and any relationship to sibling tools, leaving an agent to infer setup requirements.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description does not add parameter-specific meaning beyond reinforcing that the slug refers to a strategic Person or Organization and that agent is an override, but it doesn't need to compensate for a coverage gap.

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

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

The description states a specific verb and resource: 'Writes one shared file (stakeholders, initiative, objections, last evidence, next review, five-line brief) attached as an artifact on a create-once account work item.' It clearly identifies the tool's purpose and differentiates it from generic file or work item tools by naming the artifact and target uniquely.

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

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

The description implies the tool is for weekly account briefs on strategic Persons or Organizations and notes 'Weekly schedule is bot-side,' suggesting automated periodic use. However, it gives no explicit when-to-use versus alternatives, no exclusions, and no guidance on manual invocation or prerequisites.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose one useful trait — that after canceling you can follow up on the same agent to continue — but it omits side effects, such as whether the run's state is preserved, whether the cancellation is reversible, or what happens if there is no active run.

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 core action front-loaded in the first and the continuation nuance in the second. Every word earns its place; no filler or repetition.

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

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

The description is sufficient for a simple cancel plus the follow-up hint, and an output schema exists to describe return values. However, with no annotations and three optional parameters, it leaves ambiguous how the system selects among multiple active runs and which parameter combination to use in which scenario, so it feels minimal rather than 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?

All three parameters (agent, run_id, cursor_agent_id) already have descriptive schema text, and coverage is 100%, so the description doesn't need to compensate. It adds no parameter-level detail beyond implying that omitting them targets the active run, so a baseline score of 3 is appropriate.

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

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

The description uses the specific verb 'Cancel' with a clear target, 'the active Cursor run,' which is distinct from sibling actions like agent_run_start, agent_run_status, or agent_run_followup. It is not a tautology of the name and leaves no doubt about the operation.

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

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

The description gives no explicit when-to-use or when-not-to-use advice, nor does it name sibling alternatives. 'Follow up on the same agent to continue' implies a post-cancel path (likely agent_run_followup) but doesn't state it or specify conditions, so usage must be inferred.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose a non-obvious behavior: that the follow-up re-injects TeamShared MCP into the agent. But it does not describe side effects, permission requirements, or what happens to the existing run, leaving the agent to infer the operational impact.

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

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

The description is a single front-loaded sentence with no filler. It communicates the primary action and one behavioral detail efficiently. The parenthetical is cryptic but compact, and the overall length is appropriate for a tool whose parameter semantics are already covered by the schema.

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

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

Given that the schema documents all four parameters and an output schema exists, the description does not need to explain return values or parameter formats. It is minimally adequate, but it lacks explicit guidance on how run_id and cursor_agent_id relate to the 'existing' agent and does not clarify what happens when both are omitted. No annotations exist to compensate for these gaps.

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

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

Schema description coverage is 100%, so the parameters are already well-documented in the input schema. The description itself adds no semantic detail beyond the schema, which is acceptable given the high schema coverage. There is no contradiction or missing parameter meaning that the description should have compensated for.

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: 'Send a follow-up to an existing Cursor cloud agent.' It distinguishes itself from sibling tools like agent_run_start or agent_run_status by targeting an existing run rather than starting/listening to one. The parenthetical '(re-injects TeamShared MCP)' adds context but is jargon-heavy and slightly obscures the core purpose.

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

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

The phrase 'existing Cursor cloud agent' implies this tool is for continuing or prompting an already-running agent, which provides some usage context. However, it never explicitly names alternatives like agent_run_start or states when not to use this tool. The selection guidance is left to inference rather than stated directly.

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

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

There are no annotations, so the description carries the behavioral burden. 'List' plus 'in this org' conveys a read-only, org-scoped operation, which is the core trait. It does not disclose ordering, pagination behavior, or whether historical runs are included, but no surprising side effects are implied.

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 concise sentence with no wasted words. The action and resource are front-loaded, and the sentence ends immediately after stating the scope.

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

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

An output schema exists and the input schema carries all parameters, defaults, and constraints, so the description need not restate them. The tool is a simple list operation, and the description is sufficient; the only real gap is explicit sibling routing, which belongs to usage guidance.

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

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

The description adds no parameter-level detail, but the schema covers the two filter parameters with descriptions and limit/offset are conventional pagination names. Since schema coverage is 50% but the remaining parameters are self-explanatory, the omission is acceptable.

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

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

The description uses an explicit verb ('List'), names the resource ('Cursor cloud-agent runs'), and bounds the scope to 'this org'. It clearly distinguishes the tool from siblings like agent_run_start, agent_run_cancel, agent_run_status, and agent_run_followup.

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 listing purpose is implied by the verb, but there is no explicit guidance about when to choose this tool over alternatives such as agent_run_status for checking a single run or agent_run_followup for post-run actions. It is adequate, not prescriptive.

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

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

With no annotations, the description carries the full behavioral burden, and it discloses meaningful side effects: HTTP MCP injection with a short-lived token, one-agent-per-work-item concurrency, busy-run status semantics, and conditional playbook/skills prepending with a cap. It stops short of clarifying what the cap is or the token lifetime, and some jargon (tsk_, bc-) is unexplained, but these are minor against the substantial disclosure.

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

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

The definition is front-loaded with the core purpose and every subsequent sentence carries information with no filler. The density hurts a little — 'TeamShared', 'tsk_', and 'bc-' are unexplained internal jargon — so it sacrifices some readability for completeness.

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

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

For a tool with 8 parameters, no annotations, and a complex behavioral profile (two launch modes, injection side effects, concurrency limits), the description covers the important operational facts, and an output schema is present so return values need no description. What's missing is a tie-back to sibling tools (e.g., what to use when status=busy) and clarification of 'capped', which leaves the agent to guess at the playbook limit.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real semantics beyond the schema for work_id — playbook_slug triggers prepending of the named playbook and its cited skills, capped, with no injection when the slug is unset or work_id omitted — which instructs an agent on that parameter's behavioral effect. Other parameters are already well described in the schema, so no further compensation is needed.

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

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

The opening sentence states a concrete action with a concrete resource: start a Cursor cloud agent. The worker-vs-dispatcher distinction scopes two mmsodes, and the verb 'start' cleanly separates this from sibling tools like agent_run_cancel, agent_run_followup, agent_run_list, and agent_run_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?

The description provides strong operational context — a busy run returns status=busy instead of a second id, so an agent learns not to expect a second run for a busy work item — but it never names an alternative tool or states when not to use this one. The worker/dispatcher and playbook-injection rules guide parameter choice, yet tool-vs-tool routing is left implicit.

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

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

No annotations are provided, so the description carries the burden. 'Read' clearly signals a non-mutating operation, but it does not disclose details such as whether the tool waits for completion, returns intermediate progress, or requires an existing run. The output schema covers return shape but not these behavioral aspects.

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

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

The description is a single front-loaded sentence with no filler. Every word contributes to identifying the action and resource, which is ideal for quick agent parsing.

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 and has an output schema, so return-value coverage is handled. However, the description does not explain the relationship or precedence between run_id and cursor_agent_id, nor what happens when both are omitted, and there is no usage guidance relative to sibling tools. These gaps make it only minimally complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The tool description adds no parameter-level meaning, but the schema already describes run_id and cursor_agent_id reasonably, including the two ID formats. The description does not clarify which parameter should be preferred or whether at least one 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 uses a specific verb ('Read') and resource ('latest status of a Cursor cloud-agent run'), making the purpose immediately clear. It is also easily distinguished from siblings like agent_run_list, which lists runs, and agent_run_cancel, which mutates a 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?

There is no guidance about when to use this tool versus agent_run_start, agent_run_list, agent_run_followup, or agent_run_cancel. An agent has to infer from sibling names and the description that this is for checking status after a run has been started.

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

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

There are no annotations, so the description carries full burden, and it delivers: it discloses the write side effect, the target artifact and work item, the no-comment-when-unchanged behavior, the changed:false return, and the bot-side schedule. This gives an agent a realistic model of what invoking the tool will do.

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

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

The description is compact and well-structured, with the core purpose front-loaded and the behavioral caveats following it. Every sentence contributes useful information; there is no redundancy or filler.

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

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

Given a single optional parameter, an existing output schema, and no required prompts, the description supplies all needed invocation context: data sources, side effects, the unchanged-picture protocol, and scheduling ownership. An agent can reasonably decide when and how to call 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?

The only parameter, 'agent', is fully covered by the schema with 100% description coverage, so the baseline applies. The tool description adds no meaningful parameter guidance, but none is needed because the schema already explains the override behavior.

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

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

The description clearly defines the deliverable as an org attention briefing synthesized from open work, project status, and dream, and states an active behavior: it writes a shared file. This goes beyond restating the tool name and gives enough specificity to distinguish it from sibling tools like account_brief.

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 context is implied rather than explicit: 'Hourly schedule is bot-side' and 'Work is the signal — not Slack or email' signal when and under what conditions the tool fits. However, it does not name alternatives, exclusion criteria, or scenarios where another sibling should be used instead.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool performs durable writes, can close the session, self-heals expired sessions, returns an authoritative session_id, and reports the result shape. This is solid transparency, though it stops short of covering failure modes or permission requirements.

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 with no filler. The core purpose is front-loaded, the replaced sequence is named, and the return shape is included. Every sentence earns its place.

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

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

The definition is mostly complete for a tool with a rich schema: it names the scenario, the replaced alternatives, key behavioral nuances, and the return contract. It could be slightly more complete with explicit guidance on when not to use it, but the schema and output schema cover most operational details.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra semantic value beyond the schema by explaining that the append self-heals expired sessions and that the response's session_id is authoritative, which directly clarifies behavior tied to the session_id parameter and the overall write semantics.

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

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

The description clearly states the tool's function: a turn-end batch that combines assistant summary, durable writes, and optional close. It also distinguishes itself from the sibling sequence by explicitly naming memory_session_append + memory_remember (+ memory_session_close + memory_state_set), so an agent can tell exactly what this tool is for.

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 strong usage context by stating this replaces the end-of-turn memory_session_append + memory_remember sequence and that close is optional. It does not provide explicit when-not-to-use or exclusion guidance, but the naming of alternatives makes the appropriate use case clear.

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

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

With no annotations present, the description carries the full disclosure burden and does substantial work: it reveals a persistence side effect (originals stored in CCR/Redis), a recovery mechanism (ref= markers consumed by context_retrieve), and an operational default ('always runs'), plus configuration knobs (TEAMSHARED_COMPRESS_*). It stops short of explaining what happens to the input in-place or the exact shape of the returned refs, but the output schema covers the return side.

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 with zero filler: purpose first, then mechanism and storage behavior, then operational tuning. Every sentence earns its place, and the most decision-relevant facts (what it compresses, where originals go, how to retrieve them) are front-loaded.

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

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

For a low-complexity tool (one well-documented parameter, output schema present), the description covers purpose, mechanism, side effects, recovery path, and configuration. The only real gap is the unresolved 'always runs' instruction, which leaves some ambiguity about whether this tool is agent-invoked or automatically applied, and there is no mention of cost/latency tradeoffs an agent might weigh before compressing.

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

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

Schema description coverage is 100% — the messages parameter already documents that user messages are preserved while long tool/assistant/system blocks shrink. The main description's mention of 'JSON tool outputs, logs, and long text' is consistent with and mildly reinforces the schema but adds little meaning beyond it, so the baseline 3 applies.

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

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

The description opens with a specific verb+resource pair ('Compress a prompt payload before it reaches an LLM') and details the content types shrunk (JSON tool outputs, logs, long text) and the method (SmartCrusher-lite sampling). It also names context_retrieve as the companion for stored originals, which distinguishes it from the five other context_* siblings without needing to open any 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 description positions the tool in a pipeline ('before it reaches an LLM'), states that it 'always runs', and routes recovery to context_retrieve via ref= markers, giving an agent a clear sense of when and alongside what it operates. It does not explicitly contrast itself with similar-looking siblings like context_normalize, context_prepare, or context_commit, and the phrase 'always runs' is slightly ambiguous about whether the agent should invoke it directly or whether the system does it automatically.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool trims, cleans, shrinks, and stores originals in CCR when compressed. This is meaningful context, though the acronym 'CCR' is left unexplained and the compression trigger conditions are not specified.

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

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

Three sentences with no redundancy. The core purpose is front-loaded, followed by specific behavioral details and a clear usage rule. Every sentence earns its place.

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

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

The tool has only two simple parameters and an output schema, so the description covers most operational needs: what it does, what types of outputs it targets, and when to call it. The main gaps are the unexplained 'CCR' and the somewhat jargon-heavy 'non-teamshared' term.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds general context about the target tool types but does not add parameter-specific meaning beyond what the schema already provides for tool_name and output.

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

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

The description opens with a specific verb-resource action: 'Strip, clean, and compress a non-teamshared tool output for agent context.' It distinguishes its target (Shell, Grep, or other harness tools) from teamshared tools, though it does not explicitly differentiate itself from the closely named sibling context_compress.

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

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

The description explicitly states when to use the tool ('call this for Shell, Grep, or other harness tools') and when not to ('Prefer letting MCP middleware handle teamshared tools automatically'). It also describes what kinds of outputs are appropriate, such as recall-style payloads and large JSON/logs.

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

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

With no annotations, the description carries the transparency burden. It discloses the operation sequence (appends to session, compresses history, enriches) and the output shape, which implies the tool transforms context and may write to working memory. It does not state persistence, reversibility, or behavior when neither messages nor prompt is provided.

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 with the pipeline summary first, followed by output and usage context. It is efficient, though the arrow-notation pipeline and 'teamsmarted' jargon require the reader to already know the domain.

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

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

Given 8 optional parameters, a full output schema, and no annotations, the description supplies the needed usage context and a clear invocation trigger. It could more explicitly distinguish itself from close siblings like context_compress or memory_assemble_context, but the 'before sending a turn' guidance is sufficient for most cases.

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

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

Schema description coverage is 100%, so the baseline is the correct anchor. The description adds strategic context (why to use it, what it returns) rather than per-parameter explanations; the individual parameters are already well documented in the schema.

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

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

The description names a specific pipeline (session append → compress → enrich) and the concrete return payload (messages, optional additional_context, session_id, stats). It also scopes itself against sibling tooling by stating that server-side MCP middleware handles teamshared tool normalization and 'this covers the rest of the prompt.'

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 explicitly says 'Use before sending a turn to your LLM' and gives the condition (want teamshared to shrink tool bloat and inject recall). It does not name an alternative tool explicitly, but the middleware statement provides a boundary against normalization-focused 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses only the core operation; it does not address failure modes (invalid or expired refs), side effects, prerequisites, or whether retrieval mutates any state. For a no-annotation tool this is thin coverage.

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 13-word sentence that front-loads the verb and resource. There is no filler or repetition of the title, and every word contributes meaning.

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

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

The description is adequate for a simple one-parameter tool with an output schema present. However, it never situates itself in the compression workflow alongside siblings like context_compress or context_commit, and it says nothing about edge cases such as stale or invalid refs.

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

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

Schema description coverage is 100% — the schema already documents ref as 'CCR ref from a compressed message (ref=ccr_...)' with format guidance. The description's 'via CCR ref' adds only a weak link between the parameter and the operation, so the baseline 3 applies.

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

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

The description states a specific action ('retrieve'), a specific resource ('original content for a compressed block'), and the mechanism ('via CCR ref'). It is immediately distinguishable from sibling tools, notably context_compress, which performs the inverse operation.

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 intended use case is implied: when you have a CCR ref from a compressed message, call this tool to recover the original content. However, there is no explicit when-to-use guidance, no exclusions, and no named alternatives among the context/memory sibling tools.

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

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

There are no annotations, so the description carries the behavioral disclosure burden. It discloses two important traits: the tool is deprecated and it behaves exactly like storage_attach. It does not list side effects or permissions, but because the behavior is delegated via an alias, that information is available from the canonical tool.

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

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

The description is a single sentence with no wasted words: it states the essential fact—deprecated alias—and stops. For a compatibility shim tool, this is the appropriate level of detail.

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

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

Given the complete input schema, an output schema, and the explicit reference to storage_attach, an agent has enough context to see this tool as deprecated and to route to the canonical alternative. It is not a full 5 because the description relies on the reader to consult storage_attach to learn the actual attach behavior.

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

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

Schema coverage is 100% and each parameter already has a meaningful description in the input schema. The tool description adds no parameter-level semantics, so the schema-supported baseline of 3 is appropriate.

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

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

The description clearly identifies the tool as a deprecated alias for storage_attach, which effectively states its function by pointing to the canonical operation. It does not describe the underlying attach action directly, but the alias reference names the concrete resource and distinguishes the tool from its siblings.

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

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

Deprecated immediately tells an agent this tool should not be preferred, and 'alias for storage_attach' names the alternative to use instead. This is an explicit when-not-to-use signal combined with the correct routing instruction.

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

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

No annotations are provided, so the description carries the burden. It adds the deprecation status and the alias relationship, which is useful context beyond the schema. However, it does not disclose the operation's side effects (folder creation), which is only implied by the name/title and by the alias target.

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

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

The description is a single short sentence that conveys the essential deprecation information with no wasted words. It is front-loaded with the most important fact: the tool is deprecated.

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 deprecated alias tool, the description fully covers what an agent needs to know: it is deprecated, it aliases storage_folder_create, and the input schema (100% coverage) and output schema supply the remaining invocation details. Nothing critical is missing.

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

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

Schema description coverage is 100%, so the parameter descriptions already fully document 'title', 'parent_id', and 'agent'. The tool description adds no additional parameter semantics; the baseline of 3 applies.

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

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

The description clearly identifies the tool as a deprecated alias for storage_folder_create, differentiating it from its non-deprecated sibling. It does not explicitly state 'creates a folder', but the tool name and title supply the verb and resource, and the alias implies identical behavior to storage_folder_create.

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?

By labeling the tool as 'deprecated alias', the description explicitly tells agents not to use this tool in favor of storage_folder_create. This is a clear when-not-to-use statement and names the exact alternative.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states only that the tool is a deprecated alias; it says nothing about read-only behavior, side effects, permissions, or error behavior. The deprecation status is useful, but actual invocation behavior is left unspecified.

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

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

One short sentence conveys deprecation status and the canonical alternative with zero wasted words. The key information is front-loaded and immediately actionable.

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

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

The tool is low-complexity: one documented parameter and an output schema exist. The deprecation message is the critical extra context and is present, telling the agent to route to storage_get. The only minor gap is that the description does not explain storage_get's semantics, but that definition is available among 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?

The input schema already documents the single parameter file_id with the description 'Storage object UUID', so schema coverage is complete. The tool description adds no additional parameter-level meaning. This matches the baseline for full schema coverage.

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

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

The description clearly identifies the tool as a deprecated alias for storage_get, which tells an agent what this tool effectively is without simply restating its name. It also distinguishes it from the sibling tool set by pointing to the canonical replacement. It does not independently describe the underlying get operation, but the alias reference is sufficient.

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

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

The description explicitly marks the tool as deprecated and names storage_get as the replacement. This gives the agent direct guidance to prefer storage_get and avoid using this alias except for legacy compatibility.

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

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

With no annotations, the description carries the full burden, and it discloses an important behavioral trait: the tool is deprecated and behaves as an alias for storage_list. However, it does not describe any actual listing behavior, output characteristics, filters, or side effects; the pointer to storage_list partially compensates but does not fully disclose behavior.

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

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

The description is a single sentence with no filler: it states the deprecation status and the canonical replacement. Every word earns its place, and the critical routing information is immediately visible.

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 deprecated alias tool with a detailed input schema and an output schema, the description is largely sufficient because it tells the agent to use storage_list instead. It does not restate storage_list's full behavior, but as an alias this is acceptable; the main gap is that if storage_list's description is unavailable, the agent must infer the actual listing semantics.

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 high (83%), and the schema provides descriptions for most parameters including query, work_id, folder_id, parent_id, and project_id. The description itself adds no parameter-level meaning, so it earns the baseline score for relying on a well-covered schema.

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

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

The description states that drive_list is a deprecated alias for storage_list, which clearly identifies the underlying operation by reference to the canonical tool. It stops short of explicitly stating 'lists storage objects,' relying on the sibling tool name, but it is not vague or tautological.

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 deprecation notice explicitly signals that this tool should not be used in favor of storage_list, which is named as the replacement. This gives an agent clear routing guidance and an explicit alternative.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It discloses that the tool is deprecated and that it delegates to storage_move, which is meaningful. However, it does not describe the move operation's effects, permissions, or error behavior, leaving the behavior mostly to be inferred from the canonical 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 sentence is tightly packed and front-loads the critical deprecation signal before naming the canonical tool. Every word earns its place, and no filler is present.

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

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

For a deprecated alias, the routing to storage_move plus a fully described schema and an output schema is sufficient. It could be improved by explicitly stating 'use storage_move instead,' but the alias relationship provides the necessary context.

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

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

Schema description coverage is 100%, so every parameter (agent, file_id, parent_id) is already documented in the schema. The description adds no additional parameter-level meaning, matching the baseline of 3.

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

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

The description clearly identifies the tool as a deprecated alias and names storage_move as the canonical tool, which distinguishes it from the drive_* and storage_* siblings. It does not state the underlying action directly, but the alias relation and the canonical tool name convey the purpose.

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?

By marking the tool as deprecated and as an alias for storage_move, the description tells an agent not to choose this tool for new calls and implicitly routes it to storage_move. This is a clear usage signal, though it does not spell out 'use storage_move instead' in an imperative form.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only discloses deprecation status and alias relationship, and does not describe side effects, permissions, reversibility, or publish/unpublish semantics. The behavior is only implicitly delegated to storage_publish.

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

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

One sentence with no filler, front-loading the deprecation status and then naming the replacement. This is appropriately sized for a deprecated alias tool whose only real purpose is to route callers to storage_publish.

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 with one required parameter, a fully described schema, and an output schema available. The deprecation guidance plus the named replacement covers the key decision an agent needs to make. It loses one point because the actual publish behavior is only implicit via 'alias' and the sibling name, with no annotations to compensate.

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

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

Schema description coverage is 100% for file_id, e.g. 'Storage object UUID to publish', so the baseline is met. The description adds no parameter-level meaning beyond identifying the tool as an alias, but the schema already documents the single parameter adequately.

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 says the tool is a deprecated alias for storage_publish, which points to the relevant sibling but does not itself state the tool's operating behavior (publishing a storage object). It relies on the sibling name and the file_id schema hint to convey the function, and there is no explicit verb describing what drive_publish does.

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

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

The description explicitly provides when-not-to-use guidance via the word 'Deprecated' and names the replacement alternative, storage_publish. An agent can clearly infer that storage_publish should be used instead of drive_publish.

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

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

There are no annotations, and the description does not disclose what 'unlink' does, whether it mutates state, requires permissions, or returns anything. The alias reference points the agent to storage_unlink, but the description alone carries little actual behavioral information.

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

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

One short sentence, fully front-loaded, with no wasted words. The deprecation and alias relationship are the only necessary content, and the description delivers them immediately.

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

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

The description gives the key routing context an agent needs: this tool exists only as a deprecated alias and should be replaced by storage_unlink, which is a sibling. It does not describe behavior or return value, but those are effectively delegated to storage_unlink, making this sufficient for a deprecation stub.

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?

All four input parameters already have descriptive entries in the schema, including 'Storage object UUID to unlink' and 'Work item UUID to unlink from'. The description adds no additional parameter meaning, so the high schema coverage establishes the baseline score.

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 does not spell out the unlink operation itself, but it gives a precise definition by equivalence: this tool is a deprecated alias for storage_unlink. That clearly identifies a canonical sibling and distinguishes this tool from the rest of the drive_* family.

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?

'Deprecated alias for storage_unlink' is an explicit usage signal: avoid this tool and use storage_unlink instead. It names the exact alternative and communicates the deprecation without ambiguity.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals only that the tool is deprecated and an alias, but says nothing about side effects, permissions, idempotency, or what unpublishing entails. For a mutation-oriented tool, this is a significant omission, even if the alias relationship implies identical behavior to storage_unpublish.

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

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

The description is a single sentence, word-efficient, and front-loaded with the most critical fact (deprecated alias). No unnecessary elaboration exists, making it ideal for a wrapper tool.

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

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

Given the tool is a deprecated alias with a simple one-parameter schema and an output schema present, the description covers the essential context: its status and the canonical target. It could be more explicit about the actual action, but the alias relationship plus sibling listing of storage_unpublish makes the intent reasonably complete for an agent.

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

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

Schema description coverage is 100%, with file_id documented as 'Storage object UUID to unpublish', so the schema already handles parameter semantics. The description adds no parameter-level information, which aligns with the baseline score of 3 when the schema fully covers parameters.

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

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

The description explicitly identifies the tool as a deprecated alias for storage_unpublish, which conveys that its function matches the canonical unpublish operation. This distinguishes it from siblings like drive_publish and drive_list, but it does not directly state what unpublishing does, relying on knowledge of the aliased tool.

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

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

The description explicitly marks the tool as deprecated and names storage_unpublish as the canonical replacement. This tells an agent to use the alternative and avoid this tool, giving clear when-to-use versus when-not-to-use guidance in a single phrase.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It honestly discloses deprecation and equivalence to storage_upload_request, which is useful, but it does not describe the underlying upload behavior, side effects, or requirements such as authentication or storage object creation. Some transparency is present, but significant behavioral context is delegated to the canonical 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?

A single sentence that says exactly what is needed: the tool is deprecated and points to the canonical replacement. There is no wasted wording, and the critical deprecation signal is front-loaded.

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

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

For a deprecated alias, the description is sufficiently complete: it tells the agent not to use it and where to go instead. Full parameter documentation in the schema and an output schema cover the mechanics, so the only missing piece is the standalone behavioral description of the upload operation, which is reasonably delegated to storage_upload_request.

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

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

Schema description coverage is 100%, so the input schema already documents all 8 parameters including defaults and semantics. The description adds no parameter-specific meaning, which is acceptable under the baseline for full schema coverage.

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

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

The description clearly identifies this as a deprecated alias for storage_upload_request, which tells an agent what this tool is and where the real functionality lives. It does not describe the upload action in its own words, but the alias reference makes the purpose unambiguous and distinct from the many storage/drive siblings.

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

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

The word 'Deprecated' explicitly signals not to use this tool, and 'alias for storage_upload_request' names the exact alternative. This gives the agent an unambiguous routing decision with no need to infer when or whether to call it.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses meaningful side effects: removal from active lists, cleanup of the bucket mirror when published, retention of version history for audit, and the public route returning 404. This goes well beyond a bare 'archive' statement.

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 tightly written sentences with the primary action and immediate side effect first, followed by audit and routing consequences. No filler or redundant restatement of the schema.

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

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

The tool is low-complexity with one required parameter and an output schema, so the description's coverage of action, side effects, retention and public behavior is sufficient for correct invocation. No critical behavioral information appears to be missing.

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

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

Schema coverage is 100% and the single file_id parameter is already documented as the file UUID to archive. The description adds only the shared-file and published-mirror context, not new parameter details. Baseline 3 is appropriate.

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

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

States a specific action ('Archive') on a specific resource ('a shared file'), and clarifies the observable effect: excluded from active lists, bucket mirror cleanup if published. This distinguishes it from vaguely named alternatives like file_update or file_version_delete.

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

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

The description implies when to use it (when a file should be archived and retained for audit) and describes post-conditions, but it does not explicitly name alternatives such as file_unpublish or file_version_delete or state when NOT to use this tool. The context is clear enough to infer usage, but not explicitly 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?

With no annotations provided, the description carries the behavioral disclosure burden. It reveals that shared files default to private, that public sharing requires file_publish, that updates create immutable version rows, and that project attachments are kind=artifact only. This is strong contextual information beyond the basic create operation, though it does not cover authorization or broader side effects.

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

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

The description is four sentences with no filler: it leads with the core purpose, then adds privacy behavior, sibling-tool routing, versioning semantics, and attachment details. Every sentence earns its place and important information is front-loaded.

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

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

Given the tool has a rich input schema, an output schema, and no annotations, the description is complete enough for reliable invocation. It explains the key behavioral boundaries, attachment constraints, and related sibling operations. Nothing essential for correct use appears to be missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantic nuance beyond the schema: work_id and project_id attach to the same shared_files row, project attachments are restricted to kind=artifact, and content can be passed in different formats. This elevates the parameter understanding beyond simple property descriptions.

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

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

The description uses a specific verb and resource: 'Create a new versioned shared file in the caller's org.' It clearly distinguishes itself from sibling tools like file_update and file_publish by establishing that this is the creation entrypoint and that updates create new version rows.

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 concrete guidance about related sibling tools: file_publish is the way to generate a public share URL, and file_update is the operation that creates new immutable version rows. It provides clear context for when those alternatives are relevant, though it does not explicitly list exclusions such as when to prefer file_upload_request.

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

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

With no annotations, the description must carry behavioral transparency. It usefully discloses that the latest version content is returned and that `public_url` appears only when the file is published. Error behavior, access requirements, and unpublished-file behavior are not addressed, but the core read-only behavior is clear.

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

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

Two compact sentences: the first states the primary action and target resource, the second adds a conditional output detail. Nothing is redundant or filler.

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

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

This is a simple one-parameter read tool with an output schema present, so the description does not need to restate return structure. The only meaningful behavioral nuance, the conditional `public_url`, is covered. Slightly more routing context could help, but the tool itself is well scoped.

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

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

The only parameter, `file_id`, is already fully described in the schema as 'File UUID' (100% schema coverage). The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

States a specific action and resource: 'Fetch a shared file with its latest version content.' It also adds the conditional `public_url` output detail. It does not explicitly contrast with `file_list` or `file_publish`, but the by-ID content-fetch focus makes it reasonably distinguishable.

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

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

The description provides no guidance on when to use this tool versus siblings such as `file_list` or `file_publish`. It does not mention that this is the by-ID single-file retrieval counterpart to listing, nor any prerequisites beyond having `file_id`.

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

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

Annotations are absent, so the description carries the burden. It discloses useful behavioral traits: active files only, newest-update ordering, archived files stay joined but are omitted, and the public_url formation for published files. It doesn't describe pagination or full return shape, but with no annotations and an output schema present, this is a solid disclosure.

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

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

The description is compact and front-loaded with the core behavior, followed by return-URL details and filter guidance. Every sentence earns its place, though the public_url/slug/share_token detail could arguably be deferred to the output schema; it is still concise and relevant.

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

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

Given the tool's moderate complexity (4 optional params) and no annotations, the description covers primary use cases, filter semantics, precedence, and a key behavioral nuance (archived files). It doesn't mention pagination or limit defaults, but the output schema and self-explanatory limit parameter reduce the need.

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

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

Schema coverage is 75% and the description adds meaning beyond the schema: it explains the purpose of query (find by title without full listing), explains work_id vs project_id semantics (task vs project, artifacts only vs agent log + artifacts), and documents precedence. The limit parameter is left to the schema but its constraints are self-explanatory.

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

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

States a specific verb ('List'), resource ('active shared files in the caller's org'), and ordering ('newest update first'). It distinguishes itself from sibling file tools by focusing on listing/filtering rather than create/get/update, and the description explicitly covers filter semantics that set it apart from file_get.

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

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

Provides explicit when-to-use guidance: use query to find a file by title without listing everything, pass work_id to list files on a task, project_id to list files on a project. It also documents precedence (project_id wins) and clarifies that archived files are omitted, giving clear context for choosing parameters and interpreting results.

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

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

With no annotations provided, the description carries full behavioral disclosure. It reveals idempotency (returns existing token/slug), the eager push of latest rendered HTML to the Railway bucket, the dual URL scheme with slug and token, and the seat-based access restriction. These are meaningful behavioral traits beyond the schema.

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

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

The description is information-dense without fluff; every sentence contributes either purpose, idempotency, output URL structure, or access guidance. The main action is front-loaded, and supporting details are grouped logically. It is longer than a two-sentence description but earns each sentence.

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

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

For a single-parameter tool with an output schema and no annotations, the description covers everything needed to invoke it correctly: what it does, return behavior, URL formats, idempotency, and authorization restrictions. An agent can confidently decide whether to call this tool or request approval.

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

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

Schema coverage is 100% and the only parameter, file_id, is already described as 'File UUID to publish.' The description adds surrounding context about URL generation and idempotency but does not add new file_id-specific semantics. Baseline 3 is appropriate because the schema fully documents the 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 opens with a specific verb and resource: 'Publish a shared file: generate the public share token + slug and URL.' It clearly differentiates file_publish from siblings like file_unpublish and file_update. The scope is unambiguous and an agent can tell exactly what operation this invokes.

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

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

The description gives explicit routing guidance: agent seats are refused and should call request_gated_approval(gate="publish") instead, while console humans may still publish directly. It also notes idempotency, so agents know re-calling is safe. This goes beyond a simple 'use for publishing' statement.

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

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that the share token is retained for audit, that the public route will return 404, and that removal of mirrored bucket objects is best-effort. These specifics go beyond a generic 'unpublish' statement.

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 focused sentences with no filler. The core action is front-loaded, and the second sentence adds important caveats that earn their place.

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

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

For a one-parameter tool with an output schema present, the description covers the action, side effects, audit behavior, and the best-effort nature of bucket cleanup. Minor gaps like permission requirements and idempotency keep it from a perfect score.

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

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

The schema already provides 100% coverage for the single parameter: file_id is described as 'File UUID to unpublish.' The description adds no further parameter-level meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb and resource: 'Revoke public access to a shared file (visibility back to private).' This clearly distinguishes the tool from sibling file operations like file_publish or file_update, even without naming them explicitly.

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

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

The intended use is readily implied: call this when a shared file's public access should be withdrawn. However, the description provides no explicit guidance on when to prefer this over alternatives, or when not to use it.

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

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

With no annotations provided, the description carries the full behavioral burden and does so well. It discloses the version numbering mechanism, the eager mirroring behavior when the file is published, and the guarantee that old versions are never mutated. This is far beyond a generic 'update' statement.

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

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

The description is two sentences with zero filler. The core operation and version rule are front-loaded, followed by the published-file mirroring behavior and immutability guarantee. Every sentence earns its place.

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

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

Given the 100% schema coverage and the presence of an output schema, the description is complete enough for correct invocation. It covers what the tool does, its versioning model, the published-file behavior, and what is never mutated. An agent can select and call this tool without needing further 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?

Schema coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides for file_id, content, content_format, and agent. The versioning context is useful but does not enrich individual parameter semantics.

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

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

The description states a specific verb and resource: 'Append a new version to an existing shared file.' It also gives the versioning rule, 'ersion = prior max + 1,' and the non-destructive trait, 'Old versions are never mutated,' which clearly distinguishes it from file_create or file_version_delete.

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 clearly implies when to use it: updating an already-existing shared file by appending a version, including behavior for published files. However, it does not explicitly name alternatives such as file_create for new files or file_version_delete for deleting versions, so it lacks explicit exclusions.

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

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

No annotations are provided, so the description carries the full burden, and it delivers. It discloses the one-time token, ~10-minute TTL, self-deleting script, single-use behavior, and the update-mode side effects including preserved title/slug/share_token and bucket mirror re-publishing. This is rich behavioral context that an agent needs to understand consequences before invoking.

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

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

The description is well-structured and front-loaded with the core purpose, followed by a concise workflow explanation and a clearly separated "Update mode" section. Every sentence adds useful information—TTL, self-deletion, output behavior, update-mode preservation rules—without redundancy or filler.

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

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

For a 9-parameter tool with an output schema, the description is complete enough: it explains the end-to-end flow (request script, save, run, upload, cleanup), the constraints, and the important update-mode behaviors. The output schema and 100% schema coverage handle remaining return and parameter details, so nothing critical is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: title is ignored in update mode, file_id enables appending a new version, publish=true triggers public URL output, and filename serves as the script's default path. It doesn't narrate every parameter, but the added context materially improves parameter understanding.

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

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

The description clearly states the tool's verb and resource: "Get a one-time uploader script to push a local file into a shared file." It explicitly distinguishes itself from siblings by saying it is for files that "don't fit inline in file_create/file_update," and it explains the update-mode variant. An agent can immediately tell what this tool does and how it differs from related file tools.

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

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

The description explicitly names alternatives (file_create/file_update) and states the condition for using this tool instead: large local HTML/Markdown files that don't fit inline. It also says update mode is "the supported way to push a new version of a large file," giving clear routing guidance. This leaves little to inference.

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

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

With no annotations provided, the description carries the full burden, and it does so excellently. It discloses the irreversible/destructive nature, the refusal to delete the last version, the current_version rollback behavior, the bucket mirror re-publication side effect, and the returned fields.

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

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

The description is dense but well-organized: the safety warning is front-loaded, followed by edge-case behavior and return values. Every sentence adds meaningful information, and there is no filler.

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

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

The description is complete for a destructive single-version delete tool. It covers what is deleted, what is refused, the side effects on current version and publishing, and what the caller receives in the response. The presence of an output schema reduces the need to document return structure further.

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

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

Schema coverage is 100% and both parameters are already described clearly in the input schema. The description adds useful context about shared files and current-version behavior, but it does not materially extend the meaning of the two parameters beyond the schema.

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

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

The description names the exact action ('Delete a single version of a shared file') and adds important context: it is destructive and irreversible. This clearly distinguishes it from sibling file operations like file_update or file_archive.

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 usage is implied by the verb and resource, but there is no explicit guidance on when to prefer this tool over alternatives, nor mention of sibling tools such as file_archive or file_unpublish. The refusal condition is a useful edge-case note, not a usage guideline.

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

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

With no annotations provided, the description carries the full behavioral burden and meets it thoroughly. It discloses that optional dependencies report 'disabled' when off without degrading overall status, defines what 'semantic' means, and states the probe is cheap and safe to poll—operational behavior beyond a generic liveness check.

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?

Every sentence earns its place: purpose, return shape, component clarification, disabled-dependency behavior, and operational guidance. The description is compact, front-loaded, and completely free of filler.

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

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

For a zero-parameter liveness probe with an output schema, the description covers the return contents, disabled-dependency behavior, cost/rate expectations, and common usage context. Nothing an agent needs to invoke and interpret the tool correctly is missing.

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

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

This tool has zero parameters and the schema already documents that with 100% coverage, so the baseline is 4. There is no parameter-level meaning to add, and the description instead clarifies the return fields, which is the more relevant semantic content here.

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 'Liveness + dependency probe', a specific noun phrase naming the resource and its purpose. It details the returned status, version, and component map, and references the '/health' HTTP route and Docker healthcheck, making it clearly distinct from siblings like 'version'.

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

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

The description explicitly states this tool is used by Docker healthcheck and the '/health' HTTP route, and says it is 'always cheap; safe to poll on a 10s interval'—clear context for when to use it. It does not name alternatives or a when-not-to-use condition, so it falls just short of a 5.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses the headless-only constraint, that an email with a 6-digit code is sent, that later tools 'run as that person' after authentication, and instructs not to store the code or token. This is rich behavioral context beyond any structured annotation.

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

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

The description is front-loaded with the core purpose and constraints, then presents a scannable numbered workflow with code snippets. Every sentence earns its place; there is no filler or redundancy.

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

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

For a multi-step auth flow with no annotations, this is complete: it covers the trigger condition, alternatives, ordered calls, relevant statuses (code_sent, need_org, authenticated), session-binding consequences, and a security warning. The output schema can carry the structured status details, so nothing critical is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds workflow-level meaning beyond the schema: it shows concrete call examples for email-only, email+code, and org_id resolution, and clarifies that omitting email checks the session state. This integration of parameters into a sequence is valuable, though not a huge leap over the already descriptive schema.

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

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

The description states a specific verb and resource: 'Last-resort email + OTP bind for this MCP session (headless only).' It distinguishes itself from account-level Cursor Connect and tsk_ header alternatives, and no sibling tool overlaps with auth, so an agent can tell exactly what this tool is for.

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 tells when to use this tool: only as a last resort 'When the host has no token' and 'Do not call this as the first hop.' It names preferred alternatives (Cursor Connect, tsk_ header) and provides a numbered 3-step workflow, so invocation timing is fully specified.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses a concrete side-effect, writing an audit log entry, and 'governed' hints at guardrails or policy constraints. It does not detail permissions, reversibility, or failure behavior, but the main behavioral traits are visible.

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

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

The description is a single focused sentence with no filler. It front-loads the core operation and immediately signals the audit side-effect, making it easy for an agent to parse quickly.

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

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

With a nested parameters object and an output schema, the tool has enough structure for basic invocation. However, the description is sparse on how to discover valid action names and gives no guidance on selecting this tool over related memory actions. It is adequate but has clear gaps.

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

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

Schema description coverage is 100%, and the schema already explains action_name, action alias, agent override, and parameters. The tool description adds no extra parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Execute'), a clear resource ('governed ontology action'), and an explicit secondary effect ('write an audit log entry'). This distinguishes it from sibling tools like memory_action_log_list, which lists logs rather than applying actions.

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

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

The description implies when to use it—when you need to execute an ontology action—but does not explicitly state when not to use it or point to alternatives such as memory_action_log_list or memory_graph_relate. Usage context is present but mostly inferred.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists recent executions but does not mention that it is read-only, how results are ordered, whether pagination is needed, or what counts as a 'governed action execution.'

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

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

The description is a single sentence with no fluff. It front-loads the core behavior ('List') and immediately states the resource and scope.

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

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

Complexity is low: one optional parameter and an output schema exist, so return format is handled elsewhere. However, the description leaves open questions about ordering, whether results are limited to the most recent N, and what exactly 'governed' means, making it minimally adequate but not complete.

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

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

The schema has 0% description coverage and the description says nothing about the limit parameter. The schema does provide type, default, minimum, and maximum, so the parameter is not unusable, but the description adds no semantic meaning beyond the parameter name and constraints.

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

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

The description uses a specific verb and resource: it lists recent governed action executions at the org level. This distinguishes it from list-style siblings that target episodes, playbooks, or procedures, though the term 'governed' is not explained.

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

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

The description implies the tool should be used when the agent needs to inspect recently executed governed actions for the organization. It provides no explicit alternatives, exclusions, or by-contrast guidance, but the usage context is reasonably inferable.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses conditional side effects via 'Get-or-create' and explains the non-obvious slug mapping for harness and cloud agents. It doesn't explicitly state whether an existing profile is ever modified, but 'get-or-create' strongly implies idempotent ensure semantics.

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, each earning its place: purpose, naming convention, and routing to read-only alternatives. The core action is front-loaded and there is no filler.

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

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

For a tool with 7 optional parameters and an output schema, the description provides the essential decision context: what it ensures, how slugs are formed, and how other agents should read the profile. An explicit note about when to prefer memory_agent_set instead would make it fully complete, but the schema and output schema cover most remaining mechanics.

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

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

Schema coverage is 100% and each parameter has its own description, establishing a baseline of 3. The description adds extra meaning by tying the name parameter to harness labels and cursor_agent_id to cloud agent slugs, which goes beyond the schema's raw field descriptions.

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

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

The description opens with a specific verb and resource: 'Get-or-create this org's ontology Agent + shared memory profile.' This clearly conveys an ensure operation and immediately distinguishes it from read-only siblings like memory_agent_get and memory_entity_view.

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

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

The description explicitly routes read-only needs to alternatives: 'Other agents read the profile with memory_agent_get or memory_entity_view.' It also gives useful context on when harness vs cloud agent naming applies. It stops short of explicitly contrasting this with memory_agent_set, but the get-or-create framing largely communicates the intended use.

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

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

No annotations are provided, so the description carries the burden. It clearly states this is a read operation and that the memory is org-shared, which conveys an access boundary, but it does not mention permissions, side effects, failure modes, or what happens for missing agents.

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

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

The description is one short, front-loaded sentence with no redundant or filler words. Every word adds scope: read, audience, and resource type are all present.

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

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

For a read-only lookup with zero required parameters and an output schema present, the description plus detailed parameter descriptions is largely sufficient for an agent to select and call the tool. It lacks only explicit alternative-tool routing and behavioral caveats, which are minor for a simple read operation.

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

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

Schema description coverage is 100%, with each parameter meaningfully documented as a Harness label, ontology slug, or Cursor cloud agent id. The tool description itself adds no parameter-level meaning beyond the schema, which aligns with the baseline of 3.

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

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

The description uses a specific verb, 'Read', and a precise resource, 'another agent's (or your own) org-shared ontology memory.' This scope separates it from memory_agent_list, memory_agent_set, and content-specific getters like memory_skill_get or memory_state_get.

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 rather than explicit: the tool reads another agent's shared ontology memory, and the schema notes that omitting identifiers fetches the caller. However, the description gives no direct when-to-use guidance, no exclusions, and no alternatives such as memory_recall or memory_entity_view.

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

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

No annotations are provided, so the description bears the transparency burden. It reveals that the operation is a list scoped to the org and that referenced memories are available to other agents, but it does not mention auth requirements, pagination behavior, or filtering semantics. The read-only nature is implied by 'List', and the output schema covers return structure, so this is adequate rather than comprehensive.

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

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

The description is a single, front-loaded sentence that efficiently communicates action, resource, scope, and purpose. The parenthetical adds meaningful context without padding.

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

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

For a simple, read-only list tool with optional parameters and an output schema, the description covers the essential intent and scope. It could be slightly richer by clarifying what 'Agent ontology memories' are or pointing to sibling tools, but nothing critical is missing for selecting and invoking 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 only 33% (only 'runtime' has a description), and the tool description adds no parameter-level guidance. It does not explain how 'limit', 'offset', or 'runtime' affect results, nor does it compensate for the low schema coverage.

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

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

The description clearly states a specific action ('List'), a precise resource ('Agent ontology memories'), and an organizational scope ('in this org'). The parenthetical '(other agents can reference them)' adds semantic context that helps distinguish this listing tool from related get/set/ensure agent-memory tools.

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

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

The description gives clear context for when to use the tool: when the agent needs to discover Agent ontology memories available in the org, specifically ones that other agents can reference. It does not explicitly name alternatives or exclusion criteria, 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?

With no annotations provided, the description carries the full disclosure burden. It does disclose the core behavioral trait (a destructive replace with create-if-needed semantics) and the org-shared scope, which is useful. However, it omits any mention of permissions, reversibility, or side effects on related memory entities, so behavioral disclosure remains thin.

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

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

The description is a single front-loaded sentence with a parenthetical that adds meaningful upsert context. It contains no filler and every clause earns its place.

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

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

For a straightforward set operation, the description covers the core function, and the output schema plus fully documented parameters provide much of the necessary context. But the large memory_* sibling family includes memory_agent_ensure, which likely overlaps, and without usage/alternative guidance or side-effect disclosure an agent may route incorrectly. Operationally adequate, contextually under-specified.

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

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

Schema description coverage is 100%, with each parameter already documented: body_md is described as a compressed, org-visible markdown profile; name, slug, agent, and cursor_agent_id are optional attribution labels. The tool description adds no meaning beyond schema, so the baseline score of 3 applies.

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

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

The description states a specific verb ('Replace') and resource ('an agent's org-shared memory profile'), and adds the upsert qualifier 'creates the entity if needed.' This makes the tool's function clear and distinguishes it from read-oriented siblings like memory_agent_get and memory_agent_list, but it does not explicitly contrast it with similar write/ensure siblings such as memory_agent_ensure.

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

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

The description gives no guidance on when to use this tool versus the closely related memory_agent_ensure or other memory set tools like memory_soul_set, memory_playbook_set, or memory_procedure_set. There are no exclusions, prerequisites, or alternative conditions, leaving the agent to infer usage solely from the verb 'Replace.'

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

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

With no annotations provided, the description carries the full behavioral burden. It explains that recall happens in parallel across multiple pillars and an optional graph, uses 'the secure retrieval path', ranks and packs results, and lists exact return fields. This goes well beyond the schema and gives the agent a solid mental model of the tool's behavior, though it does not explicitly state side effects or failure modes.

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

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

The description is efficiently organized: purpose first, then mechanism, usage guidance, and return values. Every sentence contributes useful information, though the 'Fans recall across...' phrasing is slightly awkward and jargon-heavy.

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

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

Given an output schema exists, the description covers all essential context: what the tool does, how it behaves internally, when to use it, what alternatives exist, and what it returns. The parameter details are fully covered by the input schema, so nothing critical is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters including defaults and intended effects. The description does not add significant per-parameter meaning, but it also does not need to; the baseline of 3 applies because the schema carries the heavy lifting.

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

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

The description states a specific verb and resource: 'Assemble one token-budgeted, cited context pack for a task.' It clearly differentiates itself from sibling tools by naming the serial memory_recall/memory_procedure_get/memory_graph_related calls it replaces, so an agent can tell what this tool does and how it differs.

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

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

The description gives explicit usage guidance: 'Use this once at the start of a task instead of issuing serial memory_recall / memory_procedure_get / memory_graph_related calls.' This directly tells the agent when to use this tool and names the alternatives, leaving no ambiguity about the intended workflow.

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

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

With no annotations provided, the description carries the full burden. It explicitly says 'Returns', making clear this is a retrieval/status operation, and it discloses the no-data behavior ('found=false when last night wrote nothing'). It also explains how the note relates to memory_recall, adding useful context. It does not discuss auth or side effects, but for a zero-parameter read-only report tool this is sufficient.

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

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

The description is three short sentences: purpose, return/edge behavior, and relationship to memory_recall. Each sentence adds distinct value, no filler is present, and the core purpose is front-loaded.

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

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

For a zero-parameter tool with an output schema, the description is complete enough to select and invoke it correctly. It covers the purpose, the found=false edge case, and the relationship to memory_recall, so no critical behavioral information is missing.

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

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

The input schema has zero properties and 100% schema description coverage, so there are no parameters to document. The baseline for zero-parameter tools is 4, and the description does not need to add parameter-level 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 opens with a specific purpose: 'Latest nightly dream report for this org (what changed overnight)' and then states the exact returned artifact: 'most recent leftover-distill + curator report'. It clearly differentiates from the sibling tool memory_recall by noting the same note is a normal semantic memory/wiki page that memory_recall can find.

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

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

The description gives clear context for when to call: to get the latest overnight report, and it handles the empty case with 'found=false'. It also points to memory_recall as an alternative for retrieving the same note as semantic memory. However, it stops short of an explicit when-not-to-use statement, so it earns a 4 rather than a 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses the data sources involved but says nothing about side effects, whether the operation is read-only, performance characteristics, or behavior on empty results — leaving the agent to infer from the title 'View'.

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

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

A single sentence with no filler. The action is front-loaded, and the list of aggregated sources is compact.

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 output schema exists and the one parameter is clear, but the description gives no guidance on what 'roll up' returns structurally or when to prefer this over memory_recall or work_list — a notable gap for an aggregation 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 coverage is 100%, so the parameter is well documented. The description adds minimal extra meaning ('one entity' reiterates the singular slug), which is acceptable per baseline.

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

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

The description uses the verb 'roll up' with a clear resource (one entity) and enumerates the four data domains (wiki, memories, graph neigbors, work). This distinguishes it from single-purpose siblings like memory_recall or work_list, though the informal phrasing leaves some ambiguity about the delivered artifact.

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

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

Usage is implied: the agent should call this when it needs a consolidated view across the named sources for a single slug. It does not name alternates or explicitly state when not to use, but the aggregation scope provides adequate context.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. 'Browse' implies a non-mutating list operation and the org-wide default scope is a useful non-obvious detail. However, it does not mention ordering, pagination behavior, or what an 'episode' actually represents.

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

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

The description is a single front-loaded sentence with no filler words. It is efficient, though slightly too terse to fully orient an agent to the episodic-timeline concept.

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 most parameters are documented, so return values and filters do not need to be repeated. Still, with no annotations and many sibling memory tools, the description could usefully state that episodes are returned in chronological order and that this is the go-to tool for browsing the org's episodic history.

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 high (80%), and the schema already documents the main parameters. The description adds no parameter-specific meaning beyond restating the default org scope, which the agent parameter already covers.

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

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

The description identifies a concrete read action ('Browse') and a distinct resource ('episodic timeline'), and it adds a useful scope qualifier ('shared within the org by default'). It clearly reads as a list/history tool, though it does not explicitly route away from related memory tools like memory_recall.

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

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

No guidance is given about when to use this tool versus alternatives such as memory_recall, memory_session_get, or memory_action_log_list. The only contextual hint is the default org-wide scope, which is behavioral rather than a usage criterion.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses soft-delete semantics, the memory:delete permission requirement, the refusal of agent seats, the supported console-human path, and the unsupported procedural-delete case. This is exemplary behavioral disclosure for a destructive tool with zero annotation coverage.

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, each earning its place: the core action, the memory_id provenance, the procedural exclusion, and the seat/approval routing. It is front-loaded with the primary purpose and avoids any filler.

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

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

The description covers the essential behavioral facts: what is deleted, how to get the id, who is allowed, what permission is needed, and what alternative to route through. The output schema exists, so return-value details do not need to be in the description. Nothing necessary for correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful extra context by stating that memory_id is the memory_items UUID returned by memory_recall and that reason is an audit requirement. It does not repeat schema details verbatim, and parent_id is adequately covered by the schema.

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

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

The description uses a specific verb ('Soft-delete'), names the target resource ('semantic/episodic memory by id'), and immediately distinguishes this tool from memory_forget_procedure and memory_forget_skill by stating 'Procedural deletes are not supported via this tool.' An agent can tell exactly what this tool does and what it does not do without opening any sibling 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?

The description gives explicit when-not-to-use guidance: agent seats are refused, and the tool directs the agent to call request_gated_approval(gate="destructive") instead. It also specifies that memory_id must come from a previous memory_recall, and it excludes procedural deletes. This is strong, actionable 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?

With no annotations, the description carries the full behavioral disclosure burden. 'Soft-delete' hints at non-destructive behavior, but the description does not explain what soft-delete means operationally, whether it is reversible, what happens to inactive versions, or what side effects occur.

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

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

The description is a single, tightly scoped sentence with no filler. The key action, target, and scope are front-loaded, making it easy for an agent to parse quickly.

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

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

The description is minimally viable for invoking the tool, especially with a complete schema and output schema present. However, it lacks context about soft-delete semantics, version behavior, and how this relates to the sibling memory_forget and memory_forget_skill 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?

Schema coverage is 100%, so the parameters are already well documented. The description adds contextual meaning by clarifying that the operation targets 'all active versions' by name, but it does not meaningfully elaborate on parameter semantics beyond the schema.

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

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

The description clearly states a specific verb ('soft-delete') and resource ('all active versions of a playbook by name'), making the core operation unambiguous. It does not explicitly distinguish itself from sibling tools like memory_forget or memory_forget_skill, and the use of 'playbook' rather than 'procedure' relative to the tool name introduces minor ambiguity.

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

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

There is no guidance about when to use this tool versus alternatives such as memory_forget, memory_forget_skill, or memory_playbook_set. The intended context is only implied by the name and resource type, with no explicit exclusions or preconditions.

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

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

With no annotations, the description carries the burden. It usefully discloses 'soft-delete' rather than hard delete and that all active versions are affected. However, it does not mention reversibility, authorization needs, or what happens to the skill from the perspective of resolution or retrieval, leaving some behavioral context undisclosed.

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

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

The description is one tight sentence that front-loads the action ('Soft-delete') and target ('all active versions of a skill by name'). There is no filler, repetition, or unnecessary detail.

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

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

For a simple tool with two flat required parameters and an output schema, the description is mostly sufficient to invoke correctly. It clearly states the operation, scope, and target. It only lacks a brief usage-routing note relative to sibling delete/forget tools, which prevents a 5.

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

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

Schema coverage is 100%, and both parameters are already documented in the input schema (name and reason with 'Audit reason; required'). The description only re-emphasizes 'by name' and adds no new semantic detail for either parameter, so the baseline 3 applies.

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

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

States a specific verb and resource ('soft-delete all active versions of a skill by name'), which clearly identifies the operation and target. The scope 'all active versions' also helps distinguish it from sibling memory forget/procedure tools.

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

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

No guidance is given about when to choose this tool instead of related siblings like memory_forget, memory_forget_procedure, memory_skill_set, or memory_skill_get. The intended use is inferable from the name and description, but no explicit alternatives or exclusions are provided.

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

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

With no annotations, the description carries the behavioral burden. It usefully discloses that the tool is a no-op with a reason when the graph is not enabled and that predicate must be registered. However, it does not disclose duplicate or overwrite behavior, entity existence requirements, or side effects beyond graph creation.

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, each earning its place: purpose, no-op behavior, usage scenario, and predicate constraint. The description is front-loaded and contains no filler or redundancy.

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

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

The description is adequate for invoking a simple relation-recording tool, and the output schema reduces the need to explain return values. It leaves gaps around duplicate relationships, whether entities must already exist, and how this relates to memory_graph_related, which matter for a write operation with no annotations.

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

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

Schema coverage is high, so the baseline is 3. The description adds value by giving a concrete triple example ('alice -> works_on -> teamshared') and by adding the constraint that predicate must be a registered link type, which the schema itself does not state.

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

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

The description starts with a specific verb and resource: 'Record an explicit relationship in the optional org-scoped graph store.' This makes the tool's core purpose clear, but it does not explicitly differentiate it from the sibling memory_graph_related, so the agent must infer the distinction from the verb 'Record.'

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 an explicit use case ('Use this when you learn a structured fact ... that vector recall would obscure') and points the agent to memory_ontology_list for predicate validation. It does not explain when not to use it or how it compares to memory_graph_related, but the guidance is clear and actionable.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly indicates a read-only lookup ('Return entities') and adds useful context about the graph store and depth hops. However, it does not disclose traversal directionality, deduplication, or error behavior.

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

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

The description is a single sentence that is front-loaded with the operation and resource. Every word earns its place, with no redundant phrasing.

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

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

An output schema exists, so return value details are covered. The description is minimally sufficient for basic invocation, but the missing sibling differentiation and unaddressed limit semantics leave room for improvement given the low annotation coverage.

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

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

Schema coverage is only 33%, so the description must compensate. It adds meaning by clarifying that depth is measured in hops and that the query expands neighbors from name. It does not explain the limit parameter, though the name and schema constraints make its purpose reasonably inferable.

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

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

The description uses a specific verb ('Return'), names the resource ('entities related to name'), and identifies the mechanism ('graph store'). It does not fully differentiate from the similarly named sibling memory_graph_relate, which prevents a 5.

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

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

There is no guidance on when to use this tool versus alternatives, and no alternatives are named. Given the close sibling memory_graph_relate, the lack of usage direction is a notable gap.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. 'Register or update' conveys an upsert-like mutation, but it does not explain what happens to existing link types, whether changes are reversible, or what side effects occur. For a mutation tool, this is a notable transparency gap.

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

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

The description is a single sentence with no filler or redundancy. The key action and resource are front-loaded, making it easy to scan. It is as concise as possible for the information it provides.

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

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

The description plus the fully documented schema is adequate for invoking the tool, especially since an output schema exists. However, with no annotations and minimal behavioral detail, the complete picture of the tool's effect on the ontology is missing. It is a minimum-viable definition rather than a richly informative one.

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

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

Schema description coverage is 100%, and each parameter already has a meaningful description, including allowed cardinality values and the meaning of to_kinds/from_kinds. The tool description itself adds no parameter-level meaning, but the schema already carries that weight. Baseline 3 is appropriate.

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

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

The description states a specific action ('Register or update') on a specific resource ('custom org link type'), making the core purpose clear. It is distinguishable from sibling tools like memory_ontology_object_kind_set because it targets link types, not object kinds. However, it does not explicitly contrast itself with that sibling, so it stops short of a 5.

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

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

The description implies when to use the tool: when the agent needs to register or update a custom org link type. It gives no explicit guidance about when not to use it or which sibling tool to prefer instead. The context is inferable from the name and description, but not directly stated.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. 'List' conveys a read-only operation, but the description does not explicitly state that no changes are made, whether the result is a complete snapshot, or whether access constraints apply. For a zero-parameter tool the behavior is simple, but more explicit transparency would be stronger.

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

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

The description is a single, efficient sentence with no filler. The verb and resource are front-loaded, and the four content categories are listed compactly without unnecessary explanation.

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

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

For a simple zero-parameter listing tool with an output schema, the description is largely complete: it states the purpose and what the output covers. The main gap is the absence of explicit guidance about when to use this tool instead of sibling ontology mutation tools, though this is a minor omission given the tool's simplicity.

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

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

The tool has zero parameters and 100% schema description coverage, so there is no parameter meaning for the description to add. The description still contributes by naming the content categories of the output, which is useful semantic context beyond the empty schema.

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

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

The description uses a specific verb ('List') and identifies a clear resource ('org ontology schema'), then enumerates exactly what is included: link types, object kinds, interfaces, and action types. This clearly distinguishes it from sibling mutation tools such as memory_ontology_link_type_set and memory_ontology_object_kind_set.

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: it is a listing operation, so an agent would call it to inspect the ontology schema before using related memory_ontology_* tools. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.

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

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

With no annotations provided, the description carries the full transparency burden. It does disclose the two material consequences — FK remapping and deletion of the duplicate — which is real value beyond the schema. Missing are reversibility, conflict-resolution behavior, and permission or transaction notes, which matters for a destructive operation. Score 3.

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

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

A single sentence that front-loads the core operation ('Merge drop_slug into keep_slug') and appends only the essential behavioral parenthetical. No filler; every phrase earns its place.

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

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

With an output schema present and full parameter coverage, the description need not document return values. It captures the core operation and side effects, but for a destructive merge it would benefit from caveats about irreversibility and handling of conflicting properties between the two entities. Adequate with clear gaps — 3.

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

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

Schema description coverage is 100%, with meaningful per-parameter descriptions ('Duplicate entity slug to merge away', 'Canonical entity slug to keep'), so the baseline is 3. The tool description echoes the directionality but adds no parameter detail beyond what the schema already provides.

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 — 'Merge drop_slug into keep_slug' — with clear directionality between the canonical and duplicate entities. The parenthetical '(remap FKs, delete duplicate)' adds operational specificity that distinguishes it from the other memory_ontology_* siblings (list, propose_entity, rekind_entity). It stops short of 5 only by not explicitly naming sibling distinctions.

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?

'Delete duplicate' implies a deduplication context, giving an agent a reasonable when-to-use signal, and nothing misleading is stated. However, there are no explicit alternatives, no when-not conditions, and no prerequisites (e.g., verifying both slugs exist) before a destructive merge. That is implied guidance at best — 3.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does indicate an upsert behavior ('register or update'), but it does not disclose whether updating overwrites properties_schema, whether existing associated entities are affected, any permission requirements, or the consequences of changing an object kind. This is minimal transparency for a mutation tool.

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

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

The description is a single, front-loaded sentence with no filler. Every word earns its place, and the core verb-resource relationship is immediately visible.

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 input schema and output schema cover parameters and return values, so those dimensions do not need explanation in the description. However, for a mutation tool with no annotations, the description omits usage boundaries and side-effect details, leaving meaningful gaps in contextual completeness.

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

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

The input schema covers all four parameters with descriptions, so the schema already does the heavy lifting. The description adds no additional parameter-level meaning beyond indicating that the tool concerns a custom org object kind, which maps to the required 'name' parameter. Baseline 3 is appropriate.

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

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

The description states a specific action pair (register or update) and a concrete resource (custom org object kind), which clearly distinguishes it from sibling tools like memory_ontology_link_type_set or memory_ontology_rekind_entity. It is immediately clear what the tool operates on and what it does.

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

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

The description provides no guidance about when to use this tool versus alternatives such as memory_ontology_link_type_set or memory_ontology_rekind_entity. It also does not explain conditions for registering versus updating, or any prerequisites or exclusions. Usage context is left entirely 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses one meaningful trait — the entity is 'active immediately', implying a direct creation with no approval or staging step — which is more than a bare verb. However, it says nothing about prerequisites (e.g., whether the kind must already be registered), idempotency, reversion, or failure behavior when the kind does not exist.

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

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

The description is a single eight-word sentence that is front-loaded and contains no wasted words; the parenthetical earns its place by disambiguating the semantics of 'propose'. It is terse to the point of under-specification, but that deficiency is properly penalized in other dimensions rather than here.

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 existence of an output schema and 100% parameter coverage lowers the burden, and the tool's shape is simple (flat, 1 required parameter, no enums). Even so, an agent cannot determine from this description when to select it over memory_remember or memory_entity_view, or whether the named kind must already exist in the ontology. For a tool in a crowded sub-family, this is minimally viable but not complete.

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

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

Schema description coverage is 100%, so the baseline is 3 even with no parameter detail in the description. The word 'typed' reinforces the role of kind/kind_name and implies properties should conform to the kind schema, marginally reinforcing the schema's 'Registered object kind' note. It adds no syntax, defaults, or format guidance beyond what the schema already documents.

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 ('Propose') and resource ('typed ontology entity'), and the parenthetical '(active immediately)' clarifies that the entity takes effect at once rather than requiring approval. It is distinguishable from sibling tools like memory_ontology_list, memory_ontology_merge_entities, and memory_ontology_rekind_entity, though it does not name them. It stops short of 5 because 'propose' could still be misread by an agent unfamiliar with the immediate-activation parenthetical.

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

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

The description provides no guidance on when to use this tool versus alternatives such as memory_remember, memory_entity_view, or the other memory_ontology_* siblings. With a sibling list of 90+ tools and no when-to-use or when-not-to-use conditions, an agent is left to infer applicability. This is a clear gap.

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

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

With no annotations, the description must disclose behavioral consequences on its own. It communicates that an existing entity is mutated, but omits ownership details such as whether the previous kind is overwritten, whether the change is reversible, whether permissions are required, or what happens if kind and kind_name are both null. This is a material gap for a write operation.

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