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

No annotations provided; description fully covers behavioral traits: exclusive lock yielding 'lock_held' status, return digest structure, mode differences (heuristic vs llm), tier restrictions, and session analysis scope.

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 first then details, but slightly verbose. Each sentence adds value, though 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?

No output schema or annotations, but description fully covers parameters, return value (digest dict), edge cases (lock held), tier limitations, and mode differentiation, making it complete for an agent to use.

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

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

Schema coverage is 0%, but description comprehensively explains all 4 parameters: project (matches tag), surface (any or null for all), max_sessions (default 50), mode (heuristic free, llm requires Pro), adding critical context 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?

Clearly states that the tool runs memory consolidation to build a structured digest, specifying actions (analyzes recent sessions, extracts decisions, open questions, tech stack facts) and distinguishing it from other memory/export 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?

Mentions free tier limits (3/day) and Pro unlimited, and the exclusive lock behavior, but does not explicitly contrast with alternative tools like get_memory_digest or get_context_for.

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 does not disclose whether update is merge or replace, side effects, or error conditions. For a mutation tool, this is insufficient.

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: three sentences overview plus a focused bullet list of parameters. No fluff; 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?

Covers the core operation and parameters, but lacks details on return value (expected for create/update), update behavior, and error handling. With 5 parameters and no output schema, more completeness would be beneficial.

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 includes an Args section that explains each parameter's purpose (e.g., 'expected_skills: Skills typically used in this project's sessions'). This fully 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?

Stated as 'Create or update a project definition' – clear verb+resource. Title 'Create Project' is slightly but not misleadingly narrower. Differentiates from siblings like get_project and list_projects by indicating mutation.

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 via 'Projects group related sessions and can auto-associate based on skill usage.' Context signals and siblings (get_project, list_projects) help clarify when to use. However, no explicit when-not-to or alternatives are mentioned.

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 covers important behaviors: export scope (session types), output format ('anthropic-memory-v1'), field mapping instability warning, and behavior of output_path (file or inline). No contradictions.

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 introduction, constraints, note, and Args list. Front-loaded with primary action. The note on field mapping is relevant but slightly lengthy; overall concise for the information provided.

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

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

Given no output schema, the description covers key aspects: format, filtering options, instability warning, and inline return behavior. Could mention return structure or size expectations, but sufficiently complete for a moderately complex 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%, but description explains all 4 parameters in the Args section, including purpose and behavior (e.g., session_ids overrides project). 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 states 'Export LoreConvo sessions to Anthropic managed-agents memory format' – a specific verb and resource, and distinguishes from siblings like 'export_sessions' by specifying the target format. The 'Pro only' restriction adds clarity.

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 constraints: 'Only non-periodic, non-file-memory sessions are exported' and notes field mapping instability. However, no explicit guidance on when to use this tool vs. alternatives like 'export_sessions' or 'import_sessions'.

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 export includes full detail (skills, tags, artifacts) and explains output_path behavior. However, it does not mention whether the operation is read-only, any authorization needs, or potential side effects. Basic behavioral context is present but lacks depth.

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: a purpose sentence followed by an Arg list. Every sentence adds value, and key information is front-loaded. No redundant or verbose phrasing.

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 6 parameters and no output schema or annotations, the description covers the core functionality, parameter semantics, and inline vs file behavior. It does not specify the structure of inline return data or error handling (e.g., file overwrite), but it is largely complete for the tool's 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?

Schema description coverage is 0%, but the description includes an Args section that explains each parameter (output_path, project, tags, days_back, limit, format) with context like default values and usage patterns. 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?

Clearly states the tool exports sessions to JSON/JSONL for backup/migration. The verb 'export' and resource 'sessions' are specific, and the purpose is well-understood. However, it does not explicitly differentiate from sibling tools like get_session or search_sessions, which limits a top score.

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 clear guidance on using import_sessions to load exported data, and explains the output_path behavior (file vs inline). It does not specify when not to use this tool versus alternatives, but the mention of an explicit alternative is helpful.

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 output structure (list of dicts with 'truncated' boolean), search behavior (FTS5, fan-out heuristic, potential truncation), and ordering (by recency). No annotations, so description fills the gap fully.

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

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

