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 add useful behavioral detail beyond the schema by explaining that a parent 'collapses onto a basic type' and that aliases are optional. However, it does not disclose side effects, persistence, idempotency, failure behavior, or whether adding an entity type can affect existing ontology data.

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

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

The description is a single, well-structured sentence that front-loads the purpose and usage condition before compactly covering naming and optional parameters. Every phrase earns its place, with no wasted words.

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

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

The tool has 5 parameters, 0% schema description coverage, no annotations, and no output schema, so the description needs to do substantial work. It provides the core purpose and routing, but leaves out the dataset parameter, potential side effects, and what happens after the entity type is added. This is not complete enough for a mutation tool with no structured annotations to fall back on.

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 adds meaningful semantics for name (PascalCase), parent (collapses onto a basic type), and aliases (optional). However, it omits the dataset parameter entirely and does not explain the required description parameter, leaving two of five parameters without added 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 clearly states the action ('Add an entity type') and the exact resource, with a specific scoping condition ('when nothing in describe_ontology fits'). It also provides the naming convention (PascalCase) and distinguishes itself from the sibling describe_ontology 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 names the alternative tool (describe_ontology) and gives the condition for choosing this tool over it: use only when nothing in describe_ontology fits. This is clear when-to-use guidance that 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?

No annotations are provided, so the description carries the disclosure burden. It does disclose meaningful behavior: output is grouped by subject, and hotspots indicate one subject holding several values for a relation. However, it does not state whether the operation is read-only, how results are bounded, or what happens when all parameters are null.

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 concise sentences with no filler or repetition of the tool name. The core output behavior is front-loaded, and the follow-up instruction to judge candidates earns its place as actionable guidance.

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

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

With three optional parameters, no annotations, and no output schema, the description is not complete enough for reliable invocation. It leaves unresolved what dataset selects, whether entity_names and relation_ids are alternatives or combined filters, and what an empty call returns. The grouping and hotspot summary is useful but insufficient as a standalone guide.

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 clarifies that entity_names and relation_ids select the entities or relations around which facts are gathered. However, it never mentions the dataset parameter, nor does it explain how the parameters combine, default, or behave when null.

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 providing facts around given entities or relations, grouped by subject, with hotspots for multiple values on one relation. This distinguishes it from generic recall or history tools. It lacks an explicit verb like 'retrieve' or 'list', but the intent is not ambiguous.

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 used to surface contradiction candidates and directs the agent to judge them with the mnemoth-contradictions skill, giving a clear follow-up step. However, it does not explicitly state when to prefer this over siblings like memify_candidates or recall, nor does it describe any 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. 'Add relations' signals a mutation, but the description does not state whether entities must already exist, whether the operation is reversible, whether duplicates are allowed, or what side effects occur. For a write operation with no annotations, this is a significant 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, focused sentence with no filler or repetition. It front-loads the key action ('Add relations') and immediately ties the tool to its candidate source. Every word contributes to the core meaning.

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

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

For a mutation tool with no annotations and no output schema, one short sentence leaves too much unspecified. The description does not cover the input structure, required fields, dataset parameter, or what the agent should expect after invocation. It is adequate only if the agent already knows the memify_candidates output format and the relation 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 0%, so the description must compensate, but it adds little parameter-level meaning. It clarifies that source and target are existing entities and that relations come from candidates, but it does not explain the required fields (source, name, target) or optional fields (evidence, description). The schema provides only names and defaults, not behavioral 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 uses a specific verb ('Add relations') and a clear resource ('existing entities'), and references memify_candidates as the source of proposals. This distinguishes it from memify_candidates, which proposes candidates, while cross_connect applies them. It could be slightly clearer about what 'relations' means, but the core purpose is understandable.

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 'proposed by memify_candidates(cross_connect)' implies that this tool should be used after memify_candidates has generated relation candidates. However, there is no explicit statement about when not to use it or what alternatives exist beyond the sibling list. The usage context is implied rather than 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?

