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

With no annotations provided, the description carries the full burden. It discloses key behaviors: upsert semantics, returning an opaque version for optimistic concurrency, and idempotent behavior via `idempotency_key`. These are important beyond what annotations would provide. It doesn't mention failure modes or limitations, but the disclosed traits are significant and clearly described.

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

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

The description is concise and front-loaded, with the main purpose stated first. It uses three short paragraphs that each add value: purpose, upsert/version behavior, and idempotency. It is not overly verbose, though it could be slightly tighter by merging related thoughts. Overall, it is well-structured and efficient.

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

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

Given the tool's complexity (11 parameters, 0% schema coverage, no annotations), the description is incomplete. It covers the core upsert and idempotency behavior but leaves many parameters unexplained, which could lead an agent to misuse the tool. The presence of an output schema helps with return values, but the input side is under-documented. A more comprehensive description should at least summarize the role of key parameters like `memory_type`, `priority`, and `ttl`.

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

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

Schema description coverage is 0%, so the description must compensate. It only explains `idempotency_key` in detail; the other 10 parameters (e.g., `key`, `value`, `ttl`, `priority`, `metadata`, `memory_type`) are not elaborated. The description does not clarify what `value` should be, how `memory_type` affects behavior, or the meaning of fields like `canonical` and `importance`. This is a significant gap for a tool with 11 parameters.

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

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

The description clearly states the tool's purpose: 'Write a memory entry to hosted Bilinc Cloud.' It further explains the upsert behavior ('Creates the entry if it is new and revises it if the key already exists'), which distinguishes it from siblings like `revise` and `recall`. This is a specific verb+resource with differentiation.

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

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

The description gives context by explaining that the returned version can be passed to `revise` or `forget`, implying when those tools are appropriate. It also explains idempotency usage for retries. However, it does not explicitly state when NOT to use this tool or name alternatives for read/delete scenarios, so it falls short of a 5.

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

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

Annotations only declare the safety profile (readOnly=false, destructive=false, idempotent=false); the description goes well beyond that by stating exactly what mutates (updated time, history entry), what does not (stored value), the write cost, and two concrete error codes with their trigger conditions. That is precisely the extra behavioral context annotations cannot convey.

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

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

Front-loaded with the core action in the first sentence, followed by only the details an agent needs: mutation semantics, cost, and failure modes. No repetition of the title or schema, and every sentence earns its place.

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

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

For a mutation tool with an output schema present, the description covers behavior, side effects, and error conditions thoroughly enough to call it safely. The remaining gap is the unexplained reason and idempotency_key parameters, which neither the schema nor the description defines.

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

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

Schema description coverage is 0% across 4 parameters, so the description must carry the burden. It explains expected_version well (an optimistic-concurrency check that yields version_conflict), but says nothing about key, reason, or idempotency_key — notably that idempotency_key is the dedupe mechanism even though annotations declare idempotentHint=false. Partial compensation only.

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

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

The description states a specific verb+resource (record that a memory is still accurate) and immediately clarifies the key distinction from a value-changing edit: 'The stored value is not changed.' That implicitly separates it from siblings like revise and rollback. It never names a sibling explicitly, so it falls just short of the top band.

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

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

Usage is implied by 'Record that an existing memory is still accurate,' and the failure modes give implicit preconditions (the key must exist, and expected_version must match). However, there is no explicit when-to-use/when-not guidance or named alternative (e.g., revise when the value actually changed), leaving the routing decision 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. It discloses that the operation is read-only and free, values are redacted unless include_values is set, and overly large diffs are refused rather than silently truncated. This gives the agent important behavioral expectations.

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

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

The description is concise, with the main purpose in the first line and additional key behaviors following. Every sentence adds value, and it is not padded with fluff.

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

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

The description covers essential behavioral context: read-only, free, redaction behavior, and refusal of large diffs. The output schema exists, so return format need not be detailed. However, it does not mention the limit parameter or edge cases, which would make it fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the semantics of to_snapshot_id (optional, defaults to current state) and include_values (controls value redaction), but does not explain limit or from_snapshot_id in detail. This partial coverage earns a 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 states the primary action: 'Compare a checkpoint against another checkpoint or current state.' This uses a specific verb ('Compare') and resource ('checkpoint'), and the mention of 'current state' distinguishes it from sibling tools like snapshot or rollback.

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 clear context for when to use the tool: to compare checkpoints or see changes since a checkpoint. It also explains the key behavior of leaving to_snapshot_id empty. However, it does not explicitly mention alternatives or when not to use it, which keeps it from 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 zero annotations the description carries the full burden and does so well: it discloses the audit-trail write, that the deleted value is never returned, that purge additionally strips stored values from history and all checkpoints (leaving key names and hashes), that purge works on already-forgotten entries, and that it cannot be undone. This is exactly the context annotations would otherwise supply.

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

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

Front-loaded with the destructive warning, then organized into purpose, behavior, purge semantics, and alternative routing. Slight redundancy between the standalone "DESTRUCTIVE." line and "This is a destructive operation:", and the prose is a bit long, but nearly 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?