Two concise sections: general purpose/usage, then Args list. No redundant information. 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?

Covers output, parameters, and usage guidance. Minor gaps: no mention of error handling or the meaning of 'truncated' boolean beyond existence, but sufficient for a read 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?

Schema has 0% description coverage, but the description explains all three parameters in detail: topic (FTS5 behavior, truncation), limit (default 10, range 1-100), project (case-sensitive). Adds 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?

Clear verb 'retrieve' and specific resource 'sessions marked as anti-patterns'. Distinct from sibling tools like tag_as_anti_pattern (write) and search_sessions (general).

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?

States 'Use at session start or before attempting a known-tricky approach to surface past failures', providing concrete context. Does not explicitly exclude other uses or mention alternatives, but sufficient 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 exist, so the description carries full burden. It explains return value ('most relevant session excerpts'), parameter behaviors (semantic fallback, include_external filtering), and notes Pro-only feature. However, it does not disclose edge cases like empty results or if the tool modifies state (though it appears read-only).

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 brief and well-structured: a one-line summary, a usage recommendation, then a parameter list. Every sentence adds value, and the layout is easy to scan.

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

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

Given the 4 parameters and presence of an output schema, the description covers key aspects: purpose, when to use, parameter details, and return type. It lacks minor details like case-sensitivity or partial match behavior, but overall provides sufficient context for an AI 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?

Schema coverage is 0%, meaning all parameter meaning is provided by the description. Each parameter (topic, max_results, include_external, semantic) is clearly explained with examples, defaults, and behavioral details (e.g., semantic fallback). 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 clearly states the tool retrieves session context for a topic, with specific usage guidance at session start. However, it does not explicitly differentiate from sibling tools like get_related_sessions or get_docs_for_session, which share similar retrieval functions.

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 suggests using at session start to load prior context, but does not mention when to avoid this tool or direct users to alternatives. Usage context is implied rather than 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, the description carries full behavioral disclosure. It reveals that manual links are sorted first, auto-links with stale embeddings are marked with is_stale=True and include an upgrade_message. It also specifies the return dict structure. This is comprehensive for a read tool, though it doesn't mention permissions beyond the tier requirement.

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. The first sentence immediately states the core purpose. Subsequent details are organized logically with clear sections for arguments and return value. Every sentence adds value without unnecessary verbosity.

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

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

Despite no output schema, the description thoroughly explains the return dictionary with schema_version, cross_product_available, tier_gate, links, and reason. It also covers edge cases like free-tier behavior and stale embeddings. The agent has all necessary information 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?

The description adds significant meaning to both parameters: session_id is a LoreConvo session UUID, and limit is the max results with a default of 5. Since schema description coverage is 0%, the description fully compensates by providing clear semantics that the schema alone lacks.

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 that the tool returns LoreDocs documents cross-linked to a LoreConvo session. This is a specific verb+resource combination, and it distinguishes itself from siblings like 'get_session' by focusing on cross-linking. The purpose is immediately clear.

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 explicit usage context: Pro tier only, both LoreConvo and LoreDocs must be installed, and free-tier callers get an empty list. While it doesn't explicitly compare to sibling tools, the context is sufficient for an agent to know when this tool is applicable.

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 description explains entry fields and diagnostic purposes. Discloses fallback behavior (e.g., api_key_found=false). Lacks info on authentication or rate limiting details, but adequate given 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?

Well-structured with overview, entry fields, use cases, and parameter list. Every sentence is informative and no 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?

No output schema, but description explains output fields and usage. Covers all necessary 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 coverage is 0%, and description adds full meaning: explains each parameter, defaults, filtering by null, and ordering (newest first). Goes beyond schema 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?

Clearly states it returns recent consolidation log entries for transparency and diagnostics. Specific verb 'Return' and resource 'consolidation log entries' distinguish it from siblings like consolidate_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?

Explicit use cases provided: confirm consolidation ran, check rate limit status, diagnose fallbacks. Does not mention when not to use or alternatives, but clear enough for a diagnostic 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. Discloses that it returns None if no digest exists and that setting disable updates a flag. Does not cover error cases or side effects beyond the flag, but overall transparent about read and optional write 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?