No annotations are provided, so the description carries the full burden. It discloses the key behavioral contract: new assertions supersede older ones automatically, and nothing is deleted. It does not discuss dataset-scoping or failure modes, but the central side effect is clearly communicated.

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

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

Two sentences with no waste: the core subject is front-loaded, examples are provided, and the important supersede-and-not-delete behavior is included. 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 simple two-parameter declaration tool with no annotations and no output schema, the description covers the essential invocation semantics and the important behavioral consequence. The only notable gap is the undocumented dataset parameter, but an agent can still call the tool correctly for the primary use case.

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 enriches the 'names' parameter by defining what qualifies as a functional relation and giving examples, which the schema cannot convey. However, the 'dataset' parameter is entirely unexplained, and with 0% schema description coverage the tool does not fully compensate for both 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 uses a specific verb ('Declare') with a precise resource ('relation names that hold a single current value per subject') and concrete examples like current_owner and deployed_in. This clearly distinguishes it from assertion-level tools like remember or cross_connect and from other ontology tools like add_entity_type.

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 defines the target condition—relations where one current value per subject is desired—so an agent can recognize when this tool is appropriate. It does not name alternatives or state when not to use it, which keeps it just below the strongest 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 burden of behavioral disclosure. It indicates the tool is informational by listing output content categories, and it adds a session-ordering constraint. However, it does not disclose whether the tool has side effects, caches data, or how repeated calls behave. For a describe-type tool this is acceptable but not fully transparent.

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

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

The description is two short sentences with no filler. The output scope is front-loaded, and the important usage instruction about calling once per session before remember is included efficiently. Every word contributes value.

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

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

The description covers the high-level return content and the key usage instruction, but the dataset parameter remains ambiguous, and there is no explanation of default behavior. Since there is no output schema, the listed return categories help, but the description is not fully complete for correct invocation in all 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?

The schema has zero description coverage for the 'dataset' parameter, and the description only says 'for a dataset' without explaining valid values, whether null selects a default dataset, or how dataset names are specified. The description does not adequately compensate for the missing schema documentation.

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 lists what the tool provides: entity types, functional relations, imported ontologies, and store stats for a dataset. This clearly identifies the tool's purpose and content. It does not use an explicit verb like 'returns' or 'describes', but the intent is unambiguous and distinguishes it from sibling tools like recall or list_datasets.

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

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

The description gives a clear usage directive: 'Call once per session before remember.' This tells the agent when to invoke the tool relative to session flow. It does not explicitly mention alternatives or when not to use it, but the context is clear enough for a one-shot setup operation.

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 destructive scope by saying an entity is forgotten 'and its relations' and specifies exact-name matching. It also signals that the operation is sensitive by requiring user confirmation, though it stops short of explicitly stating permanence or irreversibility.

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 with no filler. The main action is front-loaded, and the alternative tool and user-confirmation requirement each 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?

Given five optional parameters, no annotations, and no output schema, the description is reasonably complete for the core action but leaves the 'dataset' parameter ambiguous. It also does not state what happens when multiple parameters are provided or what a successful 'forget' returns, so an agent may lack enough context to call it confidently in all 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 0%, so the description must compensate for the undocumented parameters. It explains entity, relation_id, session_id, and whole_dataset in natural language and adds exact-match semantics. However, the 'dataset' parameter is never explained, and the relationship between 'dataset' and 'whole_dataset' remains ambiguous.

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 ('Forget') with concrete targets: an entity by exact name, its relations, a relation by id, a session, or a whole dataset. It also differentiates from the sibling tool 'supersede' by saying to prefer supersede for facts that were once true, which prevents conflation with a similar memory-editing 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 tells the agent when not to use this tool ('Prefer supersede for facts that were true once'), naming the alternative. It also gives a clear prerequisite: 'Confirm with the user first.' This is sufficient usage guidance for a destructive memory operation.

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 full burden of disclosing behavior. It reveals the output shape (buckets per entity type, summaries, stale counts) but says nothing about whether the operation is read-only, what 'stale' means or how staleness is computed, or whether the index is live or cached. For an index tool, the definition of staleness is essential behavioral context and is missing.

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 20-word sentence with no filler and front-loads its defining term. It is efficient, though the brevity comes at the cost of substance. It earns a 4, not a 5, because it omits the two parameters despite having room to address them.

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 no annotations, no output schema, two undocumented parameters, and 23 siblings, the description leaves critical invocation details unresolved: what limit and dataset do, whether the call is safe/read-only, and whether the result contains stale items or only counts of them. The one-line overview is not enough for an agent to call this tool correctly without guessing.

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

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

