Metis

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

With no annotations, the description fully discloses behavior: upsert semantics (keeps created_at, overwrites definition) and return type (confirmation message). This is comprehensive.

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

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

The description is concise and well-structured: a clear summary followed by detailed args and returns. Each sentence adds value without redundancy.

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 (2 string params) and the presence of an output schema, the description covers all needed context: upsert behavior, use case, and retrieval sibling. It is 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 description adds meaning beyond the schema by explaining that 'term' is the unique key and 'definition' is the stored text. With 0% schema coverage, this is essential.

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 it adds or updates a glossary term, specifying the action and resource. It distinguishes from the retrieval sibling 'get_glossary' by mentioning retrieval separately.

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 explains when to use it (maintaining a personal glossary for consistent definitions) and explicitly describes the upsert behavior. It also directs to 'get_glossary' for retrieval, providing clear guidance on 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?

The description notes auto-extraction of mood and energy, but lacks details on side effects, idempotency, required permissions, or what the return value contains (output schema exists but not discussed).

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 extremely concise with no wasted words, efficiently conveying the tool's purpose and parameters in two lines plus an Args list.

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?

While the description covers the core function, it omits behavioral details like constraints on content length, persistence behavior, or post-storage results. Given the tool's simplicity, it is minimally adequate but has clear gaps.

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

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

With 0% schema coverage, the description provides succinct but clear explanations for both parameters (content text, optional image path), adding value beyond the schema 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 tool stores a journal entry with auto-extracted mood and energy, distinguishing it from sibling add_* tools like add_memory_entry or add_glossary_term.

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 alternatives (e.g., add_memory_entry or other logging tools). There is no mention of prerequisites or constraints.

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 fully disclose behavioral traits. It explains that the tool inserts into a database table and optionally writes a markdown file, and describes the return value. It lacks details on permissions or side effects, but is generally 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 well-structured with sections (purpose, usage, args, returns) and is front-loaded. It is slightly long but every sentence is informative, earning 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?

Given the tool's complexity (6 parameters, 3 required) and the presence of an output schema, the description fully covers input semantics, behavior (database insert and optional file write), and return format. No gaps remain.

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?

With 0% schema description coverage, the description adds comprehensive meaning for each parameter, including allowed values for 'entry_type', comma-separated format for 'topics', and the role of 'detail' in creating a markdown file. This goes well beyond the basic 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 clearly states 'Add a new memory entry to the memory palace' with a specific verb and resource, and explicitly distinguishes itself from sibling tools 'store_episodic_memory' and 'store_semantic_memory'.

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 guides when to use this tool ('human-curated memory palace note') and when to use alternatives ('For machine/agent event logging use store_episodic_memory; for a distilled concept/definition use store_semantic_memory').

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 fully discloses behavioral traits: it modifies user-config.yaml, creates the file with defaults if absent, updates instead of duplicating on name match, and explains the active_by_default parameter's effect on activation state. The return value type is also specified.

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 efficiently structured: opening sentence for purpose, explanatory paragraphs, a 'Related tools' line, then 'Args:' and 'Returns:' sections. Every sentence provides value, with no redundant or extraneous content.

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 3 parameters, no annotations, and an output schema, the description covers all necessary aspects: purpose, behavioral details, parameter semantics, and return value. It enables an agent to correctly select and invoke the tool without additional context.

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 thoroughly explains each parameter: name as short label and dedup key, description as one/two sentences, and active_by_default with behavior (immediate activation vs storage/inactivation). This adds critical meaning beyond the schema's title and default.

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 or update) and the resource (specialist context). It distinguishes between adding and updating, and the context of routing/search tailoring provides specificity. The sibling tools list includes toggle_context and list_contexts, which helps differentiate.

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 explains when to use the tool (to add or update specialist contexts for tailoring) and mentions related tools (toggle_context, list_contexts). However, it does not explicitly state when not to use it or provide alternatives beyond listing related tools, leaving room for slight ambiguity.

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, but description covers key behaviors: records modification time, sets watch, re-add updates, file must exist, returns confirmation or error. No hidden side effects 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?

Well-structured with summary, details, Args, Returns. Slightly verbose but adds necessary context. Efficient overall.

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 output schema exists, description still clarifies return values. Covers prerequisites, re-add logic, alternative tool. Fully adequate for a simple file-tracking 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 0%, so description adds full meaning: path must be absolute and exist, label is optional with default empty and on re-add empty label leaves old unchanged. Outperforms basic 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?

Clearly states 'Add a single file to the tracked-files list and start watching it.' Identifies specific verb, resource, and action. Distinguishes from sibling 'connect_project_folder' for bulk registration.

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

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