Concise and well-structured: main purpose first, then return behavior, usage guidance, parameter explanation, and bulleted args. Every sentence adds value with no 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?

Explains return value and references sibling for generation. Covers the optional disable side-effect. Lacks error handling details (e.g., invalid project) and does not define 'auto-load injection', but sufficient for typical use.

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

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

Schema description coverage is 0%, but description explains each parameter: project as name, surface as filter, and disable with its three behaviors. Adds meaning beyond schema, though surface could be more specific.

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 what the tool does: 'Retrieve the current memory digest for a project without re-running consolidation.' It distinguishes from the sibling consolidate_memories by noting that this is a read-only retrieval that does not trigger consolidation.

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 'Use consolidate_memories first to generate one' if no digest exists. Also explains the three modes of the disable parameter. Could be more explicit about when not to use, but the guidance is clear and practical.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only says 'Get project details', implying a read operation, but doesn't confirm safety, side effects, or error conditions.

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

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

The description is concise with two sentences plus an args line. It front-loads the purpose. However, it could be more structured with explicit sections.

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 lack of output schema and 0% parameter coverage, the description is insufficient. It doesn't explain return structure, what constitutes 'recent sessions', or how skill usage stats are presented.

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 minimal value over the schema: 'project_name: The project identifier' is vague. Schema coverage is 0%, but the description fails to clarify format, examples, or possible values.

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

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

The description clearly states it retrieves project details, including recent sessions and skill usage stats. This distinguishes it from sibling tools like 'get_session' (single session) and 'get_stats' (general stats).

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 like 'list_projects' or 'get_session'. No conditions or exclusions mentioned.

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 states it retrieves summaries, implying a read operation, but does not explicitly confirm no side effects, mention auth requirements, rate limits, or data freshness. The description is too minimal to fully cover 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?

The description is structured with a purpose sentence, a usage sentence, and a bullet-like list of parameters. It is concise and front-loaded, though the 'Args:' line is slightly redundant. 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?

While an output schema exists (not shown), the description lacks details about result ordering, pagination, or what 'summaries' entail (e.g., which fields). This leaves uncertainty about the exact output, making it moderately complete but not fully self-contained.

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 lists all four parameters with clear, meaningful explanations: 'Max sessions to return,' 'How far back to look,' and filters for project/skill. This adds value beyond the schema's type definitions and defaults.

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

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

The description clearly states 'Get recent session summaries' with a specific verb and resource. It also mentions optional filters by project or skill, distinguishing it from siblings like get_session (single session) or search_sessions (comprehensive search). However, it could be more explicit about the scope (e.g., 'summaries' vs full details).

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

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

The description says 'Use to see what work was done recently,' which provides basic context but no guidance on when not to use it or alternatives. Siblings like search_sessions or get_related_sessions are not mentioned, leaving the agent to infer appropriate 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 fully discloses behavior: it explains co-occurrence vs embedding links, the sentinel for shared_term_count=0, ranking order, and response version signaling. This is comprehensive for a read-like tool.

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

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

The description is well-structured with a summary sentence, behavior explanation, and parameter list. Every sentence adds value, though it could be slightly more concise without losing 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?

Without an output schema, the description explains return format, ranking, and versioning. It lacks mention of error conditions or existence checks, but is otherwise thorough for the tool's 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?

The 'Args:' section provides detailed descriptions for all three parameters, including defaults and max for limit, even though the schema has no descriptions. This fully compensates for the 0% schema 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?

The description clearly states the tool finds sessions related to a given session using co-occurrence and embedding. It specifies the resource ('sessions related to a given session') and method, distinguishing it from siblings like 'get_session' or 'get_recent_sessions'.

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

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

The description mentions 'Pro only' as a constraint, but does not provide explicit guidance on when to use this tool versus alternatives like 'link_sessions' or 'search_sessions'. The usage context is implied but not fully 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 contradictions with missing annotations. Describes return values in detail and implies read-only behavior. Could note absence of side effects, but still 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?

Concise, front-loaded with main purpose, then lists return fields efficiently. 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?

Despite lacking an output schema, the description enumerates all return fields and their possible statuses, making it fully self-contained.

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?

No parameters exist (0 params), so baseline 4 applies. Description adds no parameter info, which is appropriate.

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

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