Schema description coverage is 0% for both parameters, and the tool description mentions neither limit nor dataset. An agent cannot determine what limit caps (number of buckets? entries within a bucket?) or whether dataset filters the index or switches to a dataset-scoped view. With zero schema coverage and zero description compensation, the parameters are effectively undocumented.

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

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

The description names a specific resource (the global context index) and specifies its structure: one bucket per entity type, with a summary and a stale count. The 'global' scope helps distinguish it from session-scoped siblings like session_get and session_timeline. However, there is no explicit verb such as 'returns' or 'lists', and it never names a sibling it is not, so differentiation 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?

The description gives no guidance on when to use this tool versus its 23 siblings. It does not state whether to prefer it over recall, history, session_get, or describe_ontology for a given question, and it offers no exclusions or alternate routing. The usage context is only vaguely implied by the word 'global', which is insufficient.

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 discloses the key behavioral traits: the word 'ledger' positions this as a read-only view rather than a mutation, and the description states exactly what results contain (every create/merge/assert/supersede/forget event with actor and time). It does not disclose ordering, pagination semantics of the limit parameter, or what happens when no filters are supplied, so it is not fully transparent.

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

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

A single 23-word sentence with zero filler. The central concept ('provenance ledger') is front-loaded, followed by the scope ('entity and its relations or a relation') and the content details (event types, actor, time). Every clause earns its place and nothing needs to be cut.

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

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

Given no annotations, no output schema, and 0% parameter documentation, the description must compensate heavily; it successfully conveys the core purpose and what the returned events contain. But an agent cannot determine the meaning of the limit and dataset parameters, whether results are ordered, or the shape of an individual event record — gaps that matter because there is no output schema to fill them. Adequate for invoking with entity or relation_id, incomplete for full correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate for four undocumented parameters. It maps two of them — 'entity' and 'relation' clearly correspond to the entity and relation_id parameters. However, limit (pagination) and dataset (scoping) receive no explanation at all in either the schema or the description, leaving those invocations opaque. This is meaningful partial compensation but not sufficient for a 4.

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

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

The description identifies a specific resource (a provenance ledger scoped to an entity, its relations, or a single relation) and enumerates the exact events contained (create, merge, assert, supersede, forget) plus the captured fields (actor, time). This is much more specific than a bare 'history' and distinguishes the tool from session-oriented siblings like session_timeline. It stops short of 5 because it never explicitly names an alternative tool for contrast, relying on the reader to infer the distinction.

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

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

Usage is implied rather than stated: an agent can infer this tool is used to trace what happened to a specific entity or relation over time, since the scope targets knowledge-graph elements and the operation list covers mutations. There is no explicit when-to-use or when-not-to-use guidance, and no sibling tool (e.g., recall, session_timeline) is named as an alternative, leaving the agent to guess which history-like tool fits.

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

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

With no annotations, the description must carry the full behavioral burden. It does disclose the core transformation, such as parents collapsing onto basic types and labels becoming aliases, which is useful. However, it does not disclose side effects like whether the import overwrites existing entity types, whether the dataset parameter targets a specific dataset, or what happens on duplicate definitions.

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 no filler. The action is front-loaded, and the transformation rules are stated compactly. Every clause adds meaningful information.

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

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

