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 only explains the conceptual purpose, not behavioral traits such as whether adding is idempotent, what happens if the concept_id already exists, or any side effects.

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

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

The description is a single concise sentence that front-loads the action and resource, with no redundant 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 description provides basic context about concepts and their role in the knowledge graph, but it lacks guidance on how this tool fits with the many sibling tools, and no output schema exists to clarify return values or additional behavior.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional parameter semantics beyond the schema, which is the baseline expectation.

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) and the resource (a concept to the knowledge graph), and distinguishes it from sibling tools like memory_add_connection and memory_add_observation by emphasizing that concepts represent domain knowledge.

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

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

The description implies usage by defining what concepts are, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only says 'add a relationship' and lists relationship types, without addressing side effects, prerequisites (e.g., whether concepts must already exist), idempotency, or what happens on duplicate relationships. For a mutation tool, 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 concise, with a single sentence stating the action followed by a list of valid relationships. The list is necessary and front-loaded after the verb. No wasted words, though the list is lengthy but functionally relevant.

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

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

With no output schema and no annotations, the description should provide more context about return values, error cases, or the directed nature of relationships. It lacks information about cluster_id usage and whether relationships are directed from source to target. The description is minimal for a 4-parameter mutation 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 100%, and the schema already documents each parameter. The description only repeats the relationship enum values without adding new meaning (e.g., directionality semantics or how cluster_id is used). Baseline 3 is appropriate since the schema handles the heavy lifting.

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

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

The description clearly states the tool's function: 'Add a relationship between two concepts.' It also enumerates all valid relationship types, making the operation explicit and distinguishing it from sibling tools like memory_add_concept and memory_add_observation.

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 makes clear that this tool is for creating relationships between concepts, and the sibling context shows distinct purposes for other add-tools. However, it does not explicitly state when not to use it or mention alternatives, so it lacks explicit exclusion guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool persists information across sessions, which is useful, but it doesn't mention potential duplicates, idempotency, automatic session association, or return behavior. This is adequate but not rich.

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

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

Two short sentences with a clear verb-first structure. Every sentence contributes purpose and usage context without unnecessary detail or repetition.

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

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

Given the tool's moderate complexity (5 params, 3 required, enums), the description covers the core purpose and usage. The lack of an output schema is acceptable for a write operation, and the description adequately explains the main intent. Minor gaps remain around behavior on duplicate entries or exact session attribution semantics, but these are not critical.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces some enum values (e.g., discoveries, gotchas, decisions) but adds no additional meaning beyond what the input schema already provides. It doesn't compensate with extra context for parameters like effectiveness or concepts.

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 ('Record') and resource ('observation'), and clarifies the scope ('from the current session'). It distinguishes this from sibling tools like memory_add_concept and memory_add_connection by focusing on observations and listing concrete examples (discoveries, gotchas, decisions, trade-offs).

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 states when to use the tool ('Use this to capture discoveries, gotchas, decisions, trade-offs, or problem-solutions that should be remembered across sessions'), providing clear context. It doesn't name sibling alternatives or exclusions, so it doesn't reach a 5, but the guidance is unambiguous.

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

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

With no annotations, the description carries the burden. It discloses the BFS traversal and relationship-agnostic behavior, but does not mention side effects, return format, or limits like cycle handling or max_hops semantics. The read-only nature is implied by 'Find' but not elaborated.

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

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

Two short, front-loaded sentences with no fluff. The second sentence adds detail about relationship-agnostic traversal, though it partially repeats 'find concepts.' Still 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?

The tool is a graph traversal with no output schema or annotations. The description explains the purpose and scope but omits what the return value looks like (e.g., list of concept IDs), whether max_hops is inclusive, or how cycles are handled. Adequate for a simple read tool, but with 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 coverage is 100% (both parameters described), so the baseline is 3. The description does not add parameter-specific details; it only clarifies the overall operation. No further compensation 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 clearly states the tool finds conceptually related concepts via graph traversal (BFS), specifying the method and the resource. It distinguishes itself from siblings like memory_get_concept (single concept) and memory_find_solutions (solution-oriented search).

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

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