The description clearly states the tool returns MCP compatibility status for the LoreConvo server, listing all relevant fields. It distinguishes from sibling tools by focusing on server-level diagnostics rather than project or session data.

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 mentions it is useful for diagnosing version mismatches without restart, giving a clear use case. Does not explicitly exclude alternative scenarios, but the context 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 provided. The description only says 'Get full details' without disclosing whether the tool requires authentication, has side effects, or what 'full details' entails. For a read operation, more transparency about behavior is 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?

The description is concise, using two sentences that front-load the purpose. Every sentence is necessary and there is no extraneous 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 one parameter, no output schema, and no annotations, the description provides the essential purpose and parameter meaning. However, it fails to describe what 'full details' includes, and could be more complete for a specific session retrieval 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 description adds meaning beyond the schema by stating 'session_id: The UUID of the session to retrieve'. However, with 0% schema coverage, this is minimal. It does not describe format or constraints beyond the schema's type string.

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 'Get full details of a specific session', which is a specific verb-resource combination. It distinguishes from sibling tools like get_project or get_recent_sessions by targeting a specific session by ID.

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 such as get_recent_sessions or search_sessions. The description lacks context on prerequisites or typical use cases.

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

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

No annotations are provided, so the description must cover behavioral traits. It only states it returns sessions, but does not disclose read-only nature, permissions, pagination, or any side effects. Minimal behavioral insight.

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 sentences plus parameter documentation. Every word adds value. No redundancy or unnecessary text.

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

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

The tool has a simple purpose and an output schema exists, so the description does not need to detail return values. However, it omits potential edge cases (e.g., no matching skill) and ordering of results. Could be more complete.

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

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

With 0% schema description coverage, the description adds meaning to both parameters: provides an example for skill_name and explains days_back as 'how far back to search' with a default of 90. This is adequate but not exceptional.

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

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

The description clearly states the tool retrieves all sessions using a specific skill. The verb 'get' and resource 'sessions' are explicit. It distinguishes from sibling tools like 'get_recent_sessions' by focusing on skill-specific history.

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

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

The description provides a use case: 'useful for understanding how often a skill is used and in what contexts.' This gives context for when to use it, but it lacks explicit alternatives or when-not-to-use scenarios.

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 accurately describes the tool as read-only ('provides visibility'), and details the output structure. However, it does not explicitly state that no side effects occur, which would strengthen 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, with two focused sentences. The first sentence immediately states the return value and its composition, while the second adds context. No wasted words.

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

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

Given no output schema, the description adequately covers return values (session counts, storage, recent sessions) and dimensions (surface, project, tag). It could be improved by specifying how metrics are grouped or that data is aggregated. But for a simple stats tool, it is fairly 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 tool has zero parameters, and schema coverage is 100% (vacuously). The description adds value by explaining what the tool returns without needing to detail parameters. Baseline score of 4 is appropriate.

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

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

The description clearly states the tool returns a usage dashboard with specific metrics: session counts by surface/project/tag, storage metrics, and recent sessions. It effectively distinguishes itself from sibling tools like get_session and get_recent_sessions by focusing on aggregate statistics.

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 for gaining visibility into memory usage, but does not explicitly state when to use it versus alternatives like get_recent_sessions or get_server_info. No exclusions or prerequisites are mentioned.

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, but the description fully explains the tool's behavior: it returns a dict with specific keys. Though it implies a read-only operation, it does not explicitly state lack of side effects, but this is acceptable.

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: one sentence for purpose, one for usage, then a bulleted list for output. It is front-loaded and 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?

No output schema exists, but the description provides a detailed breakdown of the return dict. Combined with no parameters, the description is fully adequate for an agent to understand and 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?

The tool has zero parameters, and schema description coverage is 100% (empty). The description adds significant value by detailing the return dictionary structure, which is not present in the input 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 'Return the current LoreConvo license tier and status,' using a specific verb and resource. It distinguishes this tool from siblings like 'get_server_info' and 'vault_set_tier' by focusing on license details.

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

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