For a mutation tool with four parameters, no output schema, and no annotations, this description is incomplete. It omits parameter semantics, return behavior, and state-change details. An agent would likely need additional probing or examples to call this correctly, especially regarding 'name' and 'dataset'.

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 by explaining parameters. It only references 'text' implicitly by saying the ontology is passed as text. It never explains 'name' (likely the imported ontology's name), 'format' (possibly the ontology serialization), or 'dataset' (where to import into), leaving the agent to guess.

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: 'Import an OWL/RDF/Turtle ontology (text).' It goes on to explain the transformation it performs (classes become entity types, parents collapse, labels become aliases), which clearly distinguishes it from sibling tools like describe_ontology or add_entity_type.

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 context of when to use this tool is implied: when you have an OWL/RDF/Turtle ontology in text form to bring in. However, there is no explicit guidance about when not to use it or what alternative to choose, such as add_entity_type for manually defining a single type or list_datasets for checking existing datasets.

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 burden of behavioral disclosure. 'List' implies a read-only operation and the description adds helpful scoping context (local machine, defaults), but it does not explicitly state that there are no side effects or describe what the returned list contains.

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

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

The description is a single front-loaded sentence with no filler or redundant phrasing. The semicolon clause is somewhat awkward but carries useful scope information.

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

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

For a zero-parameter list tool, the description is mostly sufficient, noting machine scope and defaults. However, with no output schema and no annotations, it does not explicitly explain the return shape or confirm that the operation is purely read-only.

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 nothing meaningful to add. The baseline of 4 applies since no parameter documentation is needed.

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

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

The description uses a specific verb ('List') and resource ('datasets (memory scopes)'), and clarifies scope with 'on this machine' plus the default project and user-global dataset. It is clear enough, though the post-semicolon clause is slightly ambiguous and does not explicitly distinguish it from sibling tools.

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

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

No guidance is provided about when to call this tool versus siblings like recall, global_context, or session tools. The usage context is only implied by the word 'List', not explicitly stated.

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

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

With no annotations provided, the description must carry the behavioral burden. It clearly states that the tool adds a contradicts edge, which is a mutating graph operation. However, it does not disclose side effects, whether existing facts are modified, how the edge affects recall or inference, or any permissions or reversibility concerns.

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 no filler. The primary action is front-loaded, and the alternative-tool guidance is placed in the second sentence where it is easy to scan.

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

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

With no annotations, no output schema, and 0% schema description coverage, the description is too brief to fully equip an agent. It leaves open questions about how subjects are resolved from relation IDs, what the tool returns, whether the edge is directed, and how confidence and dataset influence the 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 0%, so the description should compensate by explaining parameters. It implicitly maps first_relation_id and second_relation_id to the two stored facts, but it does not explain the role of reason, dataset, or confidence, nor how they affect the resulting edge. The parameter names are intuitive, but the description adds minimal semantic value beyond them.

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 object: 'Record that two stored facts cannot both be true' and 'Adds a contradicts edge between their subjects.' It clearly distinguishes this tool from supersede, making the tool's role unambiguous even without inspecting the 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 explicitly says to use supersede instead when the newer fact simply replaces the older one in time. This gives the agent a clear decision rule for choosing between two closely related sibling tools.

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

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

With no annotations, the description carries the full burden of disclosing whether this is a read-only listing and what the returned candidates look like. It only defines proposal kinds and does not state side effects, result format, pagination behavior, 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?

A single sentence presents the main category and then each proposal kind with a short parenthetical. There is no filler, redundancy, 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?

The core invocation requirement—selecting a valid 'kind'—is covered, so an agent can likely call the tool. However, the absence of an output schema and annotations means the description should at least indicate what the returned proposals contain or how to act on them, and it does not.

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 critical semantics for the required 'kind' parameter by listing valid values and their meanings, which is especially valuable because the schema has no enum or parameter descriptions. It does not mention 'limit' or 'dataset', but those are optional and reasonably inferable from their names and defaults.

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 the domain ('Maintenance proposals') and enumerates the three proposal kinds, enabling an agent to understand what resource this tool deals with. It lacks an explicit verb such as 'returns' or 'lists', so the action is partly inferred from the tool name rather than stated.

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

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

The parenthetical definitions provide implicit selection criteria: cross_connect for co-occurring entities without a relation, consolidate for near-duplicate names, and stale_summaries for buckets needing a summary. However, there is no explicit guidance about when to use this tool versus alternatives like contradiction_candidates or cross_connect.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly discloses that the operation is destructive to `drop` and that relations and chunks are moved to `keep`, plus that `drop` becomes an alias. This is strong transparency for a mutation tool, though reversibility and scoping behavior are not mentioned.

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

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

Two concise sentences convey the operation, the exact data movement, and the alias side effect with no filler. The most decision-relevant 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?

The description is largely self-contained for a moderately destructive merge operation: it explains what happens to both entities and to their relations/chunks. Missing details include dataset scoping and return behavior, but the core call semantics are sufficient for an agent to invoke the tool correctly in 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?

The description adds meaning for `keep` and `drop` by explaining how they affect data during the merge. However, schema description coverage is 0%, and the optional `dataset` parameter is not explained at all, so the description only partially compensates for the schema gap.

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

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

The description clearly states a specific action ('Merge two entities that denote the same thing') and describes the outcome. It distinguishes this tool from siblings like `forget` or `supersede` by focusing on entity identity resolution and alias recording.

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 'that denote the same thing' implies the primary use case: resolving duplicate entity representations. However, it provides no explicit comparison to related tools such as `supersede`, `cross_connect`, or `forget`, so an agent gets limited guidance about when not to choose this tool.

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

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

With no annotations, the description carries the full burden. It does disclose a meaningful side effect: it 'marks the session distilled,' and it states lessons are persisted and linked. However, it does not explain what 'distilled' means, whether the operation is idempotent, or what happens to previously persisted lessons.

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 communicates the core action, the entity relationship, and the session side effect with no filler or repetition. Every part of the sentence carries information.

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

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

The tool has three parameters, no annotations, and no output schema, yet the description omits how dataset and session_id are used, what 'accepted' means, and what the return/outcome is. It is too sparse to fully guide correct invocation.

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

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

Schema description coverage is 0% at the top level, so the description must compensate for dataset, lessons, and session_id. It only clarifies that lessons are 'accepted' and linked to 'what they apply to,' leaving dataset and session_id semantics entirely unexplained. The nested schema has some descriptions, but the tool description adds little 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 names a specific verb ('persist') with a specific resource ('accepted lessons as Lesson entities') and states the linking behavior and side effect. It clearly distinguishes this from sibling tools like remember or memify_candidates because it is about persisting lessons and distilling the session.

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

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

No guidance is given about when to call this tool versus alternatives such as remember or memify_candidates. The word 'accepted' implies a prerequisite workflow, but the description never states it or specifies conditions.

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

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

No annotations are present, so the description carries the full disclosure burden, and it does real work: it reveals search order (project dataset first, then user dataset), the presence of evidence/validity/superseded/contested flags on facts, and the explicit 'you synthesise' instruction that tells the agent not to expect a final answer. It also discloses automatic mode routing unless overridden. It stops short of documenting pagination, cost/latency, or how hops/limit shape results, but the disclosed traits are substantive and non-obvious.

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 capability, mode enumeration, search scope, and return contract are all packed in economically and front-loaded. Every sentence contributes distinct information, including the short 'you synthesise' tip that prevents a common misuse. The mode list is dense but earns its place because the schema defines no enums for `mode`.

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 7-parameter tool with no annotations and no output schema, the description covers routing, search scope, and return format well, which is the core of correct invocation. Missing semantics for `hops` and `limit`, and the lack of guidance on how `datasets` interacts with `include_user`, are real gaps an agent would hit when tuning retrieval. It is adequate for a first call but incomplete for sophisticated filtering.

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 fully documents `mode` by enumerating all seven values plus the default, and it illuminates dataset-scoping parameters (`include_user`, `datasets`) through the 'searches the project dataset then the user dataset' statement. The `query`, `hops`, and `limit` parameters receive no meaning beyond their schema names, which is a notable gap given zero schema descriptions. Overall it adds substantial value for the most complex parameter while leaving others unexplained.

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

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

The description names the verb ('Recall') and resource ('memory'), then specifies the routing modes (hybrid, facts, neighbourhood, lexical, summaries, temporal, rules, session), the search order (project then user dataset), and the return types (ranked raw entities, facts with evidence/validity/superseded/contested flags, chunks). The mode list and return-type disclosure clearly distinguish it from retrieval-adjacent siblings such as `history`, `global_context`, and `session_get`. The opening phrase is mildly tautological, but the following detail makes the purpose unmistakable.

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

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

The mode list implicitly signals when each behavior applies — e.g., 'lexical (quoted phrase)' tells the agent that quoted phrases select lexical matching — and the 'unless given' phrasing clarifies that mode is otherwise auto-routed with a stated default. However, there is no explicit when-to-use vs when-not-to-use guidance, no mention of alternatives like `history`, `session_get`, or `global_context`, and no exclusions. Usage context is implied rather than deliberately 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 full burden, and it excels: it discloses ontology validation, entity merging, supersession of functional relations, provenance recording, and contradiction-warning behavior. This is exactly the kind of side-effect transparency an agent needs before invoking a write-like memory 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?

Two dense sentences carry high information content without fluff. The core purpose is front-loaded, and every clause adds behavioral or input guidance that would not be obvious from the bare schema.

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

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

For a complex state-changing tool with no output schema and no annotations, the description covers the main behaviors and required inputs thoroughly. It lacks clarification of `dataset` and `session_id`, and does not describe the return value or failure behavior, but the agent can still call it correctly for typical memory-storage 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 0%, so the description must compensate. It explains the shape and meaning of entities, relations, source_text, and summary, and notes optional valid_from/valid_to. It does not mention `dataset` or `session_id`, which remain unexplained, but the most operationally important parameters are covered.

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: 'Store memory as a typed graph', then details the exact entities and relations being stored. This clearly distinguishes `remember` from sibling retrieval tools like `recall` and metadata tools like `list_datasets`.

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

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

It gives clear, actionable guidance: 'Pass source_text and a summary so recall can find it lexically,' which tells the agent what inputs are expected and why. It does not explicitly contrast with alternatives like `memify_candidates` or `supersede`, but the context makes the intended use obvious.

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. It clearly indicates a mutating operation ('append') and identifies the target as the session's fast cache, but it does not disclose side effects, persistence, whether the fast cache is the same as session history, or any capacity limits. This is a significant gap for a write operation with no annotation support.

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, dense sentence with no filler. The role list is efficiently packed into a parenthetical, and the resource and action are front-loaded. It is appropriately concise, though the brevity does contribute to incompleteness—a concern that belongs to contextual completeness rather than conciseness.

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

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

Given four parameters with zero schema descriptions, no annotations, and no output schema, the description is too terse to be fully actionable. It does not state whether the session must already exist, how the fast cache relates to the session's main history, or what the optional dataset parameter is for. An agent would have to guess at important context for a mutating session 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 0%, so the description must compensate for undocumented parameters. It does provide the allowed role values (user/assistant/tool/system), which aids the 'role' parameter, but it leaves 'session_id', 'text', and especially the optional 'dataset' unexplained. The description adds only partial parameter 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 identifies a clear verb (append), a specific resource (a turn to the session's fast cache), and enumerates the accepted role values. This differentiates it from reading tools like session_get or session_timeline and from session_set_context, which sets context rather than appending a turn. The jargon 'fast cache' introduces slight ambiguity, preventing a perfect 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?

