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

No annotations, so the description carries the full burden. It usefully discloses a side effect: providing source_id marks the source chunk as processed. However it says nothing about permissions, whether existing memories are overwritten, deduplication, or mutation scope for the remaining parameters.

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

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

Four sentences, front-loaded with the core action and the format requirement. Mostly every sentence earns its place, though the keyword/technology-name guidance is somewhat list-like and could be tightened.

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

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

For an 8-parameter mutation tool with 0% schema coverage and no annotations, the description is thin: it explains summary content and one side effect but leaves most parameters and the overall mutation model unexplained. An output schema exists, so return values need not be covered, but the input contract is largely unaddressed.

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

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

Schema description coverage is 0% across 8 parameters, so the description must compensate, but it only addresses summary (format guidance) and source_id (processed-marking side effect). The six other parameters (outcome, project, artifact_ptr, context_tags, project_path, artifact_type) get no explanation at all.

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

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

States a specific verb+resource ("Store a new memory") and clarifies the two sources it can come from (reading a source or the current conversation). An agent can distinguish it from the read-oriented siblings (recall, search, fetch_source), though it doesn't name them explicitly.

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

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

Implies usage context (after crafting a memory from a source or conversation), which frames when to call it, but never states when NOT to use it or how it differs from sibling write paths like split_source. The condition for providing source_id is given, which is helpful, but overall usage guidance is only implied.

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 disclosure burden. It reveals useful behavior — that the returned text is the raw chunk from the file at the registered line range and that the intended follow-up is create_memory — but it says nothing about permissions, whether fetching is side-effect free, or handling of invalid source IDs.

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

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

Three short sentences that are front-loaded with the core action, followed by the return payload and the next-step directive. No filler, though the workflow sentence is somewhat tangential to defining the tool itself.

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

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

An output schema exists, so return values needn't be spelled out, yet the description still characterizes the content helpfully. For a one-parameter read tool with no annotations, the description covers what it does, what comes back, and the intended follow-up, leaving only minor gaps in IDs/permissions.

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

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

Schema description coverage is 0% for the single required parameter, so the description must compensate. It only implies that source_id identifies a 'source chunk' and mentions the 'registered line range', adding modest meaning without explaining ID format or how a chunk ID is obtained.

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

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

States a specific verb and resource: 'Read the raw text of a source chunk by its ID', and clarifies the return is actual conversation or plan text from a registered line range. It is clear what the tool does, though it never names the siblings (recall/search) it might be confused with.

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

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

Usage is only implied through the pipeline hint: read the content, then call anamnesis_create_memory to store a summary. There is no explicit statement of when to choose this over anamnesis_recall or anamnesis_search, so routing is left to inference.

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

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

With no annotations, the description must carry the behavioral burden. It does disclose the operation's nature (read-only, lightweight, 'quick') and its return content, but since an output schema already exists, the return description adds limited value; there is no explicit statement about side effects, auth, or rate limits, though a ping implies none.

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

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

Two tight sentences, front-loaded with the purpose and followed by the routing guidance. No filler or repetition.

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

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

For a zero-argument health check with an output schema present, the description covers everything an agent needs: what it does, what it returns, and when to call it.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless tool.

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

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

States a specific verb and resource ('health check') and enumerates exactly what it returns: server status and embedding-model load state. An agent can distinguish it from anamnesis_recall/search/fetch_source purely from the description.

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

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

Gives an explicit condition ('before calling heavier tools') and names the sibling that condition applies to (anamnesis_recall). This is exactly the when-to-use routing guidance an agent needs.

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 supplied, so the description carries the full behavioral burden. It implies a read-only recall operation and supplies usage context, but never explicitly confirms no side effects, nor does it explain ranking, scoping, or result-volume behavior.

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

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

Three sentences, front-loaded with purpose, then triggers, then the call pattern. Each sentence carries distinct information and nothing is padding.

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

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

The output schema exists, so return values need not be described. Still, for a four-parameter tool with no annotations and no schema descriptions, the definition leaves the numeric parameters and the overlap with anamnesis_search unexplained.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, yet it only explains cue (natural-language query). top_k, project, and threshold — including what a 0.3 threshold means or how project scopes results — are left entirely undocumented.

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

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