Provides explicit usage guidance: 'Use this to confirm whether the Pro license key is loaded and valid.' This tells the agent exactly when to invoke this tool, with no conflicting siblings.

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 that sessions are saved to the database, UUIDs are preserved, and dry_run prevents DB changes. It also explains the on_conflict behavior (skip/replace). This provides good transparency, though it lacks details on permissions or error handling.

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: a concise one-sentence summary followed by a brief paragraph and a clear bulleted Args list. Every sentence adds value with no 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?

Given the tool has 3 parameters and no output schema, the description covers the core functionality and parameters well. However, it does not describe the return value (e.g., success/error response), which would be useful for an import 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 fully. The Args section explains each parameter: file_path (path to file), on_conflict (options with default 'skip'), and dry_run (boolean). 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 explicitly states 'Import sessions from a LoreConvo export file (JSON or JSONL)'. It specifies the action (import), the resource (sessions from export), and the allowed formats, clearly distinguishing it from siblings like export_sessions.

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

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

The description notes that it reads exports created by export_sessions and saves to the local database, implying it is used after export. It also mentions that re-importing is safe due to UUID preservation. However, it does not explicitly state when not to use it or provide alternatives.

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

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

No annotations are provided. Description implies a read-only operation ('inspect') but does not explicitly state behavioral traits like no mutations or performance impacts. It provides reasonable context but could be more explicit about being non-destructive.

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 brief overview followed by a clear parameter list. It is slightly verbose but each sentence adds value. No wasted words, though could be more compact while retaining 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 7 parameters with no required fields and no output schema, the description adequately covers all parameters and usage scenarios. It explains return behavior for session_id and default limit. Missing mention of return format but acceptable for a list/detail tool.

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

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

Schema description coverage is 0%, but the description's 'Args' section adds full meaning to all 7 parameters, including details like 'Full-text search query across title, summary, decisions, tags' and 'Filter by tag substring.' This exceeds what the schema provides.

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's purpose: 'Inspect stored sessions: list, filter, or get full detail for one session.' It uses a specific verb ('inspect') and resource ('sessions') and differentiates from siblings like 'search_sessions' and 'get_session' by being a comprehensive browsing 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?

Description provides a clear use case ('Answers 'what do you know about me?'') and explains when to use each parameter (e.g., session_id for detail, search for query). However, it does not explicitly state when not to use this tool or mention alternatives among siblings.

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 only states that it links sessions, without revealing whether the operation is idempotent, requires permissions, overwrites existing links, or has side effects. The link_type values ('continues', 'related', 'supersedes') are listed but their semantics and impact are not explained.

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 one-line purpose followed by a clear parameter list. Every word is functional, with no redundancy or fluff. The structure is front-loaded and easy to scan, 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?

For a tool with 3 parameters, no output schema, and no annotations, the description is incomplete. It lacks context on what linking means (persistent? affects retrieval?), error handling (e.g., invalid IDs), and how this tool complements siblings like get_related_sessions or session_link_doc. The minimal description leaves the agent with significant uncertainty.

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. The 'Args:' section adds meaning beyond the schema: 'Source session ID', 'Target session ID', and 'Relationship type - continues, related, or supersedes'. This clarifies the parameters' roles. However, it does not explain constraints (e.g., circular links, duplicates) or provide examples.

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 'Link two related sessions,' clearly indicating the verb (Link) and resource (sessions). This distinguishes it from siblings like get_related_sessions (which retrieves links) and session_link_doc (which links sessions to documents). However, it does not specify what linking accomplishes functionally, such as whether it affects retrieval or is persistent.

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

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

The description provides no guidance on when to use this tool versus alternatives like get_related_sessions or session_link_doc. It does not mention prerequisites, limitations, or when not to use it. The sibling list is provided externally, but the description itself lacks explicit usage direction.

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

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

No annotations provided, so description carries the burden. It correctly implies a read operation and discloses the output includes session counts, but does not mention auth, rate limits, or ordering. Acceptable for a simple list tool.

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

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

Single, succinct sentence with no wasted words. Front-loaded with action and resource. Every word is purposeful.

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 (0 params, no annotations, but has output schema), the description fully conveys what the tool does. No additional context needed.

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?

No parameters in the schema, so description adds no param info. It implicitly confirms no filtering or arguments are needed (lists all). Baseline for 0-param tools is 4.

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

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

The description clearly states the action ('List'), the resource ('all defined projects'), and includes a specific detail ('with session counts'), distinguishing it from siblings like get_project (single project) and 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?