The description gives clear context: use when you need concepts connected by any relationship type. It does not explicitly name alternatives or exclusion criteria, but the traversal-based method is specific enough to imply appropriate use cases.

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 explicitly states the traversal relationships, giving insight into how the tool operates. It doesn't mention read-only nature or return format, but the 'find' verb implies a non-mutating query, and the relationship list adds transparency.

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

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

The description is a single sentence, front-loaded with the purpose ('Find concepts that solve a problem') and then specifying the relationships. No wasted words; concise and clear.

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 one parameter and no output schema, so the description should ideally specify what is returned (e.g., a list of concept IDs) to be fully complete. It doesn't, leaving a minor gap for agents needing to know the return format. However, the core behavior is covered.

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

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

The input schema already describes 'problem' as 'Problem concept ID to find solutions for', so the description doesn't add parameter-specific meaning beyond reinforcing the tool's purpose. Schema coverage is 100%, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool finds concepts that solve a problem, with specific relationship types ('resolved_by', 'prevents', 'mitigates', 'enables'). This distinguishes it from siblings like memory_find_related, which is generic relation finding.

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

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

The description gives clear context: use when you need to find solutions by traversing those specific relationships. It doesn't explicitly say when not to use it or mention alternatives, but the relationship types imply a focused use case.

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. 'Retrieve' implies a read-only operation, which is transparent enough for a simple getter. However, it does not disclose what is returned (e.g., the full concept object) or behavior on missing IDs, which is a minor 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, concise sentence that clearly states the tool's purpose. Every word earns its place with no redundancy or filler.

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

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

For a simple one-parameter retrieval tool with no output schema, the description is adequate: it explains what the tool does and implies the return value (the concept). It could be more explicit about the return format, but it is not incomplete for basic use.

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

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

Schema description coverage is 100% for concept_id, so the schema fully documents the parameter. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Retrieve') and resource ('specific concept from the knowledge graph'), clearly distinguishing it from siblings like memory_find_related or memory_get_observation. However, it could more explicitly mention identification via concept_id, though the schema already covers that.

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 usage when you need a specific concept, but it does not explicitly state when to choose this over memory_get_observation or memory_find_related, nor does it mention any prerequisites. It provides implied usage but no explicit guidance or alternatives.

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

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

No annotations provided, so description carries the burden. It explains the progressive disclosure behavior, what the output contains (existence and cost), and what it excludes (full details). Doesn't mention ordering or pagination, but adequate for a read-only index 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 concise sentences: first states action and resource, second adds context on what is shown. No filler, 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?

Adequate for a simple tool with one parameter and no output schema. Explains purpose and high-level output, but lacks detail on the index format (e.g., fields returned). Could be slightly more complete.

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

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

Schema coverage is 100% with a clear description for 'limit'. The description's 'all recent observations' could imply no limit, but doesn't add significant parameter semantics beyond the schema.

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

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

Description uses specific verb 'Get' with clear resource 'progressive disclosure index' of recent observations. It distinguishes from sibling tools by explaining that it shows existence and retrieval cost without full details.

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?

Implies use for overview and cost estimation before retrieving full details, and 'without full details' suggests using another tool for full content. However, it doesn't explicitly name alternatives or 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?

With no annotations provided, the description is the sole source of behavioral disclosure. 'Get' implies a read-only operation, and the description outlines what the index shows, but it does not add details like return format, error conditions, or performance characteristics. This is minimally acceptable for a simple read tool.

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

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

The description is a single, direct sentence that conveys the purpose without redundancy. It is appropriately front-loaded and contains no filler.

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

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

The description adequately explains the content returned (key insights, problem-solution mappings, knowledge domains) for a simple parameter-less read. However, the close sibling 'memory_get_index' creates potential ambiguity, and the description does not explicitly differentiate itself from that tool.

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

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