Explicitly says when to use (register one file) and when not ('To register a whole project at once, use connect_project_folder'). Also explains re-adding behavior.

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 fully disclose behavior. It states it adds a topic but does not mention whether duplicates are allowed (despite hinting at 'unique' in param doc), what side effects occur (e.g., triggers notifications), or what happens if the topic already exists. This lack of behavioral detail is a significant 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 very short and front-loaded with the purpose, but it uses Python docstring style with 'Args:' which is unnecessary for JSON. It is concise but could be more efficiently structured without the docstring formatting, potentially adding a return description or behavior note.

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 an output schema (not shown) and low complexity (2 params, no enums), the description is incomplete. It does not explain the return value, error conditions (e.g., duplicate topic), or the lifecycle of added topics. The tool's purpose is clear but operational details are missing for a complete understanding.

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 add value. It only repeats parameter names with minimal context ('topic: Topic name (unique)', 'description: Optional description...'). The schema already contains required/default info; the description does not explain formats, constraints, or usage examples, adding little 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?

The description clearly states the tool's purpose: 'Add a topic to track for new publications.' It uses a specific verb ('Add') and resource ('topic'), and distinguishes from similar sibling tools like add_glossary_term or add_memory_entry by specifying the context of tracking new publications.

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 on when to use this tool versus alternatives (e.g., search or list tools). There is no mention of prerequisites, usage context, or when not to use it. The description is purely operational without contextual decision support.

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, but the description clearly states it reads 'reflexion_log' entries (non-destructive) and returns aggregated themes. It does not contradict any annotations. Slight lack of mention of potential side effects, but none expected.

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 relatively concise (3 sentences) and front-loaded with the core purpose. It could be slightly tighter but is clearly 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?

Given an output schema exists, the description covers the input parameters, data source, time window, and output categories sufficiently. It does not need to detail return values.

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%, but the description adds meaning: 'days' is time window (default 14 days), 'agent_slug' scopes to one agent or all. This compensates for the missing schema descriptions.

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 ('Theme') and resource ('recent reflexions per agent') with clear scope (Phase 9b). It distinguishes from siblings like 'consolidate_reflexions' by focusing on aggregation and thematic grouping.

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 when to use (to get top themes from recent reflexion logs) but does not explicitly mention when not to use or suggest alternatives among the many 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 fully carries the burden. It discloses the regex-based nature, no execution, no data access, and no LLM exposure. It does not cover error handling or side effects, but the output schema covers return values.

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 extremely concise: two short paragraphs plus an Args section. Every sentence adds value, 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 tool with an output schema, the description is complete. It explains the extraction method, limitations, and safety aspects, leaving no obvious gaps for the agent.

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 single parameter 'path' has 0% schema description coverage, but the description adds crucial context: 'Absolute path to the script file (.R, .Rmd, .qmd, or .py).' This specifies format and absolute path requirement, adding significant value 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?

The description clearly states it parses R or Python scripts and extracts structured metadata. The verb 'parse' and resource 'script' are explicit, and it distinguishes itself from sibling tools by focusing on static analysis without execution.

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 explains that parsing is regex-based with no execution, no AST, no data access, and code is not sent to an LLM. This provides clear guidance on when to use the tool safely, though it doesn't explicitly list alternatives 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?

With no annotations provided, the description fully bears the burden. It details the replacement behavior (list of PII types), modes ('full' vs 'preview'), and the optional name replacement heuristic. It also describes the output JSON structure, leaving no ambiguity about the tool's 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?

The description is concise yet comprehensive, using bullet points for replacements and clear sections for args. Every sentence adds value without redundancy.

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 3 parameters, an output schema, and no nested objects, the description covers all necessary aspects: what it does, how to use it (args), and what to expect (output JSON with 'anonymized' and 'replacements'). It is fully complete for an agent to select and invoke correctly.

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

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

Schema description coverage is 0% (no descriptions in schema). The description compensates by explaining all three parameters: content (text to anonymize), mode (full/preview), and replace_names (heuristic for CAPITALIZED tokens). It also explains the output format, adding significant value.

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 'Scrub PII from text and return anonymized version + replacement map.' It lists specific PII types and their replacements, distinguishing it from sibling tools like redact_data_file or diff_anonymization.

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 explains the tool's purpose and parameters (mode, replace_names) but does not explicitly state when to use this tool versus alternatives like redact_data_file or diff_anonymization. However, the context is clear enough for an agent to infer usage.

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 full burden. It discloses the write-to-disk action, backup creation, and database update. However, it fails to mention whether the operation is reversible (backup implies some reversibility but not explicitly), required permissions, or behavior on invalid proposal_id. Some transparency, but gaps remain.

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 plus an Args line, front-loaded with the primary action. Every sentence adds value: what it does, backup detail, database update, parameter meaning. No unnecessary words.

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

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

Given the existence of an output schema (not shown), the description covers the main effects: write, backup, status update. It does not explain error handling or state prerequisites, but for a single-parameter tool with clear purpose, it is largely sufficient. Minor completeness gaps leave room for improvement.

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 provides 0% description coverage, so the description must compensate. It explains the parameter 'proposal_id' as 'the id from skill_improvement_proposals', giving context beyond the schema's bare type and title. This is helpful for agent understanding, though additional detail on validity constraints would improve it further.

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 'Apply' and the resource 'self-improvement proposal', with specific actions: writes change to disk, backs up previous content, updates proposal row. This distinguishes it from sibling tools like 'propose_skill_improvement' (creation) and 'approve_proposal' (state change) by focusing on execution.

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 when a proposal is ready to be applied, but it does not explicitly state when to use it versus alternatives like 'approve_proposal' or 'reject_proposal'. No prerequisites or conditions for use are mentioned, leaving the agent to infer 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?