The description states it lists all projects, but provides no explicit guidance on when to use this vs alternatives like get_project or search_sessions. For a simple list tool, this is minimally adequate.

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 details what is created (project registrations, config file, reference doc) and explains the response includes a markdown doc to paste. Also clarifies surface and agent identity usage.

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 purpose first, then bullet points for outputs and args. Slightly verbose but each sentence adds value. Front-loaded with key call instructions.

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?

No output schema, but description explains the reference doc response. Covers all aspects: when to call, what it creates, args, surface field guidance. Complete for a setup 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 description must add meaning for all parameters. It does so: name (workspace/team name), projects (snake_case identifiers), agents (agent names), tag_style (simple vs detailed with explanation). Provides full semantics.

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 sets up or updates LoreConvo workspace configuration. It distinguishes from sibling tools by specifying it's called once after install and again for updates, listing specific outputs like project registrations and config 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?

Explicitly says when to call (once after install, again for updates) and provides guidance on surface field and agent identity. Lacks explicit when-not conditions or alternatives, but context from siblings makes usage clear.

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 all behavioral traits. It explains that pinning atomically clears expires_at and unpinning removes the pin. It lists error codes, but does not mention auth requirements or rate limits.

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, uses bullet points for parameter details and return values, and front-loads the core purpose. Every sentence is necessary.

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 absence of annotations and output schema, the description covers behavior, parameters, and error codes well. It could mention potential limits (e.g., maximum pinned sessions) 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 coverage is 0%, so the description fully compensates. It explains the meaning and effects of keep_forever (default true, clears expiry atomically) and implicitly covers session_id as required.

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 verb ('pin or unpin') and resource ('session'), with a specific purpose: to exclude from automated cleanup. This distinguishes it from sibling tools like set_session_expiry.

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 each value of keep_forever, providing clear context for usage. However, it does not explicitly contrast with sibling tools or state when not to use.

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 covers behavioral expectations. It discloses that it downloads BAAI/bge-small-en-v1.5 (~130MB) on first run, caches the model for subsequent runs, and may take 1-2 minutes for large session stores. It also states the return format, a dict with 'indexed' and 'total_in_db' keys. This is comprehensive and avoids surprises.

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. It leads with the main purpose, then provides usage context and behavioral details in separate short paragraphs. Every sentence adds value, and there is 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 the tool has no parameters and no output schema, the description provides all necessary information. It explains the purpose, when to use, side effects (model download, time estimate), and return value. The description is complete for an agent to select and invoke this 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 tool has zero parameters, and the schema coverage is 100%. Per guidelines, the baseline score is 4 since no additional parameter description is needed. The description briefly mentions output format, which is helpful but not required for parameter semantics.

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: 'Rebuild the LanceDB semantic search index from all stored sessions.' It specifies the resource (LanceDB semantic search index) and the action (rebuild). It also distinguishes the tool by noting it is 'Pro only' and providing specific use cases (first Pro activation, recovery from corrupted index), setting it apart from sibling tools.

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

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