No guidance is provided on when to use this tool versus siblings such as session_start, session_set_context, or remember. There is no mention of prerequisites like an already-started session, nor any exclusions or alternative conditions. Usage context must be inferred entirely from the action verb.

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 does disclose a useful behavioral trait: the tool returns whether the session still needs distillation. However, it does not explain side effects, whether closing is reversible, or what happens if the session does not exist or is already closed.

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 short sentences with no filler. It front-loads the core action and adds a concise statement about the tool's output, making it efficient and easy to parse.

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

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

Despite the tool's low structural complexity, the description is incomplete: it omits parameter semantics, usage context, side effects, and any explanation of what 'needs distillation' means. Without annotations or an output schema, an agent has too little context to confidently decide when and how to use this tool.

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

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

Schema description coverage is 0%, and the description adds no meaning for either parameter. It does not mention that session_id is required, nor explain the optional dataset field. The agent must rely entirely on the raw schema, which offers no semantic detail beyond 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 clearly states the action ('Close a session') and resource ('session'), and adds a specific outcome ('Tells you whether it still needs distillation'). It is distinct from siblings like session_start and session_get, though it does not explicitly name or contrast them.

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

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

There is no guidance on when to use this tool versus alternatives such as session_get, session_timeline, or session_add_turn. The phrase 'Close a session' implies it should be used at the end of a session, but no explicit when-to-use or when-not-to-use instructions 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 provided, the description must carry the behavioral disclosure burden. It does convey that the operation is a read and that results are optionally filtered by section. However, it does not mention default behavior like include_turns=true, dataset scoping, or any quirks of the returned data.

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 states the operation, the content, and the main optional modifier efficiently.

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 four parameters, no output schema, and no annotations, this description is under-specified. It omits dataset semantics, the role of include_turns, section value expectations, and any differentiation from similar siblings. An agent would need to inspect or guess to call it with confidence.

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 all four parameters. It only adds meaning for 'sections' ('filtered by section') and vaguely implies 'include_turns' through 'turns and context entries'. The 'dataset' parameter is entirely unexplained, and the include_turns default is not surfaced.

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'), names a concrete resource ('a session'), and identifies the payload ('turns and context entries'). It is clear, though it does not explicitly differentiate itself from sibling read tools like session_timeline, recall, or history.

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 'Read a session' implies its purpose and provides basic context for when to call it. However, it gives no guidance about when to prefer this tool over the many read-adjacent siblings, 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?