Discloses key behaviors: writes to skill.md, marks as approved, creates backup. No annotations provided, so description carries full burden. Could mention failure modes or return value, but output schema exists to cover that.

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 plus an Args section. Every sentence provides necessary information without redundancy. Front-loaded with the core action.

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 complexity (single required parameter, output schema exists), the description covers the essential action and side effects. Could mention that the proposal must be pending, but this is implied by the purpose.

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?

Description adds meaning to the sole parameter 'proposal_id' by specifying it is 'The numeric ID from get_pending_proposals()', guiding the agent on how to obtain the correct value. Schema only says integer, so this adds significant value despite 0% schema description coverage.

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

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

Clearly states the verb 'approve' and the resource 'pending skill improvement proposal'. Distinguishes from siblings like 'reject_proposal' and 'propose_skill_improvement' by specifying that it applies the proposal by writing to skill.md and marking as approved.

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?

Description provides clear context that this tool is for approving proposals from get_pending_proposals() and mentions the backup creation. It doesn't explicitly say when to use vs alternatives, but the purpose is self-evident given the sibling 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?

With no annotations, the description carries the full burden. It discloses the core behavior: sets status='archived', keeps in DB, affects default view but not search. It does not mention permissions, reversibility, or side effects, but for a simple archive operation the transparency is adequate.

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

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

Three concise sentences plus an Args line. The first sentence states the core purpose, the second provides the SQL detail, and the third explains the effect. No wasted words; information is well-structured and front-loaded.

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

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

Given low complexity (one parameter, simple action) and the presence of an output schema, the description covers the key aspects: what happens to the item, its visibility, and the parameter meaning. Minor gaps like reversibility or permissions are not critical for 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?

The schema has 0% description coverage, so the description must explain the parameter. It does so by stating that relative_path is the primary key in the library_seeded table, adding context beyond the parameter name. This is sufficient, though a format example could improve it.

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 'Archive' and the resource 'library item,' explaining that it marks an item as no longer active but keeps it in the database. It distinguishes this from deletion (e.g., remove_library_item) by noting the item remains searchable and cross-pollinated.

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 explains the effect (disappears from default view, stays searchable) but does not explicitly state when to use this tool versus alternatives like remove_library_item or archive_project. The usage context is implied rather than directly guided.

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 transparently describes that the project's status is set to 'archived', data is kept, and visibility changes. It does not mention side effects or reversibility, but the 'unarchive_project' sibling partially addresses that.

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 extremely concise: two sentences plus a parameter listing. All information is relevant and front-loaded. No unnecessary words.

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

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

Given the single parameter and existence of an output schema, the description covers the essential aspects: what the tool does, the effect on data availability, and the parameter. It is fully adequate for an agent to understand and invoke the tool correctly.

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

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

The input schema has 0% description coverage, but the description includes an 'Args' section that explains the required 'project_id' parameter. This adds meaning beyond the schema, though it could provide more detail (e.g., format or example).

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 action: 'Archive a project — marks it inactive but keeps all data.' It uses a specific verb ('archive') and resource ('project'), and distinguishes itself from siblings like 'remove_project' and 'unarchive_project' by clarifying that data is preserved and the project remains available for context and 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 explains the effect ('disappears from active view but remains available for brainstorm context and search'), implying when to use it. However, it does not explicitly state when not to use it or compare with alternatives like 'remove_project'. The guidance is clear but could be more explicit.

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, description carries full burden. It discloses that the tool searches a pre-built index and returns synthesized citations, implying non-destructive read-only behavior. However, it doesn't explicitly state no side effects or permissions needed.

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?

Concise and front-loaded: one sentence for purpose, minimal parameter list. No filler, but could be slightly more 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?

Given sibling tools and presence of output schema, description covers primary use case, dependency on index, and scope variants. Lacks details on return format but output schema handles that.

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%, but the description's 'Args' section explains each parameter: question, top_k (default 5), and scope with concrete options (default, ph_library). Adds significant value beyond bare schema.

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

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

Description clearly states the tool answers a question using the user's indexed PDF library via PaperQA2, returning a synthesized answer with citations. It distinguishes from sibling tools like search_library by focusing on synthesis rather than raw retrieval.

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 guidance on prerequisite (build index first with index_library_pdfs) and explains scope options. Could be stronger by explicitly listing when not to use, but gives adequate 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?

Mentions 8000 char limit per source and returns assembled string with source labels, but does not explain what 'recent content' means, behavior when sources are empty, or default behavior when date_filters is null. With no annotations, more detail would improve 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?

Concise and well-structured: one sentence for purpose, then clear details on char limit and output, then arg descriptions in docstring style. No unnecessary words.

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

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