States a specific verb (search) plus resource (long-term memory) and mechanism (semantic similarity), which is more than a restatement of the name. However, it never distinguishes itself from the sibling anamnesis_search, leaving the agent to guess which search flavor applies.

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

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

Gives three concrete trigger conditions — start of a non-trivial problem, context feels familiar, user asks what you remember — which is unusually actionable. It omits when NOT to use it and never names anamnesis_search as the alternative for keyword/other lookups.

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

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

No annotations are provided, so the description carries the full disclosure burden. It reveals the return fields (paths, types, projects, line counts), the paginated nature, and the offset continuation pattern, but says nothing about permissions/auth needs, rate limits, or whether the scan has any side effects on the filesystem.

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

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

Three short sentences with no filler: what it discovers, what it returns, and how to page. The scope constraint and first-step guidance are front-loaded.

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

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

For a read-only scan with an output schema present, the description covers purpose, pagination, and workflow position adequately. Minor gaps remain around read-only safety guarantees and the handoff to fetch_source, but nothing needed to invoke it correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It explains the offset continuation pattern ('Call again with offset to get more'), which gives real semantics for `offset`, but `limit` is never mentioned and its default of 20 is left to the schema.

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

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

States a specific verb ('Discover') on a specific resource ('Claude session and plan files that have not yet been imported into Anamnesis'), with a scope filter (not-yet-imported) that separates it from sibling tools like anamnesis_fetch_source and anamnesis_split_source. An agent knows exactly what this returns without opening 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?

Explicitly positions the tool as 'the first step when importing the user's conversation history into memory' and explains the pagination follow-up ('Call again with offset to get more'). It gives clear usage context but does not name the downstream alternative (e.g. fetch_source) or state 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions filtering capabilities, which is useful, but doesn't describe whether this is a read-only operation, how results are ordered, pagination behavior, or any rate limits. For a search tool, basic behavioral traits are 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?

Three succinct sentences with no filler. The purpose is front-loaded, the efficiency comparison follows, and filtering details close. Efficient and well-structured.

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

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

An output schema exists, so returning values needn't be described. However, with 4 parameters at 0% schema coverage, the description only partially documents the interface. For a search tool with no annotations, more behavioral context (e.g., result ordering, empty query handling) would improve completeness.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'filtering by tags and project' but doesn't explain the 'limit' parameter, the 'query' behavior (e.g., whether empty query returns all), or how tags are combined (AND/OR). Only 2 of 4 parameters get any semantic detail.

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

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

States a specific verb+resource ('Keyword and tag search across memories') and distinguishes from the sibling recall tool by noting it's 'Faster than recall when you know specific terms to search for.' This gives a clear functional boundary, though it could be more explicit about the exact difference from recall.

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

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

Provides a clear when-to-use condition ('when you know specific terms to search for') that contrasts with recall. It doesn't state when not to use it, but the comparative framing gives good context.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that each chunk becomes a source record that can be fetched and processed into a memory, and that it must follow scan_sources. However, it does not cover permissions, idempotency, duplicate handling, error behavior, or other side effects an agent would want for a write operation.

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

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

Three sentences, each earning its place: the first states the action, the second gives the workflow context, and the third explains the outcome. The purpose is front-loaded and there is no filler.

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

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

An output schema exists, so return values need not be described. But for a tool with four required, undocumented parameters and no annotations, the description omits critical operational details: expected parameter formats, chunk object structure, and file_type/project semantics. An agent could not invoke this reliably without inspecting the schema and 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 all four required parameters. The description hints that chunks are split by line range, but it never explains the format of chunks, the meaning of file_path, file_type, or project, or expected values. It adds minimal semantic value over an entirely undocumented schema.

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

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

The description states a specific verb ('Register') and resource ('source file'), plus the key mechanism ('split into chunks by line range'). It also distinguishes this from the sibling scan tool by naming anamnesis_scan_sources as the prerequisite, so an agent can tell what this tool does versus alternatives.

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

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

It gives explicit timing and context: 'Call this after anamnesis_scan_sources to break a large file into manageable pieces for reading and memory creation.' This tells the agent when to use it and what workflow it belongs to, though it does not state when not to use it or name other alternatives beyond the prerequisite.

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