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

With no annotations, the description carries the full burden for behavioral disclosure. It states 'Auto-capture' which implies persistence, and it requires source_app and capture_context fields, but it does not disclose side effects such as whether a memory ID is returned, how duplicates are handled, whether anything is overwritten, or any authentication/rate-limit considerations.

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

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

The description is dense but efficient, packing the core purpose, content-type guidance, importance rules, and field requirements into three sentences. It is front-loaded with the main action. It could be improved with structured bullets or clearer separation of topics, but it remains appropriately concise for a 10-parameter tool.

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

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

The description covers many use cases but leaves gaps for the enum values bookmark, conversation, todo, and reference, and does not address the low and critical importance values. It also references a non-existent capture_context.agent_id field and does not explain return values, making it incomplete for an agent attempting to use the tool confidently on less-common content types.

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 fully documents all parameters, so the baseline is 3. The description adds useful mapping for content_type and importance, but it also instructs 'capture_context.agent_id' even though the schema for capture_context contains only file, branch, project, and technology. This makes the parameter guidance partially misleading and prevents a higher score.

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

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

The description opens with a specific verb and resource: 'Auto-capture structured memory.' It then enumerates concrete content types (decision, error, insight, snippet, research) with their corresponding content_type values, making it easy for an agent to understand exactly what this tool ingests and how it differs from retrieval-focused siblings like recall, timeline, and thread.

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

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

The description gives explicit when-to-use guidance by mapping use cases to content_type values and importance levels. It lacks when-not-to-use instructions and does not mention alternatives like raggy_remember or raggy_recall, so it misses the full 'do not use' side of usage 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 full behavioral burden and delivers substantial context: one-shot invocation policy, first-action ordering, empty-result semantics, and a fallback path to raggy_recall. However, it does not disclose whether loading memories has side effects on stored state, nor what the response format contains beyond being possibly empty.

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 and roughly 50 words, with the most critical instruction ('MANDATORY FIRST ACTION of every session') front-loaded. Every sentence earns its place: when to call, what query to use, and when to fall back to raggy_recall — zero 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 call pattern is fully specified, which is the most important information for a mandatory session-start tool. However, with no output schema, the return-value contract is vague — it only implies results can be empty — and it does not explain how the agent should consume the loaded memories or what to do if the call fails.

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%, setting a baseline of 3, but the description adds genuine parameter-level guidance: 'with their initial request as the query' tells the agent exactly what value to pass into the query parameter for the primary call. This operational instruction goes beyond the schema's generic 'Additional context query' text.

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 with a clear verb and resource: 'Loads relevant memories from prior sessions.' It distinguishes itself from siblings by explicitly naming raggy_recall as the targeted-lookup alternative, and the 'MANDATORY FIRST ACTION of every session' framing positions it uniquely among the raggy_* family.

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

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

Usage guidance is explicit and complete: 'MANDATORY FIRST ACTION of every session. Call ONCE before answering the first user message with their initial request as the query' tells the agent exactly when and how to invoke it. It also provides an exclusion rule ('Do not make a second call unless this returned empty') and names the alternative tool (raggy_recall) for the fallback 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose that the operation requires an API key and that it deletes a private knowledge base source. However, it does not explicitly state that deletion is permanent or irreversible, nor what the response looks like on success or failure. For a delete tool this is a moderate, not severe, 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 three sentences with no filler. The core action is front-loaded, followed by usage conditions, the alternative, ID acquisition guidance, and the auth requirement. 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 single-parameter deletion tool with no output schema, the description covers the core call scenario, the alternative tool, the ID source, and authentication. The only notable omission is explicit disclosure of side effects or irreversibility, which keeps it from being fully complete.

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

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

The schema already fully documents sourceId, so the baseline is 3. The description adds meaningful value beyond the schema by explaining that the ID identifies an uploaded private knowledge base source and by pointing to raggy_private_sources as the way to retrieve it. This helps an agent understand where the parameter value comes from.

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: 'Delete an uploaded private knowledge base source by ID.' It clearly distinguishes itself from raggy_forget, which handles individual memories instead. An agent can immediately understand both what the tool does and what it does not do.

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?

Explicit usage guidance is provided: 'Use when the user asks to remove a specific source.' It also names the alternative tool for related but different cases ('For individual memories use raggy_forget instead') and tells the agent how to obtain the required ID via raggy_private_sources. This is model 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 for destructive behavior. It explains that delete removes entirely and redact preserves the graph node while stripping content, which goes beyond the schema wording. It does not mention reversibility or permission requirements, but the main side-effect profile is clear.

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

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

Two sentences front-load the trigger conditions and mode choices, then add the sibling exclusion. Every sentence contributes value and there is no filler.

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

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