Given two params, no annotations, and an output schema, the description covers essential aspects: sources, char limit, date filters example. However, it lacks definition of 'recent' and default filtering behavior, which slightly reduces 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 coverage is 0%, so description compensates well by explaining that sources is a list from a set of allowed values (library, meetings, news, ideas, journal) and that date_filters is an optional dict with source-specific date filters, including an example. Adds significant meaning beyond the schema structure.

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

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

Clearly states the verb 'assemble' and the resource 'context from multiple sources for brainstorming'. Distinguishes from sibling tools like brainstorm_turn or get_brainstorm_session by focusing on gathering context from specific sources.

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 for brainstorming context assembly but does not explicitly state when to use versus alternatives like load_project_context or get_agent_context. No when-not-to-use guidance is 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, the description carries full burden. It discloses the use of SQLite's Online Backup API, safety for live databases, and return fields (backup_path, size_kb, checksum, elapsed_ms). This is more than basic 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 concise, front-loaded with purpose, followed by a safety note and bulleted argument list. The return value description is included. Slightly verbose due to redundant argument list with schema, but overall 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?

For a tool with 3 optional parameters and no required ones, the description fully covers purpose, safe usage, parameter details, and return format. No obvious gaps.

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

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

Schema description coverage is 0%, but the description provides clear explanations for all three parameters: destination (default path), label (filename appendix), and extra_destination (secondary copy). This adds significant meaning 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?

The description specifies the action (create), resource (timestamped backup), and context (Metis SQLite database). It clearly distinguishes from sibling tools like restore_db and verify_backup.

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 states it is safe to run while the database is live, providing good context. However, it does not explicitly state when not to use or mention alternatives like encrypt_backup.

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 that the tool fetches relevant ideas, notes, questions, and library notes, lists five steering modes with their meanings, explains session continuation via session_uuid, and describes the return format including session_uuid, turn_number, context, steering_prompts, and instructions. This is comprehensive.

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 well-structured with a summary sentence, usage instruction, enumerated steering modes, and a parameter list. Every sentence adds value, though the parameter list could be more concise. Overall, it's appropriately sized for a complex 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?

Given the tool complexity (iterative brainstorming with multiple steering modes) and the presence of an output schema (mentioned in description), the description is complete. It covers purpose, when to use, all parameters with semantics, steering modes, session management, and return value fields. No significant gaps.

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

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

Schema description coverage is 0%, but the description fully explains each parameter: topic (the brainstorm topic), steering (with explicit list of allowed modes), session_uuid (continuation vs new session), and turn_notes (optional notes). This adds complete semantic meaning beyond the schema's minimal type definitions.

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 'Run one turn of a brainstorm session, returning relevant context.' It specifies the verb and resource, and distinguishes from sibling tools like get_brainstorm_session and save_brainstorm_output by focusing on iterative turns with steering modes.

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 guidance: 'Call this at the start of a brainstorm and after each steering action.' This clearly indicates when to use. While it doesn't explicitly list when not to use, the context makes it clear this is for iterative brainstorming, and siblings cover other phases.

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 must cover behavior. It discloses use of local embeddings and no API key, and explains the force_rebuild parameter. However, it omits whether the tool creates databases, the scope of files indexed, potential resource usage, or side effects on existing 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?

Concise, well-structured. Begins with core purpose, then model details, layer examples, and a clear Args block. No filler sentences.

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 output schema exists, return values are not needed. However, important context is missing: how PDFs are associated with a database, whether the database must exist beforehand, and any time/resource implications. Adequate 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 0% but description compensates well: explains 'database' as a slug with defaults and examples, and 'force_rebuild' as re-indexing already indexed files. This adds significant meaning beyond the bare schema.

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

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

Description clearly states it indexes a knowledge database layer from PDFs, using a local embedding model. It provides examples of database slugs and links to create_knowledge_database(), but does not explicitly differentiate from sibling tools like index_library_pdfs or index_pdf_library.

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 explicit when-to-use or when-not-to-use guidance. The mention of local model implies offline use, but there is no comparison to alternatives or prerequisites for custom databases.

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, so description bears full burden. It discloses auto-tag extraction, domain/project linking, and cross-pollination behavior. Could mention if other tables are modified, but overall adequate.

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?

Concise, front-loaded with main action, and uses an Args section. Every sentence adds value without redundancy.

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 output schema present, return values need not be described. Covers core functionality, side effects, and parameter details. Could mention content length constraints but 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 coverage is 0%, but description adds meaningful context for all 4 parameters: content as idea text, source with default, image_path optional, and auto_cross_pollinate with behavior explanation. Fully compensates for schema gaps.

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 clearly states 'Store an idea in the SQLite ideas table' with specific verb and resource. Distinguishes from siblings like add_memory_entry and capture_observation by mentioning auto-tagging and cross-pollination.

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 for capturing ideas with automatic connections, but no explicit when-not-to-use or alternatives. The cross-pollination feature is highlighted, but no guidance on when to disable 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 must disclose behavioral traits. It mentions recall in future sessions, implying persistence, but does not address side effects, mutability, authorization needs, or error behavior. This is a significant gap given the absence of annotations.

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 well-structured with a clear purpose, followed by parameter details. It is concise without fluff, though the parameter list is somewhat lengthy. Front-loading the purpose aids quick understanding.

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 output schema exists, return values are covered. The description explains what the tool does and its parameters adequately. However, it lacks details on error handling, rate limits, or required permissions, leaving some context gaps for an agent.

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?