The input schema has zero parameters, so the baseline of 4 applies. The description adds no parameter-specific meaning because there are no parameters to document.

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 verb 'Get' and the specific resource 'knowledge graph index', enumerating its contents (key insights, problem-solution mappings, knowledge domains). This distinguishes it from the sibling 'memory_get_index' by focusing on the knowledge graph aspect.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'memory_get_index' or other memory tools. It does not mention any contextual cues or exclusions.

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

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

No annotations are provided, so the description carries the burden. 'Retrieve' implies a read-only operation, but it does not explicitly state that there are no side effects, what happens if the ID is not found, or any auth requirements. The verb is suggestive but lacks explicit disclosure.

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

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

Two concise sentences front-load the purpose and then provide a usage hint. Every word earns its place; there is no fluff or repetition.

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

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

For a simple single-parameter retrieval tool with no output schema, the description covers the core purpose and usage context. It does not detail return behavior or error cases, but these are not essential for a straightforward get-by-ID operation.

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

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

The schema already covers the parameter fully with 'Observation ID from the index.' The description adds contextual usage guidance but does not introduce new parameter semantics. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description clearly states the action ('Retrieve a specific observation by ID') and distinguishes it from sibling tools like memory_get_concept and memory_search_observations. The added phrase 'by ID' specifies the exact resource and selection mechanism.

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

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

It explicitly says when to use the tool: 'after seeing an observation in the index that looks relevant.' This provides clear context and implies that searching/finding should happen first. It does not name alternative tools, but the guidance is sufficient for a simple lookup.

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

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It only says 'Get observations' and provides no details about ordering, inclusion of anchor, defaults behavior, or edge cases, which is minimal.

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 wasted words. The first sentence states the action and scope, the second provides a use case, so 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 simple read tool with only three parameters and no output schema, the description is adequate but sparse. It covers the primary purpose and general use case, but lacks details on return format or edge cases. Given the simplicity, it is minimally complete.

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

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

Schema documentation covers 100% of parameters, so the description adds little. It does imply the anchor is the center and before/after are counts, but this is already apparent from the schema. Baseline of 3 is appropriate.

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

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

The description clearly states the tool retrieves observations around a specific point in time, which distinguishes it from getting a single observation or searching. However, it does not explicitly name sibling alternatives, so it lacks a small degree of differentiation.

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

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

It mentions the tool is useful for understanding context of an observation, giving a usage context. But it does not explicitly state when to use this over other memory tools, nor does it provide exclusions or alternative tool names.

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

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

No annotations are provided, so the description carries full responsibility. It discloses a sorting behavior ('sorted by recency') and implies a read-only operation through 'Returns', but it omits details like matching semantics (exact vs. fuzzy), case sensitivity, pagination behavior, or any potential side effects. The description is minimally transparent but not rich.

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, front-loaded with the core action, and contains zero filler. Every word contributes meaning, making it highly 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 simplicity, the schema fully documents parameters, and the description covers purpose and sorting. While no output schema exists, the description sufficiently indicates what is returned (matching observations). It does not describe the observation structure, but that is likely known from context. Overall, it is complete enough for a straightforward search tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema: 'keyword match' echoes the query description, and the limit parameter is not mentioned. No additional value is provided, so the score remains at the baseline.

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

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

The description clearly states the action ('Search observations by keyword') and the resource ('observations'), which distinguishes it from sibling tools like memory_get_observation (which likely retrieves a single observation by ID). It also adds a specific behavioral detail (sorted by recency), making the purpose unambiguous.

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

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

The description implies usage for keyword-based searching but does not explicitly mention alternatives or when not to use this tool. Sibling tools like memory_get_observation or memory_find_related suggest potential overlap, but no exclusionary guidance is provided. This is a clear context but lacks explicit when/when-not guidance.

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