Because no annotations are provided, the description carries the full behavioral disclosure burden. It does disclose useful behavior: feedback '+Name'/'-Name' adjusts recall weight, and retire_entry_id replaces an outdated entry. However, it does not explain side effects such as whether entries are appended or deduplicated, how confidence is used, or what happens to the session context after writes.

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 dense sentence that front-loads the purpose and packs in section categories plus the recall-weight behavior without wasted words. It is concise, though the long list and parenthetical make it slightly harder to skim.

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

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

There is no output schema, so the description should explain return behavior or at least confirm side effects. With six parameters and many sibling tools, the description leaves ambiguity around session_id semantics, dataset/confidence usage, and the full consequences of retiring entries or using +/- feedback.

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 six undocumented parameters. It adds meaning only for retire_entry_id and the feedback content convention, while session_id, section, content, dataset, and confidence remain essentially explained only by their parameter 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: 'Record a session context entry,' and enumerates valid section names like goals, rules, preferences, lessons_learned, and feedback. It is clearly distinct from read-oriented siblings like recall or session_get, though it does not explicitly name an alternative for direct write comparisons.

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

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

There is no explicit guidance about when to use this tool versus alternatives such as remember, session_add_turn, session_get, or recall. The description implies it is for writing context entries, but it does not state when it should be preferred over other session or memory tools.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does disclose that the tool starts or resumes a session and returns standing context, which is useful. But it does not mention side effects, persistence behavior, authentication requirements, or how dataset/session_id affect the operation.

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

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