With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose, expected format (e.g., content: 1–3 sentences), and default behavior (e.g., concepts auto-extracted). This adds meaning beyond the raw 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 clearly states the tool records typed observations during an agent run, with specific observation types (discovery, decision, etc.) and the purpose of enabling recall in future sessions. This distinguishes it from sibling tools like add_memory_entry or add_journal_entry.

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 advises using the tool throughout a run to capture learning, but does not explicitly state when not to use it or suggest alternatives like add_memory_entry or add_journal_entry. The guidance is implied but lacks explicit 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 provided, and description lacks details on data handling (e.g., whether content is stored or modified), leaving significant behavioral ambiguity.

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?

Concise and front-loaded with main action; Args section is somewhat redundant but acceptable given schema lacks descriptions.

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?

Output schema exists and description mentions return values; parameter coverage is adequate but not comprehensive; no edge cases or prerequisites noted.

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 has 0% description coverage; description provides one-line explanations for each parameter but adds limited additional value beyond the schema structure.

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 clearly states the tool scans content for PII patterns and classifies sensitivity level, distinguishing it from related tools like anonymize_text or redact_data_file.

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 explicit guidance on when or when not to use this tool compared to siblings like anonymize_text; usage is implied but not clarified.

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 present, so description carries full burden. It discloses no modification of original, authorization gate, and lists all supported operations with format examples. Returns expected output fields are noted.

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

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

Front-loaded with purpose, uses bullet points for operations, clearly highlights authorization. Slightly verbose but every sentence adds 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?

With output schema provided, description covers all necessary behavioral and operational details: never modifies original, authorization gate, all operations, parameter semantics. Fully equips agent to use tool correctly.

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

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

Schema coverage is 0%, but description provides detailed meaning for each parameter: path (absolute path), authorized (boolean with auth flow explained), operations (list with examples), output_path (default behavior when empty).

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 'Apply cleaning operations to a dataset and write a new file' with a specific verb and resource. It distinguishes from siblings by focusing on execution vs. suggestion (suggest_cleaning) and other data 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?

Clearly explains never modifies original, always writes to output path, and authorization requirements. However, lacks explicit when-to-use vs. alternative tools like suggest_cleaning or profile_dataset.

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 full burden. It discloses that the tool enforces at least one decision, writes to episodic memory, and requires concrete decisions. It does not mention side effects or permissions, but provides adequate transparency 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?

The description is well-organized with a clear front-loaded purpose, usage note, and parameter list. It is slightly verbose but every sentence adds value. Could be slightly more concise, but still effective.

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 4 parameters, no output schema, and no annotations, the description covers the tool's role, when to call, parameter details, and storage behavior. It provides sufficient context for an agent to use the tool correctly.

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

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

Schema description coverage is 0%, so description must compensate. It explains the decisions parameter with examples, notes summary's optionality, describes key_topics as tags, and session_id as optional. This adds significant meaning beyond the schema structure.

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 'commit', the resource 'key decisions from this session', and explicitly distinguishes from the sibling tool 'save_session_summary' by noting its enforcement of at least one decision and separate episodic memory storage.

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 explicit when to use: 'at the end of every agent-routed session, before delivering the final result'. Also gives an alternative tool ('save_session_summary') and explains the difference.

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 description carries full burden. It explains the comparison operation and return format but does not disclose whether the tool is read-only, potential side effects, error conditions, or performance implications. Basic behavioral traits are covered but not comprehensively.

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?

Description is concise and well-structured: first sentence summarizes purpose, then explains inputs, then outputs. Uses clear formatting with bullet points for return fields. 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?

Given an output schema exists (not shown), description covers the key aspects: inputs, outputs, and usage. It could mention prerequisites (e.g., need to call profile_dataset first) but overall is adequate for a focused diff 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 0%, yet description adds full context: each parameter (before_profile, after_profile) is described as a JSON string from profile_dataset() and explains their roles. This compensates entirely for the lack of schema 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?

Description clearly states the tool compares two dataset profiles and produces a side-by-side diff. It lists specific outputs like rows added/removed, columns added/removed, null count changes, type changes, and a human-readable summary. This distinguishes it from sibling tools such as profile_dataset.

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 instructs to pass JSON strings from profile_dataset() and describes the arguments and return value. While it doesn't explicitly state when not to use or list alternatives, the usage context is clear and specific enough for correct invocation.

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 explains provider-specific parameters and that Mendeley uses BibTeX export. However, it does not disclose whether the operation overwrites existing config, requires specific permissions, or has side effects like restarting services. This is adequate but not comprehensive.

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?