The description provides explicit guidance on when to use the tool: 'Run after first Pro activation, or to recover from a corrupted index.' It also mentions the model download and caching behavior, giving the agent a clear understanding of when invocation is appropriate. While it doesn't list alternatives, the context of sibling tools makes the intended use clear.

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: persistent memory storage, deduplication via session_id, update behavior preserving artifacts, exclusion of external tool sessions from auto-load/search, and opt-in summarization via Claude API. All key behavioral aspects are covered.

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 fairly long but well-structured with a brief intro, usage trigger, and detailed parameter list. Each sentence adds value; minor redundancy could be trimmed (e.g., the session_id explanation is somewhat verbose), 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 15 parameters, 3 required, no output schema, the description covers all parameters and behavioral nuances including deduplication, update semantics, exclusion logic, and summarization. It is complete for a save operation with no 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 has 0% description coverage, so the parameter descriptions carry full burden. Each of the 15 parameters is explained with purpose, defaults, and behavioral nuance (e.g., session_id deduplication, external_tool_session exclusion, summarize opt-in). This significantly 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 'Save a session summary to persistent memory' with a specific verb and resource. It mentions when to call (end of session or /bridge save), but does not explicitly differentiate from sibling tools like consolidate_memories or import_sessions, though the purpose is distinct.

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 explicit usage context: 'Call this at the end of a session or when the user requests /bridge save.' It does not specify when not to use or mention alternatives, but the trigger is clear and sufficient for most scenarios.

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 important behaviors: default exclusion of expired and external sessions, fallback mechanism for semantic search, and global env variable for external tool inclusion. No contradictions.

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 a brief intro, usage guidance, and parameter list. Though slightly lengthy, every sentence adds value. Could trim redundant phrasing (e.g., 'Use to find...' repeated).

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 (no need to explain returns), all 9 parameters are explained, behavioral nuances are covered, and sibling context is provided. No gaps identified.

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 explains each parameter (query, persona, tags, skills, project, limit, include_external, semantic, include_expired) with details like prefix matching, default values, and conditions (e.g., 'Pro tier only').

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 'Search session memory by keyword, with optional filters,' with a specific verb and resource. It distinguishes itself from sibling tools like 'get_session' or 'get_recent_sessions' by focusing on keyword search with filters.

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 use cases ('when a topic was discussed, a decision was made, or a specific skill/project was involved') but does not explicitly contrast with sibling tools like 'get_related_sessions' or 'inspect_sessions'.

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 reveals that the tool creates a link (a write operation) and returns an ok/reason dict, but it lacks information about side effects, idempotency, permissions, or rate limits. The failure reason is noted as 'generic; details in debug log', which is only moderately 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 concise (about 100 words), well-structured with a clear action statement, constraints list, parameter documentation, and return value description. Every sentence adds value, and the bulleted args/rets improve readability.

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 (3 string params, no output schema), the description covers the core action, constraints, parameters, and return values. It lacks examples, error handling details, and mention of uniqueness/duplication behavior, but overall 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?

The input schema has 0% coverage (no descriptions), so the description must compensate. It does so by explaining each parameter's purpose (e.g., 'session_id -- LoreConvo session UUID'), adding meaning beyond the raw schema. However, it could provide more detail (e.g., format constraints or examples).

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 (create a manual cross-product link from a LoreConvo session to a LoreDocs doc), distinguishing it from sibling tools like link_sessions (which links sessions together) or get_docs_for_session (which retrieves existing links).

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 context ('manual cross-product link', 'accessible on all tiers') and lists prerequisites (target doc not in opt-out vault, both products installed). However, it does not explicitly state when not to use this tool or mention alternatives, leaving some room for improvement.

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 behavioral disclosure. It explains that expired sessions are excluded from certain tools but not deleted, and that clearing expiry is possible via None. This covers key side effects, though it omits potential error behaviors (e.g., non-existent session).

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. It opens with a one-line purpose, follows with behavioral details in paragraph form, and ends with argument descriptions. Every sentence contributes useful 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?

Given the lack of output schema, the description sufficiently covers return behavior (no deletion, recovery option) and impact on other tools. It could be improved by mentioning error handling for invalid inputs, but overall it is complete for a simple mutation tool.

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

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

The schema coverage is 0%, requiring the description to fully explain parameters. It does so effectively: session_id is described as 'ID of the session to update,' and expires_at includes format guidance ('ISO 8601 date string') and the special value None. This significantly adds 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 'Set or clear an expiry date on a session,' specifying a precise verb and resource. It distinguishes itself from sibling tools like get_session or save_session by focusing solely on expiry management.

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 (setting or clearing expiry) and provides context on consequences (exclusion from searches, recovery). It offers clear usage details but does not explicitly exclude alternative scenarios or 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?

With no annotations, the description provides idempotency and notes that the reason is stored in audit log. However, it does not disclose side effects, permissions, or error handling beyond 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: a one-sentence summary followed by a compact arg list. No redundant information, every line is useful.

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 no output schema, the description covers the action, idempotency, and parameters but omits details like return value, error cases, or what happens if session_id is invalid. This is a minor gap.

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

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

Schema has 0% description coverage, so the description fully compensates by explaining each parameter: session_id (constraint), source (example), reason (purpose and storage). This is thorough for a 3-parameter tool.

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

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