The description is two short sentences with no filler. The primary action is front-loaded, and the return-value note is concise and informative.

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 purpose is clear, but the description is incomplete for a tool with no annotations and no output schema. The missing explanation of dataset and session_id leaves a significant gap for correct invocation, especially for the 'resume' case. There is also no mention of what happens if no arguments are provided.

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

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

Schema description coverage is 0% and the description never mentions the two parameters, dataset and session_id. An agent cannot tell what these parameters mean, how they relate to starting versus resuming, or whether they are scoping or identification values. The description adds no parameter-level guidance.

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

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

The description clearly states a specific verb and resource: "Start (or resume) a session," and adds value by noting it returns standing context (goals, rules, preferences, lessons). It distinguishes itself from most siblings by focusing on session lifecycle initiation rather than retrieval or mutation, but it does not explicitly name or contrast any sibling tool.

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

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

The phrase "to load before work" gives a clear usage context: this is the tool to call at the beginning of a work session or when resuming one. However, it does not explicitly state when not to use it or point to alternatives like session_get or session_timeline.

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. It signals a consequential action by mentioning 'call publish_lessons,' but it is ambiguous whether the tool performs this automatically or instructs the agent to do it afterward. It also omits side effects, repeatability, and how session state is affected.

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

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

The description is a single compact sentence with no filler and front-loads the main action. It loses a point because compressed workflow terms like 'judge' create ambiguity rather than a crisp one-sentence contract.

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

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