Very concise: two sentences describing purpose, then a bulleted list of argument explanations. Every sentence adds value; no fluff. Front-loaded with the key purpose.

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 that an output schema exists (not shown), the description doesn't need to explain return values. It covers usage scenarios (setup, switching) and parameter details. It could mention validation or success indicators, but is mostly complete for a configuration 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 0%, so the description compensates well. It explains that provider can be 'zotero' or 'mendeley', that api_key comes from a specific Zotero URL, user_id is numeric, and bibtex_path is for Mendeley. This adds meaning beyond the bare schema.

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

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

The description clearly states it configures the library provider for the Metis installation, with a specific verb (configure) and resource (library provider). It distinguishes from sibling tools like import_bibtex_library and sync_zotero_library which are related but different operations.

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

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

It explicitly says 'Call this during setup or when switching reference managers', providing clear context for when to use. It does not explicitly state when not to use it or list alternatives, but the guidance is sufficient.

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 fully carries the transparency burden. It explains that the tool walks the folder recursively, adds files with recognized extensions to a `tracked_files` table, and includes a safety limit (max_files). This is adequate disclosure for a registration 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 concise and well-structured with a clear separation of purpose, behavior, and parameter details. It is slightly repetitive in the first two sentences, but overall 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 moderate complexity, the description covers the tool's purpose, usage flow, parameter meanings, and behavioral constraints. An output schema exists, so return values are documented separately. It lacks error scenarios but is otherwise complete.

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

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

Schema description coverage is 0%, but the description provides detailed explanations for each parameter: folder_path (absolute path), label (short label with example), and max_files (safety limit with default). This adds significant meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Register all relevant files in a project folder so Metis can read them.' It lists recognized extensions and distinguishes from the sibling tool `read_file()` by noting this is a one-time setup operation per project.

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 'Call this once per project; after that, use read_file() to read any individual file.' This gives clear usage context and suggests an alternative, though it does not explicitly mention 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?

Despite no annotations, the description fully discloses behavior: how decisions are grouped and summarized, session summaries archived, reflexions consolidated monthly. It clarifies that originals are marked archived but still queryable, and that recall is kept fast. No contradictions with annotations (none provided).

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?

Well-structured with bullet points and separate sections. Efficiently communicates three consolidation rules and parameter details without unnecessary words. Every sentence adds 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?

Complete coverage: explains what the tool does, how it works for each memory type, parameter details, and return value (a report of actions). No gaps given the tool's complexity and parameter count.

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

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

Schema coverage is 0%, but the description compensates fully by explaining each parameter's purpose and default values in the Args section. dry_run is clearly described as a preview mode, decision_age_days and session_age_days have clear functions.

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 specifically states it consolidates old memories into monthly summaries and archives originals, with clear breakdown of three memory types. It distinguishes from sibling tools like consolidate_reflexions and consolidate_session_memory by being the comprehensive consolidation tool for all old memories.

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

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

Explicitly advises to run with dry_run=True first to preview changes. Also provides default age thresholds and explains the tiered retention behavior, giving clear guidance on when to use this tool for memory maintenance.

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 full burden. It discloses idempotency, deduplication, and the 7-day working memory pruning threshold. However, it omits authorization requirements or side effects like potential data loss, though the details given are substantial.

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 extremely concise: two sentences of functional explanation plus one for idempotence. No filler, key information front-loaded. Every sentence earns its place.

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

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

An output schema exists, so return values are covered. The description explains the core transformation (reflexions to semantic nodes, pruning) and key constraints (count threshold, dedup, window). Missing minor details like error states or performance implications, but overall sufficient for a knowledgeable agent.

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?

Despite 0% schema description coverage, the description explains both parameters: min_count and days are directly referenced in '>= min_count times in the last `days`'. This adds meaning beyond the bare schema, though it could be more explicit about default behaviors.

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-resource pair: 'distil recurring reflexion themes into semantic memory' and 'prune working memory'. It uses specific terms like 'min_count' and 'days' to define scope, distinguishing it from sibling consolidation tools like consolidate_old_memories and consolidate_session_memory.

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 'Runs the nightly self-improvement consolidation', indicating it's a periodic maintenance task. While it doesn't list when not to use it or alternative tools, the context is clear enough for an agent to infer appropriate scheduling.

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 discloses key behaviors: reading recent runs, filtering based on output files and summaries, deduplication against existing entries, and writing to DB and markdown files. It lacks details on side effects or permissions but provides sufficient transparency for safe invocation.

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

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

The description is concise and front-loaded with the main action. The Args section is integrated but could be more structured (e.g., bullet points). Overall efficient with no wasted sentences.

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 two parameters, high coverage in description, and an output schema (not shown), the description sufficiently explains the process, inputs, and outputs. No major gaps apparent for agent usage.

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

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

Despite 0% schema description coverage, the description's Args section explains both parameters (n_runs default 20, min_quality with options 'high' and 'all'). This adds meaningful context beyond the schema, clarifying behavior 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?

Description clearly states the tool scans recent agent runs, identifies high-value work, deduplicates, and writes memory entries. It specifies verbs 'scan' and 'write' with resources, and contrasts with similar siblings like 'consolidate_old_memories' and 'add_memory_entry' through its explicit workflow.

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 explains the tool reads recent runs and the meaning of parameters (n_runs, min_quality), implying use for consolidating session memory. However, it does not explicitly state when to use this vs alternatives like consolidate_old_memories or add_memory_entry, nor provides when-not-to-use guidance.

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

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