An output schema exists and the description still usefully notes the deleted value is never returned. For a destructive mutation with no annotations the coverage is strong, but the two control parameters (idempotency and version pinning) are unaddressed, which matters for an irreversible operation.

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

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

Schema coverage is 0%, so the description must explain all five parameters; it covers `key`, `reason` (required, written to audit trail) and `purge` (with detailed storage/history semantics) well. It says nothing about `idempotency_key` or `expected_version`, leaving retry and optimistic-concurrency behavior undocumented in both schema and description.

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

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

States a specific verb and resource ("Remove a memory from active recall") and immediately disambiguates from the closest sibling by naming `revise` as the corrective alternative. The DESTRUCTIVE flag up front makes the operation class unmistakable.

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

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

Gives explicit when-to-use ("state that is genuinely obsolete"), when-not-to-use and the alternative ("To correct a memory rather than remove it, use `revise`"), plus a separate rule for the purge flag ("Only purge when the user asks for the content to be gone, not just out of recall"). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint and idempotentHint, but the description goes far beyond by describing entry structure (operation, time, reason, source, before/after values), the rollbackSnapshotId behavior, the 'values: none' suppression, and that forgotten values are withheld. This is substantial behavioral context.

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

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

Front-loaded with the core action and ordering, then structured detail. It is a bit list-like but every sentence conveys useful semantics; 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?

An output schema exists, so return format need not be explained, but the description still enriches it with field-level semantics and edge cases (rollback operations, forgotten values, exists=false). Complete for an agent to call correctly.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It explains the `values` parameter's semantics ("none" suppresses before/after values) and the `key` parameter's scope, compensating for the bare schema.

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

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

The description opens with 'Show the recorded changes to one memory key, newest first', a precise verb+resource+ordering statement. It is clearly distinguishable from siblings like diff or snapshot by specifying the auditable change log of a single key.

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 implicitly tells when to use the tool (auditing past changes to a key) but never names or contrasts with alternatives such as diff or snapshot. No explicit 'use this instead of X when Y' guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds 'free', the paging contract (same `order` with a `cursor`, `nextCursor` null on the last page), and the `values` size modes ('preview' default, 'full', 'none'). That is real behavioral context beyond the structured fields, though it does not quantify result size or say whether paging under concurrent writes is stable.

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

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

Front-loaded with the purpose, then cost, then filters, then return/paging shape — a logical order with no filler sentences. It is dense and slightly run-on ('Returns up to `limit` entries ... and a value whose size follows `values`'), but every clause carries parameter or paging information that is otherwise undocumented.

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 0% schema descriptions, the definition documents every parameter, the default for `order` and `values`, the limit range, and the full cursor loop. An output schema exists, yet the description still names the returned fields and the `total`/`nextCursor` semantics, which is exactly what an agent needs to page 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 coverage is 0% — only titles and defaults — so the description carries the full burden, and it does: it explains `prefix`, `memory_type`, ISO-8601 `updated_after`/`updated_before`, `sources` as exact 'saved by' values, `order` values with 'key' default, `cursor` reuse rule, `limit` (1-100), and `values` modes. The only gap is that valid `memory_type` values are never enumerated (no enums in schema).

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

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

States a specific verb and resource ('List the memories stored in this Bilinc Cloud project'), so an agent immediately knows this is an enumeration tool. However, it never distinguishes itself from the sibling `recall` (presumably retrieval/search) or `history`, so the boundary is left to inference.

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

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

Usage context is implied through the enumerated filters and the 'Read-only and free' note, which tells an agent this is the cheap path for browsing. There is no explicit when-to-use/when-not statement and no routing advice to `recall` or `history` for search-style lookups.

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 takes on the burden of explaining behavior. It discloses that higher profiles 'do more reflection and return more provenance' and are 'gated by the workspace plan,' which is valuable context. It also mentions cost implications. However, it does not explicitly state whether recall is read-only or describe other side effects, leaving some ambiguity for a no-annotation 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 two sentences, front-loaded with the primary purpose. Each sentence earns its place: the first states the core action, and the second explains the profile parameter's nuances and its relationship to the status tool. There is no redundant fluff or repetition of schema information.

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

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

Given the tool's complexity (6 parameters, one required), the description covers only the retrieval purpose and profile specifics. The output schema exists and can explain return values, but the description does not clarify other parameters or edge cases. It is adequate for a basic retrieval tool but feels incomplete for an agent needing to use memory_types, query_timestamp, or explain effectively.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It only explains the 'profile' parameter in detail, covering just one of six parameters. The description does not address query, limit, explain, memory_types, or query_timestamp, leaving the agent without sufficient guidance for these parameters despite their self-explanatory names.

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

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

The description states a specific verb and resource: 'Retrieve memories from hosted Bilinc Cloud.' It clearly distinguishes from siblings like commit_mem, revise, and forget by focusing on retrieval. The additional note that 'Smart retrieval is this argument, not a separate tool' further disambiguates from potential alternatives.

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

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

The description provides practical guidance: 'call `status` to see which profiles this key may use' indicates a prerequisite for using higher profiles. It also clarifies that profile-based retrieval is not a separate tool. However, it does not explicitly state when to use recall vs. other memory operations or list exclusions, so it misses some explicit alternative guidance.

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

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