For a tool with no annotations, no output schema, and three undocumented parameters, this is under-specified. It does not clarify what the tool returns, whether publish_lessons is automatic or a required follow-up, or what the batch_chars threshold controls.

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

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

Schema description coverage is 0%, and the description does not explain session_id, dataset, or batch_chars. 'Batches' only loosely relates to batch_chars and provides no format, defaults, or guidance on how these parameters control 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 names a specific resource ('a session') and actions ('pack into batches for distillation') rather than restating the tool name. It loses a point because 'judge' is vague and the relationship to publish_lessons is not fully precise.

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 'for distillation' gives an implied use case, and the mention of publish_lessons situates it in a workflow. However, it does not state when to prefer session_timeline over sibling session tools, what preconditions are required, 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?

There are no annotations, so the description must carry the behavioral disclosure burden. 'Write' signals a mutation, but the description does not say whether the summary is overwritten, whether the bucket must already exist, what happens on invalid bucket IDs, or whether the operation is idempotent. This leaves the agent without important safety and effect 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?

The description is a single, front-loaded sentence with no filler or redundant wording. Every phrase earns its place by identifying the action, the object, and the source of the bucket.

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

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

Given no annotations, no output schema, and zero parameter documentation, this one-line description leaves significant gaps: the agent still needs to know how to pass dataset, what a successful response looks like, and what side effects occur. The memify_candidates reference provides useful workflow context but does not make the tool definition complete enough for reliable invocation.

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

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

Schema description coverage is 0%, and the description adds only minimal parameter meaning: 'summary' is the text to write and 'bucket' refers to the bucket identifier. It does not explain the optional 'dataset' parameter, the format or constraints for 'summary', or the relationship between 'bucket_id' and the candidate-generation step beyond the general phrase.

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 ('Write the summary') and a specific resource ('a global-context bucket'), then ties that resource to a concrete provenance: 'returned by memify_candidates(stale_summaries)'. This clearly distinguishes the tool from its sibling read/generation tools and tells an agent exactly what operation it performs.

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 correct usage context: this tool is the write step following memify_candidates(stale_summaries), for buckets produced by that function. It does not explicitly state when not to use it or list alternatives, but the workflow reference is clear enough to route an agent correctly.

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 must convey side effects, and it does: the old fact remains in history but is excluded from default recall. It does not discuss reversibility, permissions, validation, or effects on the new relation, but the key behavioral outcome is disclosed.

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

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

The description is two short sentences with no wasted words. It front-loads the primary action and immediately gives the most important behavioral consequence.

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?

It captures the core purpose and a key side effect, but it omits explanation of all four parameters, return behavior, and potential error conditions. Given no annotations and no output schema, the message could be more complete without becoming verbose.

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, so the description must compensate. It implicitly maps 'older fact' to old_relation_id and 'newer one' to new_relation_id, but it does not explain the required 'reason' parameter or the optional 'dataset' parameter beyond what their titles alone convey.

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 ('Mark an older fact as superseded by a newer one') with a clear resource, and adds meaningful result information ('old fact stays in history and leaves default recall'). It distinguishes itself from siblings like forget or mark_contradiction by describing the supersession semantics.

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 intended scenario: use when there is an older relation and a newer relation that should supersede it. However, it does not explicitly state when not to use this tool or name alternative tools such as mark_contradiction or forget.

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