No annotations provided, so description carries full burden. Discloses that it registers a database layer and that indexing requires a separate step. Does not mention idempotency, error behavior, or if overwriting occurs on duplicate slug. Adequate but not thorough.

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?

Brief description followed by usage tip then parameter list. Each sentence adds value. Could be slightly more compact, but overall 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?

Covers purpose, parameters, and follow-up steps. Has output schema (not shown) so return values are handled. Missing error handling or behavior on duplicate slugs. Adequate for a creation tool with moderate complexity.

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

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

Schema coverage is 0%, but description provides detailed explanations for all 5 parameters. Explains slug as URL-safe identifier, layer as 4+ for custom, folders with example. Adds value beyond basic type info.

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?

Clear verb 'Register' and resource 'custom knowledge database layer'. Distinguishes from siblings like build_pdf_knowledge_db which is a follow-up step, but not explicitly compared to other create 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?

Provides sequential workflow: create, then add PDFs, then call build_pdf_knowledge_db. Explains layer numbering (4+ custom). Does not specify when not to use or alternatives, but gives practical 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?

No annotations are provided, so the description carries full burden. It states the tool creates a DB record and makes the project available for linking and memory search, but does not mention error handling (e.g., duplicate titles), permissions, or side effects. This is adequate but not exhaustive.

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

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

The description is concise and well-structured: a one-sentence overview, a usage context sentence, an effect sentence, and a clear 'Args' list. No unnecessary words, and critical 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?

Given the tool's simplicity (4 parameters, 1 required) and the presence of an output schema, the description adequately covers the behavior (record creation, UI appearance, linking capability). No major 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?

With 0% schema description coverage, the description compensates fully by explaining each parameter: title (human-readable name with example), description (one sentence), domain (with examples), and source (with allowed values). This adds significant meaning 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?

The description clearly states the specific action ('register a new project'), the resource (Metis platform), and the effect (creates DB record, appears in Work tab). It distinguishes from siblings like create_project_full by implying this is the standard project creation 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 provides a clear scenario for when to call the tool ('when a researcher confirms they want a Claude conversation or project tracked permanently'). It does not explicitly mention when not to use or alternatives like create_project_full, but the context is clear enough.

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 must fully disclose behavioral traits. It does not mention idempotency, error handling on existing project, permissions, or side effects beyond creation. The listing of integrations is informative but insufficient for safe invocation.

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?

Very concise: two short sentences plus a clean arg list. All content adds value without redundancy. Front-loaded purpose.

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?

Output schema exists, so return value is covered. However, with 6 parameters and no behavioral context (e.g., overwrite behavior, folder requirements), the description lacks completeness for a tool of this complexity.

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 descriptions are absent (0% coverage), so the description carries the full burden. Each parameter has a concise explanation, with useful details like auto-detection for description and scan_type options. Title explanation is minimal but acceptable.

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 clearly states it creates a project with full Metis integration including DB record, CLAUDE.md, and Claude Desktop. It also notes it is the unified tool used by installers and dashboard, but does not explicitly differentiate from sibling 'create_project'.

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?

Describes intended use as the unified project creation tool, implying it is the standard path. However, no explicit guidance on when to use alternatives (e.g., simpler create_project) or when not to use 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?

No annotations provided, so description carries full burden. It discloses key behaviors: default values for owner, recurrence auto-creation on completion, and subtask creation via parent_task_id. Does not discuss error conditions or side effects beyond creation.

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?

Description is well-structured with a clear header and bulleted parameter list. It is reasonably concise, though some lines are slightly verbose. Every sentence adds value without redundancy.

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

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

Given 7 parameters (2 required) and an existing output schema, the description covers all parameters with meaningful explanations. It lacks discussion of edge cases or error handling, but for a create operation, the essential context is 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 coverage is 0%, meaning parameters have no descriptions in the schema itself. The description compensates fully by providing clear explanations for each parameter, including formats (e.g., YYYY-MM-DD for due_date), allowed values (e.g., recurrence options), and usage context (e.g., parent_task_id makes it a subtask).

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 clearly states 'Create a new task in the SQLite database' with a specific verb and resource. It lists all parameters with explanations, distinguishing it from sibling tools like update_task and delete_task.

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 creating tasks but does not explicitly state when to use this tool vs alternatives like update_task or delete_task. No guidance on when not to use it or context-specific recommendations.

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?

Without annotations, the description carries the burden of behavioral disclosure. It explains that the tool searches multiple tables and returns top results, but does not mention side effects, permissions, or response structure beyond the stated fields. The behavior is transparent enough for a read-only search.

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 extremely concise: a single-sentence purpose followed by a bullet-like explanation of sources and return format, with one parameter. Every sentence is essential 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?

Given the presence of an output schema and the tool's straightforward search nature, the description adequately covers the tool's behavior, sources, and return structure. More guidance on when to use it among many similar siblings 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?