The description clearly states the purpose: 'Mark an existing session as an anti-pattern.' This is specific and distinguishes it from general tagging tools like 'tag_session', though it does not explicitly contrast with siblings.

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

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

No guidance on when to use this tool versus alternatives such as 'tag_session' or 'untag_anti_pattern'. The description does not mention context, prerequisites, or exclusions.

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

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

With no annotations provided, the description carries the full burden. It mentions hierarchical persona matching but does not disclose whether tagging is additive or overwrites, the impact on existing tags, or any required permissions. The behavioral traits are minimally described.

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

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

The description is concise, with a clear purpose statement followed by bulleted parameter explanations. No redundant or unnecessary 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?

The description covers purpose and parameters, and mentions hierarchical personas. However, it lacks information about return values, error handling, idempotency, or behavior when tagging an already-tagged session. Given the absence of annotations and output schema, these gaps reduce 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 description includes an Args section that adds meaning beyond the schema: explains session_id as 'Session to tag', persona_name with examples, and relevance_note as optional. This significantly compensates for the schema's lack of descriptions (0% coverage in context signals).

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: 'Tag a session with a persona for filtered recall.' It uses a specific verb (tag) and resource (session with persona), distinguishing it from siblings like pin_session or tag_as_anti_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?

The description implies usage for 'filtered recall' but does not explicitly state when to use this tool versus alternatives such as pin_session or tag_as_anti_pattern. No when-not-to-use conditions or exclusions are provided.

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

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

No annotations are provided, but the description fully discloses idempotency and audit log behavior (log written on success, not on no-op). This covers the main behavioral aspects.

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, well-structured with clear sections, and every sentence adds value. No wasted words.

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

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

Given no output schema and no annotations, the description is self-contained. It explains idempotency, audit log, and all parameters, providing complete context for invocation.

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

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

With 0% schema description coverage, the description fully explains each parameter: session_id as a sessions.id, source as attribution, reason as human-readable. This adds essential 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 verb 'untag' clearly indicates removal, and 'anti-pattern' specifies the tag type. It directly distinguishes from sibling tools like 'tag_as_anti_pattern' and 'tag_session'.

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

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

The description implies use when removing an anti-pattern tag, and idempotency indicates it's safe to call multiple times. However, it doesn't explicitly state when to use or not use alternatives.

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

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

Discloses beyond annotations: Pro removes session limit, free re-enables limits preserving existing sessions, and env var prerequisite. No contradiction with annotations (idempotent, non-destructive).

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: first sentence defines purpose, then specific details. No redundant 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?

Covers purpose, usage, prerequisites, effects, and idempotency. Output schema exists for return values, so complete for this simple 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?

Adds meaning to the single parameter 'tier' by explaining consequences of each value (pro removes limit, free re-enables). Schema description only says 'Tier to activate: free or pro', so tool description adds 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?

Clearly states the tool activates a tier (free or pro) for LoreConvo, with specific effects for each tier. Distinguishes from sibling get_tier (read-only).

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 steps: after purchasing Pro license, set env var, restart server, then call with tier='pro'. Also explains reverting to free. Lacks explicit 'when not to use' but context is clear.

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

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

With no annotations, the description must fully disclose behavior. It explains the output categories and parameters but fails to state whether the tool is read-only, has side effects, or performance implications. The description is adequate but lacks depth on behavioral traits.

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 concise first sentence, bulleted output categories, usage guidance, and a parameter list. It is front-loaded and every sentence contributes 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?

The description covers the tool's purpose, usage, and parameter details. While it lacks an output schema, it explains what the tool surfaces. It is largely complete but could benefit from mentioning the return format or data structure for clarity.

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, but the description provides clear, contextual explanations for all four parameters, including default values for days_back and limit and prefix matching for persona. This fully compensates for the schema gap and adds significant meaning.

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

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

The description clearly states the tool provides proactive context suggestions from session history, listing specific categories like unresolved questions and skill gaps. It uses the verb 'Get' and resource 'context suggestions', but does not explicitly differentiate from siblings like get_context_for or get_related_sessions, leaving some ambiguity.

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 advises using the tool at the start of a session or when unsure what to work on next. However, it does not mention when not to use it or suggest alternative tools for specific needs, such as searching for individual sessions.

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