With no annotations, the description carries the disclosure burden. It reveals important behaviors: never creates, fails with memory_not_found, supports expected_version for concurrency (version_conflict). It does not mention auth or reversibility, but for a memory tool these are less critical. Slightly incomplete but strong.

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 adding substantive value: purpose, alternative differentiation, failure mode, concurrency behavior. No filler or repetition, well 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 7 parameters and zero schema descriptions, the description is too thin. It covers core use cases and error scenarios, but omits guidance on the optional parameters and does not describe the response shape (though an output schema exists). It is minimally 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 0%, so the description must compensate. It only explains `expected_version` and implies `key` must exist, but does not clarify the meaning or usage of `value`, `reason`, `strategy`, `importance`, or `idempotency_key`. This leaves most parameters under-specified.

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: 'Deliberately replace an existing memory.' It clearly distinguishes the tool from siblings by stating it is for corrections/superseding rather than creating, which aligns with the sibling context.

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 says to use this instead of `commit_mem` when correcting or superseding existing knowledge, and notes that it never creates (fails with memory_not_found). This provides clear when-to-use and when-not-to-use guidance.

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

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

With no annotations supplied, the description carries the entire behavioral burden and does so: it flags the operation as DESTRUCTIVE in execute mode, spells out that execute permanently discards every memory created or changed since the checkpoint, and documents the short-lived confirmation_token lifecycle. It also names the exact failure condition and states that reason is written to an audit trail.

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 destructive warning is front-loaded, then the two stages are enumerated in execution order with per-mode notes attached to the relevant stage. Every sentence carries operational information; nothing is restated from the schema or 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 destructive state-mutating tool with six parameters and no annotations, this is close to complete: safety profile, sequencing, token dependency, failure mode, and audit behavior are all covered, and an output schema exists so return values needn't be described. The gap is the undocumented idempotency_key and the lack of any note on what snapshot_id refers to or how it is obtained.

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

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

Schema description coverage is 0%, so the description must compensate, and it explains mode semantics, the required reason and its audit purpose, limit's 1-500 range and its irrelevance in execute, and confirmation_token's requirement in execute. Two parameters are left unaddressed: snapshot_id is only obliquely implied by "checkpoint," and idempotency_key is never mentioned at all.

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

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

"Restore the project to a checkpoint" is a specific verb+resource statement, and the two-stage preview/execute framing makes the operation unambiguous. It doesn't explicitly contrast itself with siblings like snapshot, diff, or confirm, so an agent must infer the routing rather than being told.

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 states the mandatory ordering (preview before execute), what each mode is for, and the operational rule to act on a preview promptly instead of reusing an old one. The exclusions are explicit: limit is ignored in execute, and execute fails with state_changed_since_preview if the project moved.

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, but the description discloses key behavior: list is free, ordering is newest-first, and neither action returns checkpoint contents. This adds meaningful context beyond the schema, though it does not cover side effects of creation 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 concise sentences cover purpose, usage advice, and a behavioral caveat with no redundancy. Information is front-loaded and the description is appropriately sized.

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

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

The tool has an output schema and a moderate parameter count; the description covers the main workflows. It lacks detail on parameter meanings and restore mechanics, but overall is sufficient for basic usage.

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 explains the action parameter values (create/list) but does not clarify label, limit, metadata, or idempotency_key. Schema coverage is 0%, so these parameters remain ambiguous despite self-explanatory titles.

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

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

Clearly states the tool creates or lists project checkpoints, with specific action values. Differentiates from sibling tools by focusing on checkpoint capture/list rather than memory/commit/rollback operations.

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

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

Explicitly advises using create before risky work, and notes list is free and returns newest first. Does not name alternative tools but provides context for when each action is appropriate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool is 'Read-only and never billed' and that 'Secrets are never returned,' which are important safety traits. It does not elaborate on caveats like rate limits, but the disclosed traits are strong for a status 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 three sentences and every sentence earns its place: the first states the purpose, the second conveys safety and usage, and the third reassures about secrecy. It is front-loaded with the most important information and contains no redundant words.

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

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

Given the tool has no parameters, an output schema is present, and the tool is simple (status report), the description fully covers what an agent needs to know. It states what the tool returns (workspace, plan, capabilities), when to use it, and that it is safe and read-only. The existence of the output schema eliminates the need to describe return formats.

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

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

The tool has zero parameters, so the schema provides no parameter semantics. Per the rubric, a baseline of 4 is appropriate for 0-parameter tools. The description adds no parameter information because there is nothing to add.

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 'Report the authenticated Bilinc Cloud workspace, plan, and capabilities,' which uses a specific verb and clearly identifies the resource and scope. This distinguishes it from sibling lifecycle tools like commit_mem and forget, which perform mutations. The purpose is unambiguous and immediately understood.

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

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

The description provides explicit guidance: 'Use this to discover which lifecycle operations and recall profiles the current API key may use before attempting them.' This makes the intended use case clear. It does not explicitly exclude other uses or name alternatives, but the context is sufficient for an agent to know when to call this tool.

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