The single parameter 'content' is described as 'Text to find cross-domain connections for,' which adds value over the name alone. However, with 0% schema description coverage, the description does not fully compensate by specifying format 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 clearly states the tool's function: finding cross-domain connections for given text, specifying the tables it searches and the structure of the result (top 5 with source type, title, snippet). This clearly distinguishes it from generic search 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?

The description implies when to use the tool (for cross-domain connections) but does not explicitly state when not to use it or provide alternatives among the many sibling search 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?

Discloses key behaviors: appends timestamped lines, can read when text is empty, single entry per calendar day. No annotations provided, so description bears full burden.

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?

Concise: two short paragraphs plus an Args section. Every sentence adds value — no redundancy or fluff.

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

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

For a simple tool with one parameter and existing output schema, the description covers purpose, usage, behavior, param semantics, and sibling differentiation completely.

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?

Despite 0% schema description coverage, the description fully explains the single parameter 'text' — its role in appending vs reading, and the default empty 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?

Clearly states the verb ('append to or read') and resource ('today's daily note') and distinguishes from sibling 'add_journal_entry' by noting the single-entry-per-day pattern.

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 explicit context for when to use ('for fast, low-friction capture') and contrasts with the sibling 'add_journal_entry', though no explicit when-not-to-use is given.

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?

In the absence of annotations, the description adequately discloses key behaviors: output file location (next to .enc or explicit output_path), that the passphrase is never stored, the format reversal, and the return structure. It could mention potential overwrite behavior or error conditions, but what is provided is sufficient.

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

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

The description is concise and well-organized: a one-sentence purpose, format details, output behavior, parameter listing, and return format. Every sentence adds value without redundancy.

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 presence of an output schema that likely details the return structure, the description adequately covers the tool's purpose, behavior, parameters, and output. It fully addresses the needs of a decryption tool in this context.

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 provides clear, informative descriptions for all three parameters (enc_path, passphrase, output_path), explaining their roles in the decryption process. This fully compensates for the lack of schema descriptions.

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 states that the tool decrypts a .enc backup produced by encrypt_backup(), and explains the format it reverses. It clearly distinguishes itself from the sibling encrypt_backup by being its counterpart.

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 identifies the tool as the counterpart to encrypt_backup, establishing when it should be used (to decrypt backups). While it doesn't explicitly list exclusion criteria, the context of being the decryption complement provides clear 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?

Discloses that deletion is permanent and cannot be undone, and describes return values (confirmation or note if task not found). No annotations provided, so description fully carries the burden.

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?

Well-structured with sections but slightly verbose. The 'Args' and 'Returns' format is helpful but 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?

Covers all necessary aspects: purpose, usage context, parameter detail, return value, and irreversibility. Appropriate for a simple tool with output schema.

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?

Adds meaning beyond schema by explaining task_id is obtained from get_tasks and is required. Schema coverage is 0%, so description compensates well. Could include format hint but sufficient.

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

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

Clearly states 'Permanently delete a task from the database' with a specific verb and resource. Distinguishes itself from siblings by contrasting with create_task and update_task.

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

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

Explicitly advises when to use (tasks created in error or no longer relevant) and when not (use update_task with status='done'). Also tells how to obtain task_id via get_tasks.

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 implies a read-only scan (detecting repos and folders), but does not explicitly state that no modifications occur. A direct statement would be better.

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, front-loaded sentences: purpose, context, and parameter detail. Every sentence provides essential information without redundancy.

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 core functionality and parameter. Since an output schema exists (not shown), the absence of return value explanation is acceptable. It is adequate for the tool's simple nature.

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 single parameter scan_path is described with its purpose ('absolute path to scan') and default behavior ('parent of METIS_RC_ROOT'). This adds significant value beyond the schema, which only has a default and title.

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 it scans for 'unregistered git repos and article folders', which is a specific verb-resource combination. This clearly distinguishes it from sibling scanning tools like scan_folder_for_intent or scan_inbox.

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 mentions onboarding as the use case and directs to call create_project() for registration. While it doesn't list when not to use, the guidance is clear and actionable.

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 behavioral transparency burden. It explains the paging parameter behavior ('get only the first page (faster for large resources)') and provides examples showing typical usage. It does not contradict any annotations (none present). However, it could explicitly state idempotency or read-only nature.

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 well-structured with sections (Args, Examples) and uses bullet points for parameter descriptions. It is concise yet informative, though the examples could be slightly trimmed without loss of clarity.

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 4 parameters (1 required), no enums, and an existing output schema, the description is complete. It covers all parameters, provides usage examples, and references the sibling tool dhis2_query. No gaps are left for an agent to misinterpret.

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 add meaning. It does so by explaining each parameter: resource (with examples), filters (format with example), fields (default value), and paging (behavior). This goes beyond the raw schema, though it could provide more exhaustive resource examples or filter syntax details.

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 'Query DHIS2 metadata with a simplified interface' and identifies itself as a 'Convenience wrapper around dhis2_query()', using specific verbs and resource types. It distinguishes itself from its sibling tool dhis2_query by emphasizing simplicity.

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