For a simple two-parameter tool with no output schema, the description fully supports correct selection and invocation: when to call, which mode to pick, and which sibling to use for uploaded sources.

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 memory_id and mode. The description re-explains mode semantics ('delete removes entirely' vs 'redact preserves graph node') but adds no new parameter-level syntax or constraints.

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

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

The description names the exact trigger phrases ('forget that', 'don't save that', 'delete that memory') and the resource (memories), so the tool's purpose is unambiguous. It also disambiguates from raggy_delete_source by saying uploaded sources are out of scope.

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 opens with explicit invocation instructions ('Call immediately when...') and then gives the mode choice. It closes with a clear exclusion: uploaded sources should go to raggy_delete_source instead.

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

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

No annotations are present, so the description carries the burden of behavioral disclosure. It communicates the core behavior—creating a relationship in the knowledge graph—and the relationship semantics. However, it does not disclose side effects such as whether an existing relationship is replaced, whether duplicate links are allowed, or what the operation returns.

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

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

The description is compact and front-loaded with the primary action and usage guidance. The list of relationship types partly duplicates the schema enum, but it is still helpful for quick understanding and does not make the description bloated.

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 all parameters are documented in the schema and the description provides clear purpose and usage triggers, an agent can select and invoke this tool correctly. The main gaps are the lack of output/return behavior and edge-mutation semantics, but these are minor for a relatively simple graph-link 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 input schema already describes all four parameters with 100% coverage and defines the relationship_type enum. The description adds useful context by mapping scenarios to relationship types, but it does not add significant meaning beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb and resource: 'Connect two related memories in the knowledge graph.' It lists eight concrete relationship types, making the tool's purpose unmistakable and clearly distinct from sibling tools like raggy_remember or raggy_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?

The description explicitly states when to use the tool with concrete scenarios: 'Use when a new memory supersedes/refines/contradicts an old one, or when an error resolves a past bug.' It does not name alternatives or explicitly state when not to use it, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses that the operation lists private sources and requires an API key, both useful security/privacy context. However, it does not describe whether the list is paginated, whether it returns only metadata or full content, or what happens with no sources. This is adequate but has gaps.

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

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

The description is compact and front-loads the core purpose. Both sentences earn their place: one for the function and scope, one for usage context and authentication requirement. It could have been even tighter, but it is not bloated.

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

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

Given the tool has zero parameters and no output schema, the description provides enough for an agent to select and invoke it for listing sources. It mentions the API key requirement and ties to specific sibling tools. It lacks details about response shape or edge cases, but for a parameterless list operation, this is largely complete.

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

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

The schema has no parameters, and schema description coverage is 100% (vacuously). The description adds meaning by stating what the list represents (private uploaded sources, files/URLs ingested via raggy_upload), which helps the agent infer expected output. With zero parameters, there is no parameter documentation burden, so a high score is justified.

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 ('List') and resource ('uploaded private knowledge base sources'), and specifies the ingestion method (files/URLs via raggy_upload). It distinguishes this tool from siblings by framing it as the source-listing tool, especially related to deletion.

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 gives use cases ('what sources have I uploaded' and 'to find a source ID for deletion') and names the sibling tools involved (raggy_upload, raggy_delete_source). It provides clear conditions for when to use the tool, though it doesn't explicitly state when not to use 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?

With no annotations, the description carries the behavioral burden. 'Semantic search' implies a non-mutating retrieval, and the call-count guardrail is useful, but the description does not say what a result contains, whether results are ranked, or whether any state changes occur. This is adequate 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?

Four short sentences, each carrying distinct information: function, trigger conditions, call-frequency limit, and sibling routing. The most important scoping 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?

For a low-complexity search tool with a fully described schema, the description is nearly complete: it covers purpose, when to use it, when not to use it, and an alternative. The only gap is the absence of any note about the return format, and there is no output schema to fill that gap.

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 applies and the description does not need to re-explain parameters. The prose adds no parameter-level detail beyond the schema, but none is required because every parameter already has a clear description in the schema.

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

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

The first phrase, 'Targeted semantic search over memories,' names a specific verb and resource and conveys the tool's exact function. The description then explicitly distinguishes it from raggy_context and raggy_timeline, so an agent can select it correctly among siblings.

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

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

The description gives explicit conditions: use it only after raggy_context returns nothing relevant, or for a mid-session follow-up lookup. It also provides a hard exclusion ('Do NOT call twice per question') and routes time-based queries to raggy_timeline, leaving no ambiguity about when this tool applies.

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

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

There are no annotations, so the description carries the behavioral burden. It clearly states that this is a save operation for unstructured notes, and it warns about metadata being low-value. However, it does not disclose persistence, retrieval behavior, URL ingestion behavior, or side effects beyond the schema.

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

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

Two tightly written sentences with no filler. The core purpose is front-loaded, and the usage guidance follows immediately. 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 note-save tool with full schema coverage and no output schema, the description is nearly complete. It covers the primary decision point (when to use remember vs capture). It could mention that URL can be ingested instead of text, but the schema already documents that, so the gap is minor.

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 covers 100% of the parameters, so the baseline is 3. The description adds minimal semantic value beyond the schema; the 'metadata adds no value' phrase reinforces that name and tags are optional or unnecessary, but it does not clarify the URL-vs-text distinction or value semantics beyond what the schema already states.

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

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

The description uses a specific verb and resource ('Save a simple, unstructured note') and explicitly contrasts itself with raggy_capture, which handles typed entries. An agent can immediately tell this tool from its main sibling 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?

It gives explicit routing guidance: prefer raggy_capture for typed content and only use raggy_remember for free-form notes where metadata adds no value. This directly tells the agent when to select this tool versus the obvious alternative.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does convey the key dual-mode behavior and the conditional dependency on session_id for action=get, and verbs like 'browses' and 'retrieves' imply a read-only operation. However, it omits return-format details, how sessions are defined/created, and any side effects, so an agent must infer the safety profile.

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 filler: the first front-loads the purpose with illustrative examples, and the second compactly explains the action enum. 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 moderately complex dual-mode tool, the description covers the core invocation logic well and the schema documents all five parameters. Gaps remain because there is no output schema or annotations: the return values and the definition of a 'session' boundary are left to inference, though the verbs 'browses' and 'retrieves' make the outputs largely predictable.

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

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

Schema description coverage is 100%, so the baseline is 3 even without extra description input. The description adds only marginal semantic value beyond the schema: it links action=get to 'all memories for one session_id' and ties limit/since to the act of browsing 'recent sessions', but the schema already documents each parameter and the conditional requirement on session_id.

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 use case ('session-based queries') and two concrete example queries, then maps each mode to a distinct verb-resource pair: action="list" 'browses recent sessions' and action="get" 'retrieves all memories for one session_id'. The session-based scope differentiates it from siblings like raggy_recall and raggy_timeline, which target individual memories or chronological events rather than grouped sessions.

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 frames when to use the tool ('Use for session-based queries like...') and gives two natural-language examples an agent can pattern-match against the user's request. However, it does not name alternatives or state when not to use it, leaving the agent to infer the boundary against siblings like raggy_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?

No annotations are provided, so the description carries the full disclosure burden. It does add useful behavioral context by revealing that 'since' accepts relative windows ('24h', '7d') in addition to ISO dates, which is not obvious from the schema and prevents misuse. However, it never states whether the operation is read-only, what the response shape is, or whether there are side effects — gaps that annotations would normally fill.

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

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

Three sentences with zero wasted words. The purpose and examples are front-loaded, the critical parameter behavior is second, and the sibling routing closes the definition. Every sentence contributes distinct 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?

For a query tool with no required parameters and 100% schema coverage, this is nearly complete: purpose, usage window, routing, and the most important parameter behavior are all stated. The remaining gaps are the absence of any output description (no output schema exists) and the unstated read-only nature, which is more significant because no annotations back up the safety profile.

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%, which sets the baseline at 3. The description exceeds that by documenting an accepted input format ('Pass since as a relative window (e.g. "24h", "7d") or ISO date') that the schema omits — the schema only says 'ISO date start'. This is a genuine expansion of meaning that helps an agent avoid passing invalid values.

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 — 'Use for time-based queries' — and reinforces it with concrete examples ('what did we work on today/yesterday/last week'). It explicitly names raggy_recall as the tool NOT to use, making the boundary between siblings unmistakable even 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?

It gives an explicit when-to-use rule with examples ('today/yesterday/last week') and a direct exclusion: 'Do NOT use raggy_recall for temporal questions — this is the right tool.' This leaves no ambiguity about which sibling to select for temporal queries.

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 burden. It provides useful behavioral context: the content is private, becomes indexed and searchable, and requires an API key. However, it does not disclose limits, duplicate-name handling, or error behavior, and its claim of 'files' support is not backed by any file parameter in the schema. 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?

Four short sentences, each earning its place: what it does, when to use it, when to use an alternative, and the auth prerequisite. The core action is front-loaded with zero 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?

For a moderate-complexity additive tool, the description covers purpose, usage conditions, privacy, and auth. With no annotations and no output schema, it could additionally describe the return value and duplicate/overwrite behavior, and reconcile the 'files' claim with a schema that only accepts url/content strings. These are minor gaps.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, including the url/content exclusivity constraint. The description's categories ('files, URLs, or long-form content') broadly map to the content/url parameters but add no semantic detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb ('Upload') and resource ('private knowledge base source') and enumerates the accepted inputs: files, URLs, and long-form content. It also names the sibling it is not (raggy_capture), so an agent can disambiguate 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 states when to use the tool ('documents, articles, or reference material the user wants indexed and searchable') and when not to ('For short notes/thoughts use raggy_capture instead'), naming the alternative with the condition that selects it. Nothing is left to inference.

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