Metis
Server Quality Checklist
Latest release: v0.1.4
- Disambiguation2/5
With 196 tools, many have overlapping purposes, such as multiple search tools (search_library, search_literature, search_fulltext, search_pdf_knowledge, semantic_search) and memory tools (store_episodic_memory, store_semantic_memory, store_procedural_memory, add_memory_entry). An agent would struggle to distinguish between them without deep understanding of subtle differences.
Naming Consistency3/5All tool names use snake_case consistently, but verb patterns vary widely (add_, create_, store_, capture_, save_, record_, log_, write_). Some names are verbose or include prepositions, making the pattern less predictable.
Tool Count1/5196 tools is far beyond typical scope (3-15). This massive number indicates poor modularity and likely many redundant or overly specialized tools, overwhelming both the agent and the context window.
Completeness4/5The tool set covers an impressively broad range of research activities: projects, tasks, memory, literature, data cleaning, DHIS2, brainstorming, etc. Minor gaps exist (e.g., no dedicated tool for updating project description), but overall the surface is quite complete.
Average 4.2/5 across 196 of 196 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 190 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states it adds a topic but does not mention whether duplicates are allowed (despite hinting at 'unique' in param doc), what side effects occur (e.g., triggers notifications), or what happens if the topic already exists. This lack of behavioral detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the purpose, but it uses Python docstring style with 'Args:' which is unnecessary for JSON. It is concise but could be more efficiently structured without the docstring formatting, potentially adding a return description or behavior note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown) and low complexity (2 params, no enums), the description is incomplete. It does not explain the return value, error conditions (e.g., duplicate topic), or the lifecycle of added topics. The tool's purpose is clear but operational details are missing for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add value. It only repeats parameter names with minimal context ('topic: Topic name (unique)', 'description: Optional description...'). The schema already contains required/default info; the description does not explain formats, constraints, or usage examples, adding little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add a topic to track for new publications.' It uses a specific verb ('Add') and resource ('topic'), and distinguishes from similar sibling tools like add_glossary_term or add_memory_entry by specifying the context of tracking new publications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., search or list tools). There is no mention of prerequisites, usage context, or when not to use it. The description is purely operational without contextual decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits such as side effects, permissions needed, or reversibility. It only says 'restore to active status' without warning about potential impacts on files, connections, or other projects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no redundant words. However, it is so brief that it sacrifices completeness for brevity, which may leave gaps in understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (unseen) and the simplicity of the tool, the description still lacks information about return values, error cases, and its relationship to sibling tools like 'archive_project'. It is too minimal for complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 parameter 'project_id' is described only as 'The project_id to restore', which adds minimal meaning over the schema's 'Project Id'. No format, source, or validation hints are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Restore') and the resource ('archived project'), making the tool's purpose unambiguous and easily distinguishable from sibling tools like 'archive_project' or 'remove_project'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no prerequisites, and no mention of when not to use it. It only states what it does, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It discloses use of local embeddings and no API key, and explains the force_rebuild parameter. However, it omits whether the tool creates databases, the scope of files indexed, potential resource usage, or side effects on existing data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured. Begins with core purpose, then model details, layer examples, and a clear Args block. No filler sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are not needed. However, important context is missing: how PDFs are associated with a database, whether the database must exist beforehand, and any time/resource implications. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0% but description compensates well: explains 'database' as a slug with defaults and examples, and 'force_rebuild' as re-indexing already indexed files. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it indexes a knowledge database layer from PDFs, using a local embedding model. It provides examples of database slugs and links to create_knowledge_database(), but does not explicitly differentiate from sibling tools like index_library_pdfs or index_pdf_library.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The mention of local model implies offline use, but there is no comparison to alternatives or prerequisites for custom databases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not state that this is a read-only operation, does not mention idempotency, rate limits, or the definition of 'recent'. Only states it returns a JSON array of span objects with a default limit of 50.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a clear purpose statement, structured Args block, and a brief return note. No unnecessary sentences or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 optional parameters and an output schema, the description covers parameter semantics and return type. However, it lacks explanation of what a 'span' is, how 'recent' is defined, and any behavioral context like sorted order or pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 0%, the description adds meaningful interpretations for all three parameters: session_id filters by session, run_id filters by run, limit sets max rows with default 50. This 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Fetch' and resource 'spans', with optional filters. It hints at recency but doesn't define it, and no explicit differentiation from sibling span tools like start_span or log_span, but the read intent is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 get_agent_runs or other get_* tools. It mentions optional filters but doesn't specify scenarios where filtering by session vs run is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions merge behavior but omits important details: idempotency, error handling, authentication needs, return value. Output schema exists but description doesn't reference it or clarify what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Brief two-paragraph structure: purpose sentence, merge explanation, then args list. No wasted words. The args section could be integrated more seamlessly but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description is adequate but not thorough. It explains the merge behavior and gives key examples, but lacks error handling, format spec, or return value description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description adds value by listing example preference keys (news_topics, journals, etc.). However, it does not specify required JSON format (e.g., escaping, allowed types), leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it writes user-preferences.json produced by the first-run config wizard. Specifies merge behavior to avoid overwriting earlier sections. Does not explicitly differentiate from sibling tool write_user_config, which might have overlapping purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes use case (first-run config wizard, incremental saves) but provides no guidance on when not to use it or alternatives like write_user_config. Lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'retrieve a stored daily insight' but does not clarify side effects (likely none), error handling for missing dates, or whether it is read-only. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single purpose sentence plus a parameter definition. Every sentence is essential, and the structure front-loads the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple retrieval tool with an output schema, the description is largely adequate. However, it could be more complete by noting that the insight must exist for the date, or what happens if it doesn't. Still, it covers the core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by documenting the 'date' parameter with format and default behavior ('Empty = today'). This adds meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Retrieve a stored daily insight' which clearly identifies the verb and resource. However, it does not explicitly differentiate from the sibling tool 'generate_daily_insight', though the distinction is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'generate_daily_insight' or other retrieval tools. Prerequisites (e.g., insight must exist) are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not state whether the tool is read-only, has side effects, or any behavioral constraints. Minimal information beyond the basic listing action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus parameter doc. No wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema, the description adequately covers the return fields and parameter. Could mention what 'recent' means or edge cases (e.g., empty list), but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining the 'limit' parameter (maximum sessions, default 20). This adds meaningful context beyond the schema's type/default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'brainstorm sessions', and specifies the fields returned (title, turn count, status). It distinguishes from siblings like 'get_brainstorm_session' but doesn't explicitly differentiate from 'list_recent_sessions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_recent_sessions' or 'get_brainstorm_session'. Lacks context on prerequisites or filtering scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It explains the parameters but does not disclose potential side effects (e.g., overwrite behavior, idempotency, auth requirements). For a write operation, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with minimal redundancy. It front-loads the purpose and uses a clear args list. No unnecessary sentences, though structuring could be slightly improved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basics for a store operation, but lacks details on output (though output schema exists), error behavior, and constraints like uniqueness. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates well. It adds examples, specifies Markdown format for steps, and clarifies the trigger context purpose. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stores a successful workflow pattern in procedural memory and explains what procedural memory means. However, it does not explicitly differentiate from sibling tools store_episodic_memory or store_semantic_memory, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (for repeatable processes, workflows that worked well) but lacks explicit guidance on when not to use or how it differs from alternative memory stores. No contrast with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It mentions that 'name must exist in specialist_contexts' but does not disclose side effects (e.g., whether toggling is idempotent, what happens if already active, or any impact on ongoing sessions).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one line for purpose and a bulleted list for arguments. It is appropriately front-loaded with the action. No superfluous words, though the args section could be integrated more naturally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the description fails to mention return values, error conditions, or the overall effect of toggling. For a simple toggle tool, the description is incomplete; it does not convey what happens after activation/deactivation (e.g., context becomes available/unavailable).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since input schema descriptions are missing (0% coverage), the description adds meaning: it clarifies 'name' as 'Context name to toggle (must exist in specialist_contexts)' and 'active' as 'True to activate, False to deactivate.' This provides necessary constraints and meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's action: 'Activate or deactivate a specialist context.' The verb 'toggle' is clear, and the resource 'specialist context' is specific. It distinguishes from sibling tools like 'add_specialist_context' (which creates new contexts) and 'get_context' (which reads state).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'add_specialist_context' or 'get_context'. There is no discussion of prerequisites, such as the need for the context to exist, nor any mention of when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks details on data handling (e.g., whether content is stored or modified), leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and front-loaded with main action; Args section is somewhat redundant but acceptable given schema lacks descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists and description mentions return values; parameter coverage is adequate but not comprehensive; no edge cases or prerequisites noted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description provides one-line explanations for each parameter but adds limited additional value beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool scans content for PII patterns and classifies sensitivity level, distinguishing it from related tools like anonymize_text or redact_data_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when or when not to use this tool compared to siblings like anonymize_text; usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavioral traits. It does not mention idempotency, error handling on existing project, permissions, or side effects beyond creation. The listing of integrations is informative but insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two short sentences plus a clean arg list. All content adds value without redundancy. Front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return value is covered. However, with 6 parameters and no behavioral context (e.g., overwrite behavior, folder requirements), the description lacks completeness for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), so the description carries the full burden. Each parameter has a concise explanation, with useful details like auto-detection for description and scan_type options. Title explanation is minimal but acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it creates a project with full Metis integration including DB record, CLAUDE.md, and Claude Desktop. It also notes it is the unified tool used by installers and dashboard, but does not explicitly differentiate from sibling 'create_project'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes intended use as the unified project creation tool, implying it is the standard path. However, no explicit guidance on when to use alternatives (e.g., simpler create_project) or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation ('Return') with no side effects, which is transparent for a simple list. However, it does not clarify what 'active' means, or whether results are paginated or sorted. Without annotations, more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is minimally adequate. However, it could benefit from explaining what 'active' means or providing an example of the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides complete coverage. The description adds no parameter information, but none is needed. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('active topics from user_topics'), making the tool's purpose clear. However, it does not differentiate from sibling tools like add_user_topic or get_topic_memory, limiting its distinctiveness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only discloses one behavioral trait (refuses private items). Missing details such as permissions, reversibility, and overwrite behavior, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences plus arg list, front-loaded with the action verb, and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and 0% schema coverage, the description provides the core action and a key constraint. However, it lacks details on error handling, return values, and collision behavior, assuming the output schema covers return. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds clear meaning beyond schema titles: defines source as 'absolute path to the file in basket/' and target as 'absolute destination path (file or folder).' This compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('move') and the resource ('basket item to stable project folder'). It differentiates from sibling tools like list_basket and scan_folder_for_intent by focusing on promotion, but does not explicitly distinguish itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that it refuses to touch basket/private/ items, providing a usage constraint. However, it does not specify when to use this tool over alternatives or give explicit prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It does not explicitly state that the tool is read-only, nor does it mention side effects, authentication needs, or rate limits. The focus is on parameter behavior rather than operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and uses a structured list for arguments, making it easy to parse. However, the initial sentence could be more front-loaded with the tool's primary function before diving into details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description appropriately focuses on input behavior and search scope. It covers defaults, field targets, and the archive toggle, which is adequate for a search tool of moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides clear, meaningful explanations for all three parameters (query, include_archived, limit), adding value since the input schema has 0% coverage. Default values and meanings are well articulated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches literature across specific fields (basename, disease, etc.) and allows inclusion of archived items. However, it does not explicitly distinguish from its likely sibling search_literature, leaving the 'extended' aspect somewhat inferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions default exclusion of archived items and the include_archived parameter, providing basic usage context. But it offers no guidance on when to prefer this tool over alternatives like search_literature or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
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 states 'adjust the feature-tips preference' without describing persistence, side effects, or response behavior. Agent has no insight into what happens after execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: a single line for purpose followed by three lines for parameters. Front-loaded with purpose. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple preferences tool, parameter descriptions are adequate. However, lacks information about output format or return value (output schema exists but unused), and whether changes take effect immediately or require confirmation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description is the sole source of parameter meaning. It adds clear, actionable explanations for each parameter: enabled (turn on/off), power_user (expert vs guided mode), snooze_days (snooze for N days). Significantly enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it adjusts the feature-tips preference, using a specific verb ('adjust') and resource ('feature-tips preference'). This distinguishes it from sibling tools like 'next_discovery_tip' (shows tip) and 'discovery_status' (gets status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Does not mention prerequisites, exclusions, or when not to use it. Agents must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only states that the tool retrieves data without any details on side effects, permissions, or data size limits. The description is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy. It is appropriately concise, though slightly sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no parameters and an output schema present, the description is sufficient. It explains the core action, but lacks additional context about data freshness or ordering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the description does not need to add parameter meaning. Baseline for no parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' and resource 'contacts from the contacts table', clearly indicating the action and scope. It distinguishes itself from sibling tools by precisely naming the data source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_memory' or 'search_library'. There is no mention of prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 adequately describes the read operation but does not disclose potential side effects, permissions, or rate limits. It is clear but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-sentence purpose followed by a clean bullet-list of parameter details. No extraneous information or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (no need to describe return values) and 4 parameters, the description adequately covers parameter usage. It misses typical use cases or examples, but is sufficient for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose, default values, and allowed values (e.g., 'news' vs 'article' for source_type). It adds meaning beyond the schema's raw title fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve recent news briefs from the database' with a specific verb and resource. However, it does not explicitly distinguish from sibling tools like 'scan_news' or 'get_new_publications', which could cause ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., scan_news for RSS, search_literature for articles). There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states the action without disclosing side effects, limitations (e.g., recursion, size limits), permissions, or read-only nature. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with a clear purpose statement. The 'Args' section is minimal and directly adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool purpose and the existence of an output schema, the description covers input parameters adequately. However, it lacks behavioral details like recursion behavior, but is otherwise complete for a basic file-listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides explicit descriptions for both parameters (folder_path and pattern), including the pattern format with examples. This adds meaningful context beyond the schema's default value and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List files in a folder' with a specific verb and resource. Among many sibling tools like list_backups or list_basket, list_folder is distinct in its purpose of listing files in a file system folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. No exclusions, prerequisites, or context for when it is appropriate to call list_folder over other listing or scanning tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides one behavioral insight: deduplication by URL makes repeated runs safe. However, it omits details like authentication requirements, failure handling, or whether it appends or overwrites existing items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, 57 words, front-loaded with the core action. Each sentence serves a purpose: main action, sources, and safety behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and presence of output schema, the description is largely complete. It explains the action, sources, and idempotency. The only minor gap is lack of detail on output structure, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so baseline is 4. The description adds no parameter-specific info but explains the tool's purpose effectively, which compensates for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch RSS feeds and add new items to news_briefs') and lists specific sources, but does not explicitly differentiate from sibling tools like 'get_news_briefs' or other scanning tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'scan_literature' or 'scan_pubmed_alerts'. The description only covers functionality, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions recall in future sessions, implying persistence, but does not address side effects, mutability, authorization needs, or error behavior. This is a significant gap given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, followed by parameter details. It is concise without fluff, though the parameter list is somewhat lengthy. Front-loading the purpose aids quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are covered. The description explains what the tool does and its parameters adequately. However, it lacks details on error handling, rate limits, or required permissions, leaving some context gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose, expected format (e.g., content: 1–3 sentences), and default behavior (e.g., concepts auto-extracted). This adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records typed observations during an agent run, with specific observation types (discovery, decision, etc.) and the purpose of enabling recall in future sessions. This distinguishes it from sibling tools like add_memory_entry or add_journal_entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It advises using the tool throughout a run to capture learning, but does not explicitly state when not to use it or suggest alternatives like add_memory_entry or add_journal_entry. The guidance is implied but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 only describes the search action and does not mention any side effects, rate limits, pagination, or limitations. The read-only nature is implied but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. The separate 'Args' section for parameters is well-structured. Every sentence contributes meaning, though the examples could be slightly more integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic functionality and parameter semantics. Since an output schema is present, the lack of return value explanation is acceptable. However, it does not address edge cases like empty results or multiple matches, leaving some gaps for a simple search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the 'Args' section in the description adds meaningful descriptions for all three parameters (e.g., 'What you're looking for.' for query). These add value beyond the schema's titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the Code Repository for code, variables, and treatments, with concrete examples ('Poisson model offset'). It distinguishes from sibling search tools by specifying the unique resource (Code Repository).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its purpose and examples but does not explicitly state when to use this tool over alternatives like search_fulltext or search_literature. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It describes the merge behavior and preservation of specialist_contexts and active_contexts, but does not mention permissions, error handling, side effects, or what happens if the config does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an Args section, efficiently conveying purpose and key behavior. It is front-loaded with the main action. Could be slightly more structured, but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema exists, the description covers the core functionality and parameter meaning. However, it lacks context about prerequisites (e.g., wizard must have run) and does not differentiate usage from similar write tools like write_user_preferences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the parameter. The description's Args section adds meaning by specifying that yaml_content should be 'Complete YAML string as produced by the wizard (all sections)', but does not provide format constraints, size limits, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Write' and the resource 'the full user-config.yaml produced by the first-run config wizard'. It distinguishes from siblings like 'get_user_config' (read) and 'write_user_preferences' (partial write) by specifying it writes the complete config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used after the first-run config wizard and mentions merging behavior, but does not explicitly state when to use this tool versus alternatives like 'write_user_preferences' or provide any when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes auto-extraction of mood and energy, but lacks details on side effects, idempotency, required permissions, or what the return value contains (output schema exists but not discussed).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words, efficiently conveying the tool's purpose and parameters in two lines plus an Args list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the core function, it omits behavioral details like constraints on content length, persistence behavior, or post-storage results. Given the tool's simplicity, it is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description provides succinct but clear explanations for both parameters (content text, optional image path), adding value beyond the schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stores a journal entry with auto-extracted mood and energy, distinguishing it from sibling add_* tools like add_memory_entry or add_glossary_term.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., add_memory_entry or other logging tools). There is no mention of prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that it registers a database layer and that indexing requires a separate step. Does not mention idempotency, error behavior, or if overwriting occurs on duplicate slug. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Brief description followed by usage tip then parameter list. Each sentence adds value. Could be slightly more compact, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, and follow-up steps. Has output schema (not shown) so return values are handled. Missing error handling or behavior on duplicate slugs. Adequate for a creation tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description provides detailed explanations for all 5 parameters. Explains slug as URL-safe identifier, layer as 4+ for custom, folders with example. Adds value beyond basic type info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Register' and resource 'custom knowledge database layer'. Distinguishes from siblings like build_pdf_knowledge_db which is a follow-up step, but not explicitly compared to other create tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides sequential workflow: create, then add PDFs, then call build_pdf_knowledge_db. Explains layer numbering (4+ custom). Does not specify when not to use or alternatives, but gives practical context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description relies on 'Retrieve' to imply read-only behavior. It does not disclose any side effects, idempotency, or failure conditions, which is minimal for a retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, including a structured args section. Every sentence serves a purpose with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description sufficiently covers retrieval and parameter purpose. No additional content needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description explicitly explains 'session_uuid' as 'The session identifier returned by brainstorm_turn()', adding source context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' and resource 'all turns in a brainstorm session', clearly distinguishing it from siblings like 'brainstorm_turn' which creates turns, and 'list_brainstorm_sessions' which lists sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'brainstorm_turn' or 'list_brainstorm_sessions'. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It states ordering and filtering but does not mention side effects, safety (read-only assumption), pagination, or limits. The read-only nature is not explicitly stated, and potential size of returned data is omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an args listing, with the main action front-loaded. Every word contributes essential information, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description is mostly adequate. However, it lacks context on what constitutes a 'memory entry' (e.g., fields included) and how this tool differs from other memory retrieval tools, which is relevant due to many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'topic' has 0% schema description coverage. The description adds a clear explanation and concrete examples (e.g., 'metis-setup', 'phd-research'), which compensates well. Could be improved by specifying allowed characters or format, but it suffices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Return' and the resource 'memory entries tagged with a specific topic', with ordering 'newest first'. This distinctively identifies its function among siblings like search_memory or list_recent_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the description (use when you need all entries for a topic, newest first), but there is no explicit guidance on when not to use or alternatives. The description does not differentiate from similar tools like search_memory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action and result (list contexts with active status) but does not disclose that this is a read-only, idempotent operation, or any potential side effects, rate limits, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 8 words, front-loading the key information. Every word is purposeful with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a zero-parameter tool with an output schema, the description is complete. It states the action and the result (list all contexts with active status), which is sufficient for an agent to understand invocation and basic expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so baseline is 4. Description correctly implies no parameters are needed and adds no superfluous parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'List' and the resource 'user contexts', specifying both general and specialist types and that active status is included. This distinguishes it from sibling tools like 'get_context' or 'toggle_context' by implying a full listing rather than a single context or toggling action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of when not to use it or when to prefer sibling tools like 'get_context' or 'toggle_context'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the entire burden. It states 'Load every tool' but does not explain what 'load' entails (e.g., side effects, resource usage, reversibility). This is insufficient for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both essential. The first sentence states the core action, the second provides usage guidance and examples. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema (not shown), the description is minimally complete. It covers purpose and usage, but lacks details on what happens after loading. Adequate but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 describes the 'group' parameter as a 'named group' and points to list_tool_groups for possible values, but does not specify format or constraints. Adequate but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Load every tool in a named group at once') and provides concrete examples (group 'data', 'specialist'). It references sibling tool 'list_tool_groups' for finding group names, aiding differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises use for multiple related operations and gives concrete example scenarios. It does not explicitly state when not to use, but the context and reference to list_tool_groups provide sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the burden of behavioral disclosure. It transparently states side effects: writes a file to 'outputs/brainstorms/' and updates the 'brainstorm_sessions' table status to 'saved'. This is good, though it could mention if the operation is idempotent or destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It front-loads the main action, then lists side effects, and finally documents parameters in a clear list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and an output schema (not shown), the description adequately covers the tool's behavior, side effects, and parameter semantics. It does not explain return values, but the output schema likely covers that. The side effects (file write, table update) are explicitly stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 adds brief descriptions for all four parameters (e.g., 'The session identifier', 'Short descriptive title'). These add meaning beyond the raw schema, though they are minimal. The baseline for low coverage is higher, so a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to save/freeze a brainstorm session as Markdown output. It specifies the action ('Freeze') and the resource ('brainstorm session'). While it distinguishes from siblings like 'brainstorm_turn' by focusing on final saving, it does not explicitly differentiate itself from other related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternative tools (e.g., 'brainstorm_turn' for ongoing sessions, 'get_brainstorm_session' for retrieval). It lacks context on prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It describes search, ranking, and formatting behavior, but does not disclose permissions, side effects, or data safety. It implies a read-only operation but doesn't confirm.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences plus arg definitions), front-loaded with purpose, and every sentence adds value. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with an output schema, the description adequately covers purpose, parameters, and usage. It could mention behavior when no entries are found, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema: it explains 'topic' as 'topic or task description', 'tags' as 'optional comma-separated topic tags' with an example, and 'top_n' as 'maximum number of entries to return (default 5)'. Schema coverage is 0%, so description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves past memory entries by topic and returns a structured context brief. It specifies the verb 'Retrieve' and the resource 'memory entries', but does not explicitly differentiate from sibling tools like search_memory or search_notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (when needing memory entries for context injection) and how the tool works (topic keyword, optional tags, ranking, top N). However, it lacks guidance on when not to use or mention of alternatives among the many sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It mentions scanning and refreshing but does not clarify if 'refreshing' overwrites data, requires permissions, or has side effects. Critical safety details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with action, no filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an existing output schema, description is adequate but lacks mention of performance impact or error scenarios for a bulk operation. Could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. Description adds meaning by specifying 'all registered project folders', which is beyond the empty schema. No further param info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it scans all registered project folders for activity and refreshes CLAUDE.md for each. Verb+resource is specific and distinguishes it from sibling tools like scan_project_folder that operate on single folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context (called by dashboard Update button or on demand) but does not specify when not to use it or suggest alternatives like scanning a single folder. Implied usage is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It explains that the tool searches multiple tables and returns top results, but does not mention side effects, permissions, or response structure beyond the stated fields. The behavior is transparent enough for a read-only search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single-sentence purpose followed by a bullet-like explanation of sources and return format, with one parameter. Every sentence is essential and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the tool's straightforward search nature, the description adequately covers the tool's behavior, sources, and return structure. More guidance on when to use it among many similar siblings would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'content' is described as 'Text to find cross-domain connections for,' which adds value over the name alone. However, with 0% schema description coverage, the description does not fully compensate by specifying format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: finding cross-domain connections for given text, specifying the tables it searches and the structure of the result (top 5 with source type, title, snippet). This clearly distinguishes it from generic search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for cross-domain connections) but does not explicitly state when not to use it or provide alternatives among the many sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description details what is captured and where it writes, and that it returns the brief. No hidden side effects disclosed, but sufficient for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences: purpose, details, usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes captured data and output, but missing explanation of session_id parameter. Output schema exists but parameter gap hurts completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter session_id is optional with default '' but the description does not explain its purpose or effect. Schema coverage is 0%, so description fails to add meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a portable session handoff brief, listing specific captured data and output location. This distinguishes it from siblings like add_journal_entry or save_session_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: before session end, /clear, or device switch. Does not mention when to avoid or alternatives, 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the save behavior (path format) and parameter options, but lacks details on potential side effects (e.g., overwriting, costs, rate limits, authentication needs). The transparency is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-line summary and save path, followed by a structured Args block. It is clear and efficient, though the Args formatting is slightly verbose. Overall, good balance of detail and brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 1 required, and no annotations, the description covers all parameters and the output location. An output schema exists, so return value documentation is not needed. However, missing usage guidelines and potential side effects prevent a perfect score. Still, it is largely complete for a generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, the description provides an 'Args' section that explains each parameter with defaults, allowed values, and example usage. This adds substantial meaning beyond the raw input schema, making parameter selection clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate an image using AI and save it to the PKM,' specifying a verb (generate), resource (image), and destination. The title 'Generate Image' aligns with the purpose, and among siblings there is a distinct 'list_generated_images' tool, so there is no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention when not to use it. No prerequisites or contextual conditions are stated, leaving the agent to infer usage from the parameter description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions what information is retrieved but does not state that it is read-only, whether it requires authentication, or what happens if the context is missing. The safety profile is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise summary followed by parameter documentation. It is front-loaded with purpose. The 'Args' section adds value but could be slightly more concise. Overall efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the availability of an output schema, the description adequately covers the tool's purpose and parameter semantics. It does not describe the return value structure, but this is handled by the output schema. The description is complete enough for effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema for both parameters. For 'section', it enumerates valid values ('overview', 'articles', 'milestones', 'methods'). For 'max_chars', it explains the default, purpose, and special value 0 for no limit. This compensates for the schema's zero description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves research project context from the PKM and lists specific information types (structure, articles, milestones, methods). The name and title align, and it distinguishes itself from siblings like 'get_context' or 'get_project_status' by focusing on research context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for research planning and writing but does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. Given the large number of sibling tools, explicit guidance would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description is the sole source. It describes a non-destructive probe (returns flagged/patterns_found) but does not explicitly state it is read-only or safe. Lacks detail on logging side effects or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with version header, purpose, usage, args, and returns. Concise with no extra fluff. Could be slightly more streamlined but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides enough context given the simple nature of the tool: clear what it does, when to use, and what to expect in returns (probed_content, flagged, patterns_found). No missing critical information for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains both parameters: 'content' as the external content to probe and 'source_label' for logging. 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool probes external content for injection patterns and gives specific use cases (web scrapes, RSS, etc.), making the purpose distinct from many sibling tools. However, it doesn't explicitly differentiate from close siblings like 'check_data_safety'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this before inserting externally-sourced content into agent context, with concrete examples. Does not mention when not to use or alternatives, but the usage guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Capture as much reproducibility context as you can' but lacks information on side effects, permissions, rate limits, or what happens if the code already exists. This is insufficient for a save operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and usage guidance before listing parameters. Each sentence serves a purpose, though the parameter list is lengthy but necessary given the lack of schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (10) and zero schema description coverage, the description provides minimal coverage for each parameter. It does not explain default values, validation rules, or return value format (though an output schema exists). The description is adequate but leaves gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It lists each parameter with a brief semantic hint (e.g., 'Short descriptive name' for title, 'r | python | sql | ...' for language). While not exhaustive, it adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Save') and resource ('Code Repository'). It enumerates the types of code artifacts (script, snippet, reusable function, template) and distinguishes itself from siblings like 'search_code_repository' which retrieves code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use this whenever the user writes or shares code worth reusing.' It does not, however, explicitly state when not to use the tool or mention alternatives, which would be helpful for agents deciding between this and other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: it updates scan_summary and last_scanned fields, and refreshes CLAUDE.md. This gives the agent awareness of side effects beyond the simple operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four lines, each providing distinct information. It is front-loaded with the main action and efficient, though slightly more structure could improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the tool's purpose and side effects. It does not mention prerequisites (e.g., project must be connected) but is otherwise complete for a simple one-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not elaborate on the project_id parameter beyond its name. While the parameter is straightforward, the description adds no additional meaning or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans a project folder to detect work done since last scan, listing specific checks (git commits, modified files, todo completions, new documents). This distinguishes it from siblings like 'scan_project_scripts' and 'full_scan'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the description of what it does, but there is no explicit guidance on when to use this tool versus alternatives (e.g., scan_project_scripts) or any conditions/limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 details the scanning, parsing, and registration behavior, and notes the return summary. It does not mention potential side effects like overwriting or permissions, but overall adequately describes the tool's actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a header, bullet points, and an Args list. It is moderately concise, about 8 lines, with no superfluous content, though it could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (scanning multiple script types, registering artifacts, aggregating data) and the presence of an output schema (not shown but indicated), the description covers the key inputs and outputs. It explains the return summary (N scripts, M packages, etc.), making it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the tool description includes an 'Args' section explaining both parameters (folder_path and project_id). This adds meaning beyond the schema titles, compensating for the lack of schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool walks R/Python scripts, extracts metadata, and registers them as code artifacts. It lists specific file types and processing steps, but does not explicitly differentiate from sibling tools like scan_project_folder or scan_folder_for_intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description describes what the tool does but does not specify when to use it versus alternatives, nor does it mention when not to use it. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the free API, no key needed, daily safety, and insertion to news_briefs. However, lacks details on rate limits, error handling, or idempotency. Given no annotations, more transparency would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening statement, technical detail, usage context, and parameter explanations. It is reasonably concise for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema available, the description covers purpose, parameters, use context, and behavior. It lacks return value description but the output schema likely fills that gap. Idempotency and error handling are omitted, but for a daily scan tool this may be sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description thoroughly explains each parameter: query's multi-source fallback, reldate's meaning and default, max_results' purpose. This provides substantial value beyond the minimal schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans PubMed for recent papers matching a query. It mentions daily scheduling and response insertion, but does not explicitly contrast with sibling tools like scan_literature or search_literature, though the PubMed specificity is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions daily scheduling context and safety, but does not provide when-not-to-use or alternative tools for more complex queries or different sources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description discloses that it performs case-insensitive substring search with context lines and result truncation. However, it does not specify read-only nature, side effects, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a one-line summary followed by structured parameter descriptions. No unnecessary words, and the information is efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and moderate complexity, the description covers core functionality well. Minor gaps: does not specify if search is on content or filename, nor the full return structure (handled by output schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description provides clear explanations for all four parameters: query, scope, limit, and max_chars_per_result (including special behavior for 0). Adds value beyond the schema's types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches markdown notes across specific scopes (domains, projects, library). It distinguishes from many sibling search tools by specifying 'markdown notes' and the supported scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like search_library or search_memory. Lacks context about when to choose this tool over similar ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the return format and operational logic (analyzes profile, suggests operations with priorities), but omits whether the tool modifies the dataset (assumed read-only but not stated). No annotations to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded purpose, examples illustrate functionality, and structured Args/Returns section clearly explains output format. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, and return structure adequately. Output schema covers return details, so description doesn't need to exhaustively list fields. Slight gap in describing the profile summary format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single 'path' parameter is described as 'Absolute local path to the dataset file,' adding necessary detail beyond the schema's type definition. Compensates for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool profiles a dataset and returns recommended cleaning operations, with concrete examples distinguishing it from simpler profiling or cleaning execution tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 profile_dataset or clean_dataset. Lacks prerequisites (e.g., file must exist) or context about typical workflow placement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adequately discloses key behaviors: uses Whisper, optional speaker diarization conditional on dependencies, saves transcript alongside audio, updates meetings table, and returns transcript text and file path. This covers side effects and conditional behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but complete, using two paragraphs to state the core function and then document parameters and return values. It is efficiently structured without superfluous information, earning a strong score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, output schema present), the description covers the main functional aspects, optional features, and return structure. Minor omissions like error handling or diarization availability check are acceptable for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description's explanation of the sole parameter 'recording_id' as 'The meeting_id from the meetings table (shown in Meetings tab)' adds essential context beyond the schema's bare 'Recording Id' title, helping the agent know how to obtain the correct value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool transcribes a meeting recording using Whisper, which is a specific verb-resource pair. While it doesn't explicitly differentiate from sibling 'transcribe_voice', the mention of 'meeting recording' and 'meeting_id' makes its purpose distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for transcribing meeting recordings with an optional diarization feature, but does not provide explicit guidance on when to use this tool versus alternatives, or when not to use it. The context is clear but exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Add or update' indicating mutation and the unique key constraint, but lacks details on side effects, authorization needs, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise docstring with an Args section, no fluff, and every sentence adds value. It is efficiently structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema, the description covers essential parameters and usage hints. However, it could mention error cases or confirmation of upsert.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds meaning by clarifying 'name' as unique key, 'notes' as notes, 'role' as role/affiliation, and 'birthday' format (YYYY-MM-DD). This compensates well for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add or update a contact record,' specifying the action and resource. The tool name 'update_contact' aligns well, and it distinguishes itself from sibling tools like 'get_contacts'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that 'name' is used as a unique key, providing some usage guidance. However, it does not explicitly state when to use this tool versus alternatives 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.
- Behavior2/5
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 mentions the operation (integrity_check) and output format but does not explicitly state that the tool is non-destructive or safe to run. Missing details on error handling (e.g., if file is missing or encrypted).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences with no filler. It front-loads the core action and includes necessary parameter details. Every sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, simple output), the description covers the main behavior and output shape. It could be improved by mentioning what happens on errors (e.g., file not found, corrupted), but the core integrity_check behavior is adequately described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds significant meaning by specifying 'Full path to an unencrypted .sqlite backup.' This clarifies the parameter's type, format, and secrecy requirement, compensating for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs SQLite integrity_check on a backup file, specifying the exact action and resource. Among siblings like backup_db, restore_db, and list_backups, it is distinctly focused on verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for verifying backup integrity but does not explicitly state when to use versus alternatives or provide exclusions. No mention of prerequisites (e.g., file must already exist) or 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses that the result is written to the meeting's notes field in the database, which is a side effect. However, it doesn't discuss permissions, rate limits, or other 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a short summary, followed by usage context, behavior, and args/returns sections. No unnecessary sentences, but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and existing output schema, the description covers the tool's purpose, usage context, side effects, and return value. It is complete enough for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (meeting_id) with 0% schema description coverage. Description adds 'The meeting_id from the meetings table', providing context beyond the schema's 'Meeting Id' title, but could offer more detail like format or example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'find cross-references' and the resource 'saved meeting', specifying the types of cross-references (open tasks, related papers, active projects). It distinguishes from siblings by focusing on enriching a meeting after saving its transcript.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this after saving a meeting transcript' and mentions the normal flow via Meetings tab or transcribe_recording(). Does not provide when-not-to-use or alternatives, 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states it retrieves terms. It does not disclose any behavioral traits such as read-only nature, rate limits, or side effects. The minimal description fails to compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, clear return of all glossary terms) and the presence of an output schema, the description is complete and sufficient for an agent to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100%. According to guidelines, a baseline of 4 is appropriate as the description cannot add more parameter meaning beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' and resource 'all glossary terms', clearly stating the action and scope. It also distinguishes from sibling 'add_glossary_term'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or when to avoid it. Usage is implied by the name and sibling context, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the basic import operation without discussing side effects (e.g., duplication handling, overwrite behavior, validation). A user or AI agent would not know if this action is destructive or idempotent, or if it requires specific file permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences for purpose and usage, plus a two-line args section. Every sentence contributes useful information, and there is no redundancy or fluff. The structure is clear and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description is adequate but incomplete. It lacks guidance on error cases (e.g., invalid BibTeX, file not found), expected output format (though output schema exists), and whether the tool validates entries before importing. The description meets minimum viability but misses behavioral and error-handling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description adds meaning beyond the schema. It describes the sole parameter 'bibtex_path' as 'Full path to the .bib file (e.g. from Mendeley export).' This clarifies that it expects a file path and gives an example. However, it does not specify whether relative paths or remote paths are allowed, nor does it mention file encoding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Import papers from a BibTeX file') and resource ('into literature_metadata'). The verb 'import' and target 'literature_metadata' are specific. Among siblings like other import/search tools, this one uniquely handles BibTeX import, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete use case ('Use this for Mendeley users: export your library from Mendeley as BibTeX, then point this tool at the file.'). This provides clear context for when to use it, but it does not explicitly state when not to use it or mention alternatives. Other import tools exist (e.g., import_citations) but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the reading, splitting, and calling of capture_idea() per item. It does not mention error handling, duplicate detection, or limits. No annotations are present to supplement, so it carries the full burden but is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences plus a single bullet for the argument. It is front-loaded with the purpose, and 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (assumed to document return values), the description covers input, process, and file types adequately. It lacks details on edge cases like empty files or duplicates, but is sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, file_path, is described as absolute or relative to METIS_RC_ROOT. This adds meaning beyond the schema property name. Since schema description coverage is 0%, the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports an ideas document and captures each idea by splitting into discrete items and calling capture_idea(). It specifies supported file formats (.txt, .md, .docx). This distinguishes it from the sibling tool capture_idea which handles single ideas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for bulk import of ideas from a document, but does not explicitly state when to use this tool versus capture_idea for individual entries. No exclusion or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the algorithm (BFS), the max_hops parameter, and that results are ranked by length. With no annotations, this provides useful behavioral context. It does not mention performance characteristics or what happens when no path exists, but the core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus parameter list. The main purpose is front-loaded, 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (though not detailed), the description adequately covers input parameters and behavior. It mentions the returned result (paths ranked by length). Minor gaps: no mention of error handling or path format, but sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully compensates for the 0% schema coverage by explaining each parameter: from_path includes an example relative path, to_path is described concisely, and max_hops states its default and purpose. 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool finds connection paths between two knowledge library notes using BFS. The verb 'find' and resource 'connection paths' are specific. However, it does not differentiate from similar sibling tools like 'find_connections' or 'kg_memory_connections', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'search_library' or 'find_connections'. The description lacks context about prerequisites or typical use cases, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must stand alone. It discloses return format (JSON array, newest first) and default directory, but lacks explicit statements about safety (e.g., read-only) or potential side effects, which is acceptable for a simple list operation but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus argument breakdown. No fluff, front-loaded with purpose. Efficient use of space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter) and presence of an output schema, the description adequately covers purpose, parameters, and return structure (JSON array, newest first).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description adds meaning by explaining the purpose of backup_dir and its default value. This compensates well for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists backup files with size, age, and checksum availability. The verb 'list' and resource 'backup files' are specific and distinct from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus other list tools or alternatives. The description only states what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description lists checks performed but does not state side effects (read-only, no modifications), error conditions, or permissions needed. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with step number, purpose, bulleted checks, instruction, and parameter. No redundant sentences, all content earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Mentions return of pass/fail report, but with output schema present, description need not detail return structure. Lacks prerequisites and report interpretation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'slug' described as 'The course slug to review.' Schema coverage is 0%, so description adds basic meaning but not detailed syntax or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run quality checks on a drafted course before publishing' and lists specific checks, distinguishing it from sibling tools like publish_course.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells to fix failures before calling publish_course, implying usage timing. Does not mention alternatives or 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It implies a read-only search but does not explicitly state non-destructive behavior, authorization needs, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the purpose, and includes helpful examples. The argument list is clear. Minor redundancy could be removed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with an output schema, the description covers purpose, usage, and parameters adequately. It does not detail pagination or result format, but these are likely in the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds value by explaining each parameter: query is a keyword/phrase, limit is max results with default 10. This compensates well for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search past session summaries for a topic or keyword', using a specific verb and resource. It distinguishes from siblings like search_memory or recall by focusing on session summaries, though explicit differentiation is not given.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with examples ('what did we decide about the installer?') indicating when to use this tool. However, it does not explicitly exclude alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the write-to-disk action, backup creation, and database update. However, it fails to mention whether the operation is reversible (backup implies some reversibility but not explicitly), required permissions, or behavior on invalid proposal_id. Some transparency, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences plus an Args line, front-loaded with the primary action. Every sentence adds value: what it does, backup detail, database update, parameter meaning. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown), the description covers the main effects: write, backup, status update. It does not explain error handling or state prerequisites, but for a single-parameter tool with clear purpose, it is largely sufficient. Minor completeness gaps leave room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 0% description coverage, so the description must compensate. It explains the parameter 'proposal_id' as 'the id from skill_improvement_proposals', giving context beyond the schema's bare type and title. This is helpful for agent understanding, though additional detail on validity constraints would improve it further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Apply' and the resource 'self-improvement proposal', with specific actions: writes change to disk, backs up previous content, updates proposal row. This distinguishes it from sibling tools like 'propose_skill_improvement' (creation) and 'approve_proposal' (state change) by focusing on execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a proposal is ready to be applied, but it does not explicitly state when to use it versus alternatives like 'approve_proposal' or 'reject_proposal'. No prerequisites or conditions for use are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions 8000 char limit per source and returns assembled string with source labels, but does not explain what 'recent content' means, behavior when sources are empty, or default behavior when date_filters is null. With no annotations, more detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: one sentence for purpose, then clear details on char limit and output, then arg descriptions in docstring style. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two params, no annotations, and an output schema, the description covers essential aspects: sources, char limit, date filters example. However, it lacks definition of 'recent' and default filtering behavior, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates well by explaining that sources is a list from a set of allowed values (library, meetings, news, ideas, journal) and that date_filters is an optional dict with source-specific date filters, including an example. Adds significant meaning beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'assemble' and the resource 'context from multiple sources for brainstorming'. Distinguishes from sibling tools like brainstorm_turn or get_brainstorm_session by focusing on gathering context from specific sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for brainstorming context assembly but does not explicitly state when to use versus alternatives like load_project_context or get_agent_context. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns a 'plain unified-diff string suitable for display,' but does not discuss side effects, permissions, or safety. The behavior is simple and non-destructive, but more detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single-sentence summary followed by terse parameter definitions. Every sentence adds value, and the structure front-loads the core purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description adequately covers inputs and return type. It specifies the return is a unified-diff string for display. Minor gaps exist in error handling, but overall complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds brief clarifications: 'Original (pre-anonymization) text' and 'Anonymized text from anonymize_text().' This adds some meaning beyond the schema, but lacks details on constraints or formatting expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Return a unified diff comparing original and anonymized text,' which clearly identifies the verb (Return) and resource (unified diff). It distinguishes itself from the sibling 'anonymize_text' by focusing on the comparison output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after anonymize_text by referencing 'anonymized text from anonymize_text().' This gives clear context for when to use the tool, though it does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it reads reflexions, appends to skill.md, queues as draft, and does not apply. With no annotations, description adequately covers main behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences front-loaded with essential info. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return format is covered. Missing explanation of 'days' param and any edge cases or side effects, but overall adequate for a 2-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0%, description only explains agent_slug but not 'days' parameter (default 14). Days likely controls reflexion timeframe but is left implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'draft', resource 'skill-improvement proposal', and source 'recent reflexions'. Distinguishes from siblings like apply_proposal and propose_skill_improvement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says draft is NOT applied and points to apply_proposal as alternative. Lacks context on when to choose over propose_skill_improvement or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only on the database; writes only Markdown', which clarifies safety and side effects. It also describes the output format. However, it does not mention potential issues like overwrite behavior or performance with large libraries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 120 words) and well-structured: purpose, format, portability, safety, and parameter. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers all critical aspects: what it does, output format, side effects, and parameter description. No missing essential information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by explaining the single parameter 'out_dir' with a default path. It adds meaning beyond the schema, though it could elaborate on what 'RC root' means and behavior when omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports the library as a cross-linked Markdown vault with specific details (YAML frontmatter, index, wikilinks). However, it does not explicitly differentiate from the sibling tool '_obsidian_vault', which may have similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a portable Markdown export but lacks explicit guidance on when to use this tool vs alternatives, such as other export or search tools. No 'when not to use' or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. States that tools are made callable and returns names, but does not disclose if it adds to or replaces existing active tools, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly concise but includes an 'Args' section that duplicates schema information. The main action is front-loaded, but the redundancy reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the tool's purpose, usage, and parameters. Output schema exists so return values need not be detailed. Explains why tools are kept out of active set. Missing details on persistence of loaded tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning beyond schema: defines query as 'keywords describing what you want to do' and limit as 'max tools to return/load'. Schema had no descriptions, so this is helpful. Could be more specific about query format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the full tool catalogue and loads matching tools on demand, which is a unique purpose distinct from sibling tools. It provides specific examples of query keywords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use: to find tools by keyword to save context. It tells the agent to call returned tools directly. Does not explicitly state 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates read-only behavior through 'Retrieve' and 'Reads the consent_ledger', but does not explicitly state that no data is modified. It also does not disclose potential limitations (e.g., rate limits, size of ledger). The behavior is adequately but not exhaustively described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief intro, a context sentence, a clear Args section, and a Returns section. Every sentence adds value without redundancy. Front-loads the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, clear read-only purpose, output description provided), the description is complete. It covers what the tool does, what it returns, and the parameter role. No additional context seems necessary 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (limit) has 0% schema description coverage, but the description fully compensates by explaining its meaning ('Number of most recent ledger rows to return, newest first') and default value (30). This provides complete semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves recent consent events from the audit ledger, specifying the resource (consent events) and action (retrieve). It mentions the source (consent_ledger written by log_consent_event) and the fields returned, providing a specific purpose. However, it does not differentiate itself from other 'get' sibling tools beyond linking to its write counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reviewing or reporting on sensitive data treatment, providing context. It also notes the relationship with log_consent_event, but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or comparisons to other audit or logging tools are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states it loads and returns a summary, but omits details on idempotency, authorization requirements, rate limits, or any side effects. For a read operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: three sentences plus an argument list, each sentence adding unique value. It is front-loaded with the version and purpose, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema (not shown but present), the description adequately covers the tool's role and expected output. It could be slightly more specific about the return format, but is generally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'level' has no schema description (0% coverage), but the description lists explicit values ('quick', 'standard', 'deep', 'chain') and explains that it controls the complexity of returned behavioral rules. This compensates for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool loads the Metis constitutional policy for agent context, returning a summary of behavioral rules. It distinguishes itself from sibling get_* tools by specifying it enforces shared policy across all agent types, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to prepend the policy to any agent's system context to enforce shared policy. This provides clear context for when to use the tool, though it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's read-only nature implicitly (querying) and mentions optional filters and a default limit. However, it lacks details on pagination (e.g., offset/cursor support), ordering, and any potential errors. The output schema exists, so return format is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: one summary line followed by a structured list of parameters with clear explanations. Every sentence is relevant and adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with 4 optional parameters, an existing output schema, and no required fields, the description adequately covers the filtering behavior. It lacks information on sorting order or default ordering, but the tool appears straightforward. Overall, it is comprehensive enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does so for all four params: status (with allowed values), project_id, owner, and limit (with default). This adds meaning beyond the schema's title and default values. Minor ambiguity: description says '' for status means all, but default is 'open', which is clear enough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query') and resource ('tasks'), clearly distinguishing it from sibling tools like create_task, update_task, and delete_task. It states that the tool queries tasks from a SQLite database with optional filters, which is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the primary task listing tool via the phrase 'Query tasks from the SQLite database', but it does not explicitly specify when to use it versus other search or memory tools (e.g., search_memory, list_recent_sessions) or provide exclusion criteria. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 it fetches references via CrossRef, checks against Zotero, and reports missing items. However, it does not mention potential side effects, rate limits, authentication requirements, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with only four lines. It is front-loaded with the main purpose, and each subsequent sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values. It covers inputs and process adequately. A brief mention of output content could enhance completeness but is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It describes 'dois' as a comma-separated list of DOIs and 'label' as an optional output file label, adding practical context beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (mine/fetches/checks/reports), resource (reference lists of specific articles), and specific actions (via CrossRef, against Zotero library). It distinguishes this tool from siblings like search_library or scan_literature by focusing on mining references from DOIs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching references from DOIs and checking against Zotero, but does not explicitly state when to use this tool vs alternatives or provide exclusions. No guidance on when not to use it is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the algorithm and parameter effects but omits side effects, permissions, or whether it is 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three short paragraphs covering purpose, method, and parameters without extraneous details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the tool's behavior and parameters, though it could mention prerequisites or safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to both parameters (n_clusters auto-detect at 0, min_papers default 3) beyond the schema, which has 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it clusters papers and proposes a collection structure, distinguishing it from sibling tools like search or list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how the tool works (k-means on embeddings) but does not explicitly state when to use it or when to prefer alternatives like search_library.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals key behaviors: content classification, blocking sensitive requests, persistence to session_events, and returning a routing decision. However, it omits details on error handling, idempotency, or side effects beyond the pipeline steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose at over 250 words, including a detailed bullet list of the 11 pipeline stages. While well-structured and informative, it could be more concise by summarizing the pipeline without enumerating every step.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 params, output schema exists), the description covers the pipeline flow, parameter semantics, and subsequent agent actions. It lacks details on error scenarios or return format, but the output schema (not shown) likely handles return clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 provides an 'Args' section with brief but meaningful explanations for each of the 4 parameters (e.g., 'Existing session ID if resuming. Leave empty to auto-bootstrap.'). This adds value beyond the schema's type and name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it is the 'Master /metis entry point' that runs an 11-stage pipeline and returns a routing decision. This clearly distinguishes it from sibling tools like 'metis_doctor' or 'session_bootstrap' by defining its central orchestrating role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that 'Every /metis invocation passes through here' and details which stages are executed by the tool versus called by the agent later. This provides clear context for when to use it, though it does not explicitly list alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the effect of each policy mode (strict, normal, offline) and that it applies to all agents, but does not mention requirements, reversibility, or potential disruptions (e.g., dropping connections).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a brief sentence followed by a bullet list and explicit args. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with an output schema, the description covers the core functionality well. It could mention return behavior or confirmation, but the output schema likely covers that. Missing failure conditions or required permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It defines the only parameter 'policy' with three valid values and their meanings, which adds significant value beyond the empty schema. However, it could have listed the values as an explicit enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Set the current network access policy for all agents' and distinguishes three modes with explicit explanations. This differentiates it from the sibling 'get_network_policy' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what each policy does but does not provide when to use this tool versus alternatives. There is no mention of prerequisites, side effects, or guidance on when to choose which policy. However, the context is clear regarding the tool's function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description clearly states it reads 'reflexion_log' entries (non-destructive) and returns aggregated themes. It does not contradict any annotations. Slight lack of mention of potential side effects, but none expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise (3 sentences) and front-loaded with the core purpose. It could be slightly tighter but is clearly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description covers the input parameters, data source, time window, and output categories sufficiently. It does not need to detail return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning: 'days' is time window (default 14 days), 'agent_slug' scopes to one agent or all. This compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Theme') and resource ('recent reflexions per agent') with clear scope (Phase 9b). It distinguishes from siblings like 'consolidate_reflexions' by focusing on aggregation and thematic grouping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to get top themes from recent reflexion logs) but does not explicitly mention when not to use or suggest alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses that the tool searches a pre-built index and returns synthesized citations, implying non-destructive read-only behavior. However, it doesn't explicitly state no side effects or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and front-loaded: one sentence for purpose, minimal parameter list. No filler, but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given sibling tools and presence of output schema, description covers primary use case, dependency on index, and scope variants. Lacks details on return format but output schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's 'Args' section explains each parameter: question, top_k (default 5), and scope with concrete options (default, ph_library). Adds significant value beyond bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool answers a question using the user's indexed PDF library via PaperQA2, returning a synthesized answer with citations. It distinguishes from sibling tools like search_library by focusing on synthesis rather than raw retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on prerequisite (build index first with index_library_pdfs) and explains scope options. Could be stronger by explicitly listing when not to use, but gives adequate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: reading recent runs, filtering based on output files and summaries, deduplication against existing entries, and writing to DB and markdown files. It lacks details on side effects or permissions but provides sufficient transparency for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. The Args section is integrated but could be more structured (e.g., bullet points). Overall efficient with no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, high coverage in description, and an output schema (not shown), the description sufficiently explains the process, inputs, and outputs. No major gaps apparent for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description's Args section explains both parameters (n_runs default 20, min_quality with options 'high' and 'all'). This adds meaningful context beyond the schema, clarifying behavior and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool scans recent agent runs, identifies high-value work, deduplicates, and writes memory entries. It specifies verbs 'scan' and 'write' with resources, and contrasts with similar siblings like 'consolidate_old_memories' and 'add_memory_entry' through its explicit workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool reads recent runs and the meaning of parameters (n_runs, min_quality), implying use for consolidating session memory. However, it does not explicitly state when to use this vs alternatives like consolidate_old_memories or add_memory_entry, nor provides when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must convey behavioral traits. It specifies keyword matching and the three tables, but omits details about result grouping, pagination, or ordering. Some behavioral context is provided, but not comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose, one for method and tables, then parameter explanations. It is front-loaded with the primary action and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the existence of an output schema, the description covers the key aspects: what is searched, how, and parameters. It lacks detail on result structure (e.g., grouped by source) but is largely sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains both parameters: 'content' as the text to find connections and 'limit' with default 5 as max results per source. This adds meaning beyond the raw schema, compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches library, meetings, and news for items related to given text, using keyword matching. This distinguishes it from sibling single-source search tools like search_library, scan_news, etc., by specifying the combined scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cross-source keyword searches but does not explicitly state when to use this tool versus alternatives like search_library or search_fulltext. No when-not-to-use 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must convey behavioral traits. It states a read operation but omits details like required permissions, rate limits, or whether the schedule is stored persistently. Adequate for a simple getter but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 8 words, no fluff. Every word adds value. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema present, the description is complete for a simple retrieval tool. It sufficiently describes what the tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, schema coverage is 100% vacuously. Description adds no parameter info, but baseline is 4 for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Verb 'Return' clearly indicates retrieval, resource 'backup schedule configuration' is specific. Distinguishes from sibling tools like set_backup_schedule (write) and list_backups (list backups, not schedule).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies read-only usage but does not explicitly state when to use vs alternatives (e.g., set_backup_schedule, list_backups). No when-not-to-use advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes sorting order (most recent first), returned fields (agent slug, rationale, diff summary), and truncation of diff summary to 200 chars. No annotations provided, so description carries burden; it covers key behaviors but omits potential details like pagination or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second adds sorting and field details. No redundant information, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple list tool with output schema (return values documented there). Covers sorting, fields, truncation, and scope. No missing critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description correctly implies no parameters needed. With 0 params, baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists skill improvement proposals awaiting review, with specific verb 'list' and resource 'pending proposals'. It distinguishes from sibling tools like approve_proposal and reject_proposal by focusing on listing pending ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. Does not mention when not to use it or suggest alternative tools for creating or approving proposals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full transparency burden. It mentions graph traversal ('Traverses the lightweight knowledge graph') but does not specify error handling (e.g., missing entry_id), performance characteristics, or confirm it is read-only. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Overall concise: two introductory sentences followed by a bullet-style parameter list. The structure front-loads the core purpose and usage. The parameter descriptions repeat some schema info but add value through explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters (two required, one optional) and an existing output schema, the description covers the core usage, parameter meanings, and a typical workflow link. It lacks details on error cases or edge conditions, but is sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, so the description must compensate. The 'Args' section explains all three parameters: layer (memory type), entry_id (row ID), direction (outgoing/incoming/both with default). This adds meaningful context beyond the schema's bare type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds memories related to an entry via memory_relations using graph traversal. This distinguishes it from other memory tools like recall or search_memory, which focus on direct retrieval or text search, by highlighting the relational graph aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this after recall() and provides concrete examples (papers informed a decision, concepts relate to a workflow). Does not explicitly state when not to use, but the guidance is clear enough for typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It indicates a read operation (reads from directory) and briefly describes the output (filename, date, prompt). However, it does not disclose sorting order beyond 'newest first' in the param, pagination, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three sentences, each adding value. It front-loads the purpose and efficiently covers directory, output fields, and parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one parameter and an output schema, the description covers the main points. However, it could mention sorting order explicitly and whether results are paginated beyond the limit. It is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the limit parameter; the description adds essential meaning: 'Maximum number of images to return (default 20, newest first).' This fully compensates for the lack of parameter documentation in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List recently generated images in the PKM' and specifies the directory path, making the purpose unambiguous. It is distinct from sibling listing tools like list_folder by focusing on generated images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving recently generated images, but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It adequately describes what the tool returns (built-in and custom databases, fields like layer, document count, etc.), but does not mention any potential side effects, authentication needs, or rate limits. For a listing tool, this is sufficient but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs. It front-loads the main action and resource, and every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema present, the description provides sufficient context about what databases are listed and what fields are included. It is complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds meaning by detailing the types of databases included and the specific fields reported, which is valuable beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all knowledge databases (layers) in Metis, mentioning specific built-in and custom databases. It distinguishes from sibling tools like create_knowledge_database and build_pdf_knowledge_db by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While the purpose is clear, there is no explicit guidance on when to use this tool versus alternatives. The description implies its use for viewing the list, but no when-not or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses the logging action, dashboard appearance, and side effect of writing a session event when session_id is present. However, it does not specify idempotency, error behavior, or authentication requirements, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with separate sections for purpose, usage, parameters, and returns. Each sentence contributes value, though slightly wordy. Front-loaded with the main action and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 params, no annotations, output schema present), the description covers purpose, when to call, parameter details, return value, and side effects. It lacks error conditions and exact return format, but the output schema may fill those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the documentation-style parameter explanations add significant meaning, such as clarifying that 'complexity' maps to status values and that 'session_id' triggers an additional event. Some defaults (e.g., 'standard' for complexity) are slightly inconsistent with the listed statuses, but overall adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool logs a completed agent run for audit and dashboard tracking, with a specific verb ('Log') and resource ('agent run'). It distinguishes from siblings like get_agent_runs and other logging tools by emphasizing the 'completed run' context and integration with the dashboard and session events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to call it 'after writing an output file, per the output contract' and explains the conditional behavior when session_id is supplied. No explicit exclusions or alternatives are provided, but the context is clear enough for proper use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 it returns text and has a max_chars default, but lacks details on error handling, encoding, or behavior for binary files. The description adds moderate value beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise with a clear two-line summary and an Args section. The first sentence could be combined with the second, but overall it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool and the presence of an output schema, the description covers purpose, file types, and parameter defaults. It does not mention output format explicitly, but that is likely defined in the output schema. It is mostly complete for a read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides prose explanations for both parameters (path and max_chars), including usage guidance for large files. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads file content and returns text, lists supported text file types, and notes that files need not be pre-registered. This differentiates it from sibling tools like scan_tracked_files or list_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies it works for any text file and that the file doesn't need pre-registration, giving clear context. However, it does not explicitly state when not to use it (e.g., for binary files or metadata), and no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses file movement to processed/, transcription method (faster-whisper), and handling of non-audio files (listed for manual review). It does not cover error handling or permissions, but covers key 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, listing supported audio formats, processing steps, and parameter usage. It is well-structured with bullet-like lines and a clear separation of parameter description. Could be slightly shorter but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no required fields, output schema exists), the description is largely complete. It explains input, process, and output (ideas). Missing details about return format are covered by the output schema, so overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds full value. It explains the single parameter 'auto_transcribe_audio' in detail: default behavior (True) and effect when set to False (list only). This compensates completely for the schema lack.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('scan the inbox/ folder and auto-transcribe any audio files to ideas'), identifying the resource (inbox) and the operation (transcribe). It includes supported audio formats and distinguishes itself from sibling tools like scan_literature, scan_news, etc., by focusing on inbox processing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does and when to use the parameter (auto-transcribe), but does not explicitly say when to avoid this tool or suggest alternatives among siblings. It provides context but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It describes search sources and return format but lacks details on idempotency, permissions, or side effects. As a read-only search, it is acceptable but not explicit about safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns). It is concise while providing necessary details, though it could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 non-enum parameters and an output schema, the description adequately explains the search sources, fields covered, and return format. No critical gaps for a simple search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage). The description adds meaning: query is a keyword or phrase, entry_type lists possible values (session, journal, idea, decision, topic) and default behavior. This compensates well for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches memory by keyword across both structured entries and journal notes, with explicit scope (memory_entries table and journal files). This is specific and distinct from sibling tools like search_session_memory or search_library.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what data is searched and mentions optional filtering by entry type. However, it does not explicitly contrast with other search tools or provide when-not-to-use guidance, though the scope is clear enough for basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool only persists configuration and that older backups will be deleted based on keep_days when the scheduler runs. However, it does not mention authorization needed, error states, or reversibility of settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a clear opening clause, a brief behavioral note, and a parameter list. Every sentence serves a purpose, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and all parameters well. However, it does not mention the presence of an output schema or what the tool returns (e.g., a confirmation or the schedule state). Slightly incomplete for a tool with an output schema, but otherwise comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It adds meaningful explanations for all 4 parameters: enabled (on/off), time_utc (format hint 'HH:MM'), keep_days (retention policy), and destination (default path). This adds significant value beyond the schema's bare types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Configure the nightly backup schedule' with specific verb and resource. It further explains that the schedule triggers backup_db() automatically and that this tool only persists the configuration, distinguishing itself from related tools like backup_db and get_backup_schedule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating the scheduler reads the schedule to trigger backup_db(), and that the tool only persists config. However, it does not explicitly state when to use this tool vs alternatives like backup_db for immediate backup or get_backup_schedule for viewing, nor does it provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lists actions (creates, adds, returns) but does not disclose authorization needs, side effects, or whether the operation is reversible. Basic transparency is present but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (under 100 words), front-loaded with the main purpose, and organized with clear sections for args and returns. 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, output schema exists), the description fully explains the effect on the database and the return value (Course ID, confirmation, questionnaire). No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the JSON schema provides no descriptions. The description compensates by giving clear explanations for each parameter (e.g., topic: 'The subject or title of the course'). This adds significant meaning beyond the schema's titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it starts a new course build pipeline, creates a course record, adds a placeholder row, and returns an intake questionnaire. It distinguishes from sibling tools like publish_course or save_course_curriculum by focusing on the initial pipeline step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for starting a course build, but it does not explicitly state when to use it versus alternatives like save_course_curriculum or publish_course. No guidance on prerequisites or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses offline operation, supported formats, routing behavior, and model size options. It does not mention any destructive side effects, but the 'route_to' parameter implies potential file creation, which is documented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, a note about offline processing, and a clear Args section. It is somewhat verbose but each sentence adds value. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of audio transcription and routing, the description covers inputs, outputs, behavior, and constraints. The return value is described, and examples illustrate common usage. No gaps for an AI agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description provides thorough parameter documentation: each parameter's purpose, options, defaults, and interactions (e.g., record_seconds used only when audio_path empty). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Transcribe an audio file or live mic recording' with a specific verb and resource. It is distinct enough from siblings like 'transcribe_recording', though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples and explains parameters, but lacks explicit when-to-use or when-not-to-use guidance relative to sibling tools. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior: sets status='archived', keeps in DB, affects default view but not search. It does not mention permissions, reversibility, or side effects, but for a simple archive operation the transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences plus an Args line. The first sentence states the core purpose, the second provides the SQL detail, and the third explains the effect. No wasted words; information is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (one parameter, simple action) and the presence of an output schema, the description covers the key aspects: what happens to the item, its visibility, and the parameter meaning. Minor gaps like reversibility or permissions are not critical for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain the parameter. It does so by stating that relative_path is the primary key in the library_seeded table, adding context beyond the parameter name. This is sufficient, though a format example could improve it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Archive' and the resource 'library item,' explaining that it marks an item as no longer active but keeps it in the database. It distinguishes this from deletion (e.g., remove_library_item) by noting the item remains searchable and cross-pollinated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the effect (disappears from default view, stays searchable) but does not explicitly state when to use this tool versus alternatives like remove_library_item or archive_project. The usage context is implied rather than directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the use of SQLite's Online Backup API, safety for live databases, and return fields (backup_path, size_kb, checksum, elapsed_ms). This is more than basic transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, followed by a safety note and bulleted argument list. The return value description is included. Slightly verbose due to redundant argument list with schema, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 optional parameters and no required ones, the description fully covers purpose, safe usage, parameter details, and return format. No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides clear explanations for all three parameters: destination (default path), label (filename appendix), and extra_destination (secondary copy). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action (create), resource (timestamped backup), and context (Metis SQLite database). It clearly distinguishes from sibling tools like restore_db and verify_backup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is safe to run while the database is live, providing good context. However, it does not explicitly state when not to use or mention alternatives like encrypt_backup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains provider-specific parameters and that Mendeley uses BibTeX export. However, it does not disclose whether the operation overwrites existing config, requires specific permissions, or has side effects like restarting services. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences describing purpose, then a bulleted list of argument explanations. Every sentence adds value; no fluff. Front-loaded with the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown), the description doesn't need to explain return values. It covers usage scenarios (setup, switching) and parameter details. It could mention validation or success indicators, but is mostly complete for a configuration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates well. It explains that provider can be 'zotero' or 'mendeley', that api_key comes from a specific Zotero URL, user_id is numeric, and bibtex_path is for Mendeley. This adds meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it configures the library provider for the Metis installation, with a specific verb (configure) and resource (library provider). It distinguishes from sibling tools like import_bibtex_library and sync_zotero_library which are related but different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Call this during setup or when switching reference managers', providing clear context for when to use. It does not explicitly state when not to use it or list alternatives, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses key behaviors: default values for owner, recurrence auto-creation on completion, and subtask creation via parent_task_id. Does not discuss error conditions or side effects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a clear header and bulleted parameter list. It is reasonably concise, though some lines are slightly verbose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters (2 required) and an existing output schema, the description covers all parameters with meaningful explanations. It lacks discussion of edge cases or error handling, but for a create operation, the essential context is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning parameters have no descriptions in the schema itself. The description compensates fully by providing clear explanations for each parameter, including formats (e.g., YYYY-MM-DD for due_date), allowed values (e.g., recurrence options), and usage context (e.g., parent_task_id makes it a subtask).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a new task in the SQLite database' with a specific verb and resource. It lists all parameters with explanations, distinguishing it from sibling tools like update_task and delete_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating tasks but does not explicitly state when to use this tool vs alternatives like update_task or delete_task. No guidance on when not to use it or context-specific recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only scan (detecting repos and folders), but does not explicitly state that no modifications occur. A direct statement would be better.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences: purpose, context, and parameter detail. Every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and parameter. Since an output schema exists (not shown), the absence of return value explanation is acceptable. It is adequate for the tool's simple nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter scan_path is described with its purpose ('absolute path to scan') and default behavior ('parent of METIS_RC_ROOT'). This adds significant value beyond the schema, which only has a default and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it scans for 'unregistered git repos and article folders', which is a specific verb-resource combination. This clearly distinguishes it from sibling scanning tools like scan_folder_for_intent or scan_inbox.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mentions onboarding as the use case and directs to call create_project() for registration. While it doesn't list when not to use, the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral transparency burden. It explains the paging parameter behavior ('get only the first page (faster for large resources)') and provides examples showing typical usage. It does not contradict any annotations (none present). However, it could explicitly state idempotency or read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (Args, Examples) and uses bullet points for parameter descriptions. It is concise yet informative, though the examples could be slightly trimmed without loss of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (1 required), no enums, and an existing output schema, the description is complete. It covers all parameters, provides usage examples, and references the sibling tool dhis2_query. No gaps are left for an agent to misinterpret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It does so by explaining each parameter: resource (with examples), filters (format with example), fields (default value), and paging (behavior). This goes beyond the raw schema, though it could provide more exhaustive resource examples or filter syntax details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query DHIS2 metadata with a simplified interface' and identifies itself as a 'Convenience wrapper around dhis2_query()', using specific verbs and resource types. It distinguishes itself from its sibling tool dhis2_query by emphasizing simplicity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for common metadata lookups (as a wrapper) but does not explicitly state when to use this tool versus dhis2_query or other alternatives. It lacks explicit when-to-use or when-not-to-use guidance, leaving the agent to infer from 'simplified interface'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It states the passphrase is never stored and describes the output and return value, but does not mention overwriting behavior, error handling, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with essential information front-loaded. Every sentence adds value, and the argument section is succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers key aspects: algorithm, output file, security note, and return JSON. It could mention potential errors or edge cases, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It provides brief but clear definitions for `backup_path` and `passphrase`, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool encrypts a backup file using AES-256-GCM and produces an output file with '.enc' extension. It distinguishes itself from sibling tools like `decrypt_backup`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It notes that the implementation uses Python stdlib and is simple, advising against production-grade use without a secrets manager. However, it does not explicitly contrast with other tools or specify conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states 'Retrieve' implying read-only, but does not disclose any behavioral traits like authentication requirements, rate limits, or side effects. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear two-line purpose followed by structured argument descriptions. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description covers all parameters with defaults and behavior. Complete enough for an agent to use correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the raw schema: explains the default values, that empty topic means all topics, and the filtering behavior of 'unread_only'. Schema coverage is 0%, so description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and resource 'new publications', with optional topic filtering. This distinguishes it from sibling tools like 'search_literature' which may retrieve all publications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'scan_news' or 'search_literature'. The purpose implies it's for recent publications but does not provide exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly states it reads from a YAML file and falls back to a default structure if the file does not exist, which is an important behavioral detail. No mention of idempotency or side effects, but the read-only nature is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. The main action is front-loaded, and the fallback behavior is provided in a separate sentence. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with an output schema, the description is adequate. It specifies the source path and fallback behavior. Could be improved by explicitly stating idempotency or read-only nature, but the current info is sufficient for an agent to understand what happens.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so there is nothing to explain. The schema coverage is 100%, meeting the baseline expectation. The description correctly avoids inventing unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Title and description clearly state it reads the thinking profile from a specific file. The verb 'Read and return' plus resource path makes purpose unambiguous. Siblings like reset_thinking_profile and update_thinking_profile confirm this as the read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is minimal—only describes what the tool does, not when to use it versus alternatives. No explicit when-not-to-use or mention of sibling tools. For a zero-parameter getter, the need is obvious, but explicit guidance could improve differentiation from related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and discloses key behaviors: reads PDFs, stores first 4000 characters, updates abstracts, and is incremental. It does not mention destructive actions, but the mutation of metadata is transparently described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear bullet points and an Args section. It is front-loaded with the main purpose. Could be slightly more concise, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description does not need to explain return values. It sufficiently covers inputs, behavior, and incremental nature. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that explains the possible values for the single parameter 'scope' (literature, zotero, all), which the schema only defines as a string with no enums or description. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts and indexes full text from PDFs in the Metis library, specifying sources (inputs/literature/, Zotero storage) and storage destinations. It differentiates itself by mentioning incremental processing and scope parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for indexing PDFs but does not provide explicit guidance on when to use this tool versus alternatives like 'index_library_pdfs' or 'scan_literature'. No when-not-to-use 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It mentions 'insert/replace' indicating potential overwriting, but does not specify effects on existing data, error handling, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary, followed by a short workflow explanation, then an Args block. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the workflow and parameters adequately. Given the existence of an output schema, return values are not required. It could mention prerequisites (e.g., JSON must be from profiling script) but already implies it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining each parameter: json_path, dataset_name, and project_id. It provides usage details like 'absolute path', 'override the dataset name', and 'project to associate'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads JSON profiling output and registers it as a data dictionary. This distinguishes it from siblings like 'generate_profiling_script' (which produces the JSON) and 'register_data_dictionary' (which might have a different input).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool is used after running a profiling script locally, which generates a JSON file. It sets the context for when to use it, but does not explicitly list alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the algorithm (BFS flood-fill from a starting entry up to depth hops) and the return format (entries grouped by distance with shared topics). It implies a read-only operation. While it omits performance characteristics or potential side effects, the provided details are sufficient for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a sentence on the underlying graph and algorithm, then a bullet-point Args section. Every sentence adds value, and the critical purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and no annotations, the description covers the algorithm, all parameter semantics, and the return format (grouped by distance with shared topics). It is complete enough for a tool that traverses a memory graph, requiring no additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section that explains the meaning and allowed values for entry_type ('memory', 'episodic', 'semantic', or 'idea'), entry_id, and depth (default 2). This adds crucial meaning beyond the schema, which only has names and types. With 0% schema description coverage, the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds memory entries connected via shared topics using BFS flood-fill. It identifies the starting entry and depth but does not explicitly differentiate from sibling tools like 'find_connections' or 'get_related_memories', though the algorithm mention (BFS, graph) provides implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when you need connected memories via shared topics, using the graph built by kg_index_memory(). However, it does not provide explicit guidance on when to use this tool over alternatives, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It states it appends a row (write operation) and lists parameters, but lacks details on side effects, idempotency, permissions, or error handling. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose, one for usage, and a clear Args block. No wasted words, front-loaded, and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, the description needn't detail return values. It covers purpose, usage, and all parameters. Slight gap: no mention of success/failure response, but overall complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema properties), but the description includes an Args block explaining each parameter: action, data_classification (with enum list), agent_slug, notes, session_id. This adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool appends a row to the consent_ledger table, providing an audit trail for agent data processing. It uses specific verbs and resource, distinguishing it from siblings like get_consent_ledger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this whenever an agent processes data so there is an audit trail,' giving clear when-to-use guidance. It doesn't mention alternatives or when-not-to-use, 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that it records a span and returns a span_id. Does not cover side effects, idempotency, or storage behavior. Adequate but could be more comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured. Starts with a clear summary sentence, then lists parameters in a readable format. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main use case and parameter details. Mentions return value (span_id) despite output schema existing. Could discuss error handling or constraints, but overall complete for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by listing all 8 parameters with clear one-line explanations. Adds significant meaning beyond the schema's titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it records a completed span in one call, distinguishing from a start/end two-call approach. The sibling tools include start_span and end_span, so the description effectively differentiates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for when to use (retrospective timing data) and implies alternative of separate start/end calls. Does not explicitly list when not to use, but the single-call distinction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the proposal is queued and not directly applied, and returns a proposal ID for review. However, it does not mention any side effects, required permissions, or limits on pending proposals, which would enhance transparency for a mutation-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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (6 lines), well-structured with a brief statement of purpose followed by Args and Returns sections. Every sentence adds value without repetition or fluff. Front-loaded with the key point about queuing and human review.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no nested objects, output schema exists), the description adequately covers the workflow and return value. It could mention what happens after approval or rejection, or how to retrieve the proposal ID later, but it is complete enough for an AI agent to understand the proposal cycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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: agent_slug with examples, proposed_content as full replacement, and rationale with length guidance. This adds significant meaning beyond the schema's type/title, especially for rationale (schema has only default empty string).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'proposes' and the resource 'change to its own skill file', and distinguishes it from direct modification by explicitly referencing approve_proposal(). The title includes 'Metis — Propose Skill Improvement', further clarifying the domain and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the proposal is queued for human review and not applied until approve_proposal() is called. This provides clear guidance on when to use this tool (to propose changes) and when not (for immediate effect, use approve_proposal). It references the approval step but does not explicitly compare with other sibling tools like draft_self_improvement_proposal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes key side effects: setting row to active, resetting progress, and writing a note. However, it does not mention permissions needed, reversibility, or error conditions. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with purpose, followed by implementation details, then parameter and return info. Every sentence is meaningful with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter and presence of an output schema, the description covers the essential usage. It provides context about being after 7 steps. Missing details about what '7 steps' are or prerequisites, but still complete enough for an experienced user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by listing the parameter and its purpose: 'slug: The course slug to publish.' This adds meaning beyond the schema's type-only definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Finalise and publish' and identifies the resource as 'completed course build'. It clearly states the actions performed: marks as active, sets progress to 0, writes completion note. This distinguishes it from sibling tools like 'get_course_status' or 'review_course'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Call after all 7 steps are done', providing clear guidance on when to use. It also implies the course must be completed. However, it does not explicitly state when not to use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It explains the purpose (building a traceable chain) and that it should be called per step, implying additive and non-destructive behavior. However, it does not state idempotency, error handling, or whether it modifies existing data. The traceability context provides moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (about 7 lines) and front-loaded with the core purpose. Every sentence contributes meaning: purpose, traceability rationale, usage hint, parameter explanations. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (recording a step), the description covers purpose, usage pattern, and parameter meanings. An output schema exists (so return values need not be explained), and the description does not cover error scenarios or prerequisites, but those are less critical for a recording tool. It adequately equips an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description is essential. The 'Args' section (in the description text, not the schema) explains each parameter's role, including an example for 'description' and valid values for 'step_type'. This adds significant meaning beyond the schema's parameter names, though more constraints (e.g., format for 'code') could be added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool records a cleaning/transformation step for dataset lineage. It uses a specific verb ('Record'), identifies the resource ('one cleaning/transformation step for a dataset'), and distinguishes itself from sibling tools like 'clean_dataset' (which performs cleaning) by emphasizing traceability and reproducibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'Call once per step' and provides examples of step types (recode, filter, join, derive, …). It implies this tool is for recording rather than executing steps, but lacks explicit guidance on when not to use it or alternatives among siblings (e.g., 'clean_dataset', 'profile_dataset'). Clear but could be more explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must stand alone. It clearly states the behavior: the skill file is not changed, the proposal is marked rejected with an optional reason. This is sufficient for a simple non-destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with the core purpose, then explaining effects, then listing parameters in a clear structure. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and parameters, but given that an output schema exists (though not shown), it does not describe the return value or any confirmation message. For a simple action, this is adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining both parameters: proposal_id is 'the numeric ID from get_pending_proposals()' and reason is 'optional note explaining why the proposal was rejected', adding significant context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('reject') and resource ('pending skill improvement proposal'), clearly distinguishing it from siblings like apply_proposal and approve_proposal by stating 'without applying it'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool (to reject a pending proposal) and implies alternatives by contrasting with applying, but does not explicitly name sibling tools or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes what gets deleted (record, tasks, optionally folder) and the safety check. No annotations provided, so burden is on description. Lacks disclosure of irreversibility, required permissions, or response format. Output schema exists but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a clear structure: brief intro, bulleted effects, Args section. No wasted words or redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key behavioral aspects (deletion scope, file safety check) and parameter details. Could add irreversibility warning or permission requirements, but output schema likely covers return structure. Effective given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description adds meaningful context for both parameters: project_id identifies the project, delete_files explains behavior and default value. Adds safety constraint for file path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool removes a project entirely, deleting the project record and associated tasks, with an option to delete files. Distinguishes from siblings like archive_project and delete_task by specifying destructive action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (permanent removal) and includes a safety check for file deletion. Does not explicitly state when not to use or compare to alternatives like archive_project, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses destructive behavior ('erases all recorded preference signals') but could be more explicit about irreversibility or side effects. No annotations exist to shift 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, no fluff. Every word is necessary and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no annotations, the description covers the essential effects. Could mention whether the action is reversible or if any confirmation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters (0 params, baseline 4). The description adds context about what resources are affected (events and yaml), compensating for the absence of parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('clear all thinking_profile_events and reset thinking-profile.yaml to defaults') and resource, distinguishing it from siblings like 'update_thinking_profile' or 'record_thinking_event'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for resetting to defaults but lacks explicit guidance on when to use vs. alternatives (e.g., 'update_thinking_profile') or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses file write destination (`knowledge/courses/{slug}/course.json`) and state advancement (to Step 5). However, it omits side effects, error handling, permissions, or validation behavior. For a mutation tool with no annotations, this is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus argument list. Front-loaded with purpose and step. No redundant information. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists (though not shown) so return value documentation is not needed. Description explains the step context and file writing. Lacks details on error cases or input validation, but is sufficient for a simple 2-param tool within a larger workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description adds essential meaning: slug as course identifier, curriculum_json as JSON with modules and lessons arrays. This compensates for empty schema descriptions. Could be strengthened by detailing the structure of modules and lessons.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Save' and resource 'approved curriculum design for a course'. Identifies as Step 4 in a workflow, distinguishing it from sibling tools like save_course_outline (earlier step) and save_course_sources (different content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Call this after the Learning Architect has produced the curriculum.' Provides context on when to use, but lacks when-not-to-use or alternatives. Workflow context (Step 4) helps agents understand ordering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It states the tool saves the outline and advances if approved is True. However, it does not explain side effects (e.g., overwriting), validation of input, or error conditions. The behavior is adequately described but lacks detail on edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an initial sentence, then 'Args:' and 'Returns:' sections. It is concise overall, though the parameter details could be slightly trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, parameters, and its place in a multi-step process. It mentions a return value ('Confirmation and next-step instructions'), but does not detail validation or error handling. Given the output schema exists, this is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to each parameter: slug is linked to start_course_build, outline_json format is exemplified with module structure, and approved is explained with its effect. Since schema descriptions are absent (0% coverage), this compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Save' and the resource 'course outline'. It specifies the step context ('after Step 2 (Scope Plan)') and that it advances to Step 3. This distinguishes it from sibling tools like save_course_curriculum and save_course_sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call the tool 'once the user has reviewed and approved the module outline' and that 'approved must be True to advance'. This provides clear context, but it does not mention when not to use it or alternative tools for earlier/later steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses behavioral effects (writes YAML files, advances build) but does not cover error handling, idempotency, or prerequisite steps. Adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with front-loaded purpose, clear structure, and no unnecessary words. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no annotations, and presence of output schema, description explains input format, effect, and pipeline position. Lacks error scenarios but is otherwise complete for a simple save tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description adds meaning: explains slug as course slug and sources as JSON array with required fields and an example. Significantly compensates for schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Step 3 — Save harvested source metadata for a course' with a specific verb and resource, and clearly distinguishes from sibling tools like save_course_curriculum and save_course_outline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Call this after the Content Harvester has collected materials', providing a clear precondition, and mentions that the build advances to Step 4, indicating sequence. Does not explicitly say when not to use, but the pipeline context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions 'write-through guarantee' and 'content (truncated to 2000 chars)', adding useful context. However, it does not describe success/failure behavior, idempotency, or what happens on duplicate events.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose, followed by usage guidance, event types, and parameter explanations. 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not shown), the description provides adequate context for a simple logging tool: when to use, what to provide, and truncation. It could mention error handling or return value, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 explains each parameter: session_id comes from session_bootstrap(), event_type is a category, and content is truncated. It also enumerates valid event types. While it lacks format constraints, it adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Persist one atomic event to session_events (write-through guarantee)'. It provides a specific verb and resource, and distinguishes itself from siblings by specifying it is for atomic event persistence and should be called after every tool call, file write, and classification decision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Call this after every tool call, file write, and classification decision.' This provides clear context, but it does not mention when not to use it or offer alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior fully. It reveals that 'names' skips content reading, 'content' reads specific files, and 'none' returns empty. But it omits details on error handling, permissions, or side effects, which is acceptable but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a one-sentence summary followed by a structured Args section. It is front-loaded with purpose. The Args list is slightly verbose but necessary for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and presence of an output schema, the description covers the essential inputs and behaviors. It lacks edge-case handling (e.g., missing folder) but is sufficient for the intended simple use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description fully explains both parameters: folder_path as absolute path, and scan_type with three enumerated values and their behaviors. This adds substantial meaning beyond the schema's minimal titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Detect a project's purpose from its folder contents.' It uses a specific verb (detect) and resource (project purpose from folder), and distinguishes from siblings like 'scan_project_folder' by focusing on intent detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the three scan_type options with their use cases (fast vs accurate vs manual), providing clear context for when to choose each. However, it does not explicitly compare to alternatives like 'detect_projects' or state when not to use the tool, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 results are inserted into news_briefs with source_type='article' and that the API is free and keyless. However, it does not cover rate limits, response format, error behavior, or what happens if max_results is exceeded. The fallback chain is helpful but behavioral aspects are partially covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a bulleted Args section. Every element adds value: the opening sentence states purpose, the second adds key context (coverage, API, side effect), and the Args map cleanly to the schema. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no required parameters and an output schema exists, the description sufficiently covers the tool's purpose, behavior, parameter semantics, and side effects (insertion into news_briefs). The fallback chain ensures the agent understands default behavior even without explicit user input. This is complete for a data-gathering tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 does so thoroughly: each parameter is explained with defaults and fallback logic for query, days_back, and max_results. The query parameter's fallback chain adds crucial context beyond the schema's type/default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Scan OpenAlex for recent papers matching a query'), specifies the resource (OpenAlex), and clearly distinguishes it from sibling tools like search_semantic_scholar or search_literature. The verb 'scan' combined with 'recent papers' and 'query' leaves no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context on query defaults and the free API, but does not explicitly state when to use this tool over alternatives (e.g., search_literature, search_semantic_scholar). No when-not-to-use or exclusion criteria are given, so the agent must infer from the OpenAlex-specific scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden and discloses that it reads a table, checks file modification times, and updates timestamps. It clearly describes the operations performed, which is sufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences, front-loading the key purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is fairly complete, explaining the process and purpose. The presence of an output schema reduces the need to detail return values. Minor gap: no mention of error cases or output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100% trivially. The description adds no parameter-specific meaning, but the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans tracked files and reports changes since last scan, with details on how it works. It distinguishes itself from siblings like add_tracked_file or full_scan by focusing on scanning only tracked files for modifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking changes in tracked files but lacks explicit guidance on when to use this tool versus alternatives like full_scan or scan_inbox. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions whitespace trimming and return confirmation but lacks detail on permissions, reversibility, or side effects. Adequate for a simple update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and front-loaded: a short summary sentence, usage guidance, and a clean args/returns section. 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers purpose, desired preconditions, parameter details, and return value. The dashboard sorting effect adds useful context. Output schema presence reduces need to explain return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates well. Both parameters are described with examples for category (e.g., 'Article') and indication that whitespace is trimmed. Provides meaningful context beyond field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Assign or change a project's category' using a clear verb-resource pair. It distinguishes from siblings like get_project_categories by calling that tool as a preliminary step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to call get_project_categories first to reuse existing labels, and explains the dashboard sorting effect. Does not include when-not-to-use scenarios 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It notes that the tool reads the database directly (no modifications stated) and imports into literature_metadata with library_source='zotero-local'. However, it does not mention whether imports are appended or deduplicated, nor error handling or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (three sentences) and front-loaded with the core action. It includes a separate 'Args' section for parameter details, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and the presence of an output schema (not shown), the description covers the essential: purpose, alternative, parameter behavior, and target table. It could mention overwrite vs. append, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage with only type and default. The description compensates by explaining db_path meaning and fallback behavior when empty, adding significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports a local Zotero library by reading zotero.sqlite directly, with no API key or network needed. It explicitly distinguishes the tool from its sibling sync_zotero_library by calling it 'the offline alternative'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (no network, no API key) and contrasts it with sync_zotero_library. It also details the db_path parameter and the fallback search behavior. It lacks an explicit 'when NOT to use' but the context is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states it appends to history and updates prompt memory and next_steps. However, it does not explain what 'refresh prompt memory' entails or whether the operation is idempotent, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with no redundant sentences. It uses a clear structure: purpose, usage instruction, then parameter list. The front-loaded purpose immediately conveys the tool's intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and an output schema exists, the description covers the core functionality, usage, and parameter semantics adequately. It lacks details on return values but the output schema fills that gap. Overall, it is sufficiently complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so compensation is needed. The description explains 'what_was_done' as a 1-3 sentence summary and 'next_steps' as optional, updating the next_step field. 'project_id' is described as 'The project slug,' which is sufficient. This adds meaning beyond the schema's titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Append a session summary to a project's history and refresh its prompt memory.' The verb 'append' and resource 'project history' are specific. Among memory-related siblings, the focus on session summaries at session end differentiates it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this at the end of any work session on a project,' providing clear when-to-use guidance. It also explains the benefit (feeds into load_project_context), though it does not discuss when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the key behavioral trait: it writes to system/thinking-profile.yaml. It also notes safety for repeated calls, indicating no destructive side effects. The mutation is clear, and no contradictory information is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two short paragraphs, first stating purpose, second listing computed fields in a bullet-like style. No unnecessary words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown but signaled), the description does not mention what the tool returns (e.g., success message or updated profile). However, the computed fields are well-described. A brief note on return value would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so schema coverage is 100%. The description adds meaning by explaining what the tool computes, but does not need to elaborate on parameters. Baseline is 4 because no parameter documentation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recomputes and updates the thinking profile from the last 90 days of events, listing three computed components (connection_preferences, preferred_idea_sources, agent_feedback). This distinguishes it from siblings like get_thinking_profile (read-only) and reset_thinking_profile (reset to default).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Safe to call multiple times,' implying idempotent usage, but does not explicitly state when to use this tool vs alternatives (e.g., reset_thinking_profile, get_thinking_profile). Guidance is minimal and implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description bears full burden. It discloses auto-tag extraction, domain/project linking, and cross-pollination behavior. Could mention if other tables are modified, but overall adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with main action, and uses an Args section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return values need not be described. Covers core functionality, side effects, and parameter details. Could mention content length constraints but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaningful context for all 4 parameters: content as idea text, source with default, image_path optional, and auto_cross_pollinate with behavior explanation. Fully compensates for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Store an idea in the SQLite ideas table' with specific verb and resource. Distinguishes from siblings like add_memory_entry and capture_observation by mentioning auto-tagging and cross-pollination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for capturing ideas with automatic connections, but no explicit when-not-to-use or alternatives. The cross-pollination feature is highlighted, but no guidance on when to disable it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It explains the comparison operation and return format but does not disclose whether the tool is read-only, potential side effects, error conditions, or performance implications. Basic behavioral traits are covered but not comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured: first sentence summarizes purpose, then explains inputs, then outputs. Uses clear formatting with bullet points for return fields. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (not shown), description covers the key aspects: inputs, outputs, and usage. It could mention prerequisites (e.g., need to call profile_dataset first) but overall is adequate for a focused diff tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet description adds full context: each parameter (before_profile, after_profile) is described as a JSON string from profile_dataset() and explains their roles. This compensates entirely for the lack of schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool compares two dataset profiles and produces a side-by-side diff. It lists specific outputs like rows added/removed, columns added/removed, null count changes, type changes, and a human-readable summary. This distinguishes it from sibling tools such as profile_dataset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to pass JSON strings from profile_dataset() and describes the arguments and return value. While it doesn't explicitly state when not to use or list alternatives, the usage context is clear and specific enough for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the call is authenticated, automatically prefixes '/api/', and allows GET/POST/PUT with a body. This clarifies the tool's behavior beyond a simple query, including mutation potential. However, it does not mention rate limits or error handling, which would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Examples) and a concise first sentence that captures the core purpose. While slightly longer than minimal, every sentence adds value. No redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (implied), the description need not detail return values. It covers parameter details, usage context, and provides examples, making it self-contained for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully with detailed parameter explanations and examples. It explains 'endpoint' format, 'params' as a dict with examples, 'method' default and options, and 'body' usage. The examples further clarify common usage patterns, making parameter semantics very clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool makes an authenticated API call to a DHIS2 instance and returns JSON. It lists specific use cases (metadata validation, data element lookup, etc.), which distinguishes it from generic API tools. The verb 'Make' and resource 'API call to the configured DHIS2 instance' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests appropriate use cases ('Use for live metadata validation...') but does not explicitly state when to avoid this tool or compare it to alternatives like the sibling tool 'dhis2_metadata'. This lack of exclusion criteria or alternative guidance limits its usefulness for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the computation (duration from start_ms to now) and return format. However, it does not mention side effects on a span store or error handling for invalid span_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with a bullet list for args. Front-loaded purpose. No redundant information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity and presence of output schema, the description explains return format and parameter usage. Minor gap: no mention of error handling or behavior when span_id is invalid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 provides complete descriptions for all three parameters, including use of span_id from start_span(), valid status values and default, and error condition. This fully adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Close an open span' and 'Computes duration from start_ms to now', specifying the verb and resource. It distinguishes from siblings like 'start_span' and 'log_span' by focusing on closing and timing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after 'start_span' but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, leaving the agent to infer context from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations provided, description carries full burden. Clearly indicates read-only behavior (retrieve, returns log). Describes output format and ordering (newest first). Lacks explicit safety or authorization notes, but for a get tool the behavior is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured. First sentence states purpose, second explains what it returns, third gives relationship to log_agent_run, then bullet-style args. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: what it does, parameters, return format (text block with fields). Output schema exists but description still lists fields. Could mention pagination or error cases, but for a simple retrieval it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides only titles and defaults (0% coverage), but description includes an 'Args' section explaining each parameter in detail: limit (max count, default 10), since (ISO date/datetime, empty for all), agent_slug (filter by slug, empty for all). This adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves recent agent run history from the database. Uses specific verb 'Retrieve' and resource 'agent run history'. Distinguishes from sibling tools like log_agent_run (write) and other get_* tools by focusing on runs and specifying results order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions usage 'for the dashboard or for reviewing recent activity' but does not explicitly state when not to use or compare with alternative tools. No exclusion criteria or guidance on selecting this over similar tools like search_memory or list_recent_sessions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains that parameters are optional and lists the return fields (status, steps, modules, next action), but does not disclose potential side effects, authentication needs, or rate limits. Adds some value but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. It front-loads the main action in the first sentence and then uses a clean Args/Returns structure. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (as per context signals), the description adequately covers the tool's purpose and return structure. The single optional parameter is fully explained, making the tool complete for its intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'slug' is explained in the description as 'Course slug. Leave empty to list all active builds', which adds meaning beyond the minimal schema (just a string with default). Compensates for the 0% schema description coverage well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the current status of a course build, with the ability to list all active builds when slug is empty. This distinguishes it from sibling tools like start_course_build, publish_course, and review_course.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage tip (leave slug empty for all active builds) and implies the tool is for checking status. However, it does not explicitly mention when not to use it or alternatives, but for a simple query tool, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the output composition (entry counts, coverage map, etc.), implying a read-only operation. However, it does not explicitly state that no side effects occur or mention any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose and a compact list of outputs. Every sentence earns its place, and critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema (not visible but signaled), the description fully explains what the tool returns. There is no missing information for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, earning a baseline of 4. The description adds value by detailing the return structure, which goes beyond the minimal schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a 'health report for the memory palace' and lists the specific outputs (entry counts, coverage map, gaps, duplicates, provenance). This distinctively differentiates it from sibling tools that add, search, or manage individual memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a health overview but does not explicitly state when to use this tool versus alternatives like search_memory or get_related_memories. No when-not or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the default return value ('normal') when no policy file exists, which is useful behavioral context. However, it does not mention side effects or permissions, which are minimal given the 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose with no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, no parameters, and existence of an output schema, the description sufficiently covers what the tool does and its default case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters (schema coverage 100%), the baseline is 4. The description adds no parameter info because there are none, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the current network access policy, with a verb ('Return') and specific resource, distinguishing it from the sibling 'set_network_policy'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies read-only usage but does not explicitly state when to use it over alternatives or provide exclusions. The context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the core behavior (registering a project) and conditional behavior based on the 'write_config' parameter (write directly vs. return instructions). However, it does not mention potential side effects, permissions required, or what happens if the project ID already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with no filler. It opens with a clear purpose statement followed by a structured argument list. Every sentence adds value, and the formatting is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and an output schema (not shown but present), the description is mostly complete. It explains both parameters and the conditional output. Missing minor details like error states or idempotency, but adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The description adds complete semantics: 'project_id' is identified as 'The Metis project ID to register' and 'write_config' is explained with its conditional effect. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Register a Metis project in Claude Desktop's project list.' The verb 'register' combined with the resource 'Metis project' and target 'Claude Desktop's project list' provides a specific and unambiguous purpose, distinguishing it from other project-related tools like create or load.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives like 'connect_project_folder' or 'create_project'. It provides basic parameter explanations but lacks context on prerequisites, expected usage scenarios, or conditions where manual setup is preferred. Usage is implied but not clearly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that private/ subfolder is never listed, adding behavioral context beyond a basic read operation. No annotations exist, so description carries full burden; it could mention read-only nature explicitly but does not mislead.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, each purposeful: first states core function, second adds critical exclusion. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completely describes a simple list tool with no params and an output schema; explains the basket concept and privacy constraint, sufficient for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist in the schema, and schema coverage is 100%. Baseline of 4 applies; description adds no param info as none required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb+resource ('List files in the Metis basket') and distinguishes from sibling tools like 'list_folder' by defining the basket's role (legacy & inspiration documents) and explicitly excluding the private/ subfolder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for listing basket files and notes the exclusion of private data, but does not explicitly compare to other list tools or provide when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies a read-only operation and recency ordering, but does not explicitly state read-only nature, permissions, or memory scope (global vs session). Adequate but could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus arg detail. Every sentence adds value. Purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, and parameter. Output schema exists to define return structure. Lacks specificity on memory scope (e.g., session vs persistent), but sufficient for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage for parameter 'n'. Tool description fully explains 'Number of entries to return (default 10)', adding essential meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Return the n most recent memory entries' with a clear verb and resource. The use case 'start of a session' distinguishes it from search or topic-specific siblings like search_memory or get_topic_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly suggests use 'at the start of a session to recall what was last worked on'. However, no explicit when-not-to-use or alternatives are mentioned, though sibling differentiation is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately discloses behavior: it returns a JSON object with specified fields. It does not mention side effects, but none are expected for a read-only list tool. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary words. The first sentence front-loads the action and subject, making it efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description covers all essential aspects: what is listed and the return structure. No further context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%. The description adds value by detailing the return format (extensions, capabilities, versions), which is absent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists supported dataset formats and library versions, with specific verb 'List' and resource. It differentiates from sibling tools like get_library_stats by focusing on formats and versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide when to use this tool versus alternatives or any exclusions. Usage is implied as a straightforward informational listing, but explicit context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool lists tool groups and includes a count of parked ones, adding behavioral context beyond a simple 'list'. It does not mention side effects, but for a read-only list this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the core functionality without any unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description fully captures what the tool does: listing tool groups with parked counts. No further context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%. The baseline for zero parameters is 4; the description adds no additional parameter info, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'list' and the resource 'tool groups that can be loaded on demand'. It adds a specific detail about counting parked groups, which distinguishes it from siblings like 'load_tool_group'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives (e.g., load_tool_group). While the purpose is clear, no guidance on conditions or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool returns context_doc, session history, and next step. However, it does not disclose whether the tool is read-only, requires permissions, or has side effects. The description is truthful but lacks depth regarding 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences of purpose and one for the parameter. Every sentence adds value, and critical info is front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers all necessary aspects: purpose, return values, usage timing, and parameter details. It is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds a meaningful docstring for the single parameter, including a format example. Schema coverage is 0%, so the description compensates well by explaining the parameter's purpose and expected value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool loads the full context block for a project, specifying the verb 'load', the resource 'project context', and the purpose 'ready to paste into Claude'. It distinguishes from sibling context tools by focusing on project-specific context with a structured brief.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends use at the start of any work session on a specific project. Provides clear context but does not mention when not to use or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions that an empty category returns all categories, which is a useful behavioral detail. However, it does not disclose whether the operation is read-only, any required permissions, or what the response contains beyond the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: it states the purpose, then usage context, then parameter descriptions. Every sentence is necessary, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to detail return values. It covers purpose, usage, and parameters adequately. However, it could mention that it returns only user-recorded decisions, which is implied but not explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains both parameters: category ('filter to one category, or \'\' for all') and limit ('max rows'). This adds essential meaning beyond the schema's type and default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool recalls recorded preferences/decisions for personalization, using the specific verb 'recall' and resource 'preferences/decisions'. It also notes it is called during context assembly, distinguishing it from sibling tools like 'remember' or 'write_user_preferences'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use: 'during context assembly (and any time Metis is about to act in a way a preference might govern)'. It does not provide exclusions or alternatives, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full responsibility for behavioral disclosure. It explains the conditional logic (check for active session, resume or create), the return of last 5 events or seeding from memory, and the required client parameter. It does not mention side effects like database writes or error handling, but the disclosed behavior is sufficient for most use cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a clear header and bullet-like structure. Every sentence adds value: purpose, conditional logic, and parameter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description need not detail return values, but it still mentions returning last 5 events or seeding context. It covers the core behavior well, though it could mention error scenarios or prerequisites like a valid computer identifier.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'client' has a default in the schema but no description or enum. The description adds explicit allowed values ('code', 'chat', 'cowork', 'dashboard'), which is critical for correct invocation. This significantly adds meaning beyond the schema, especially with 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Find or create a session for the current computer.' It uses a specific verb ('find or create') and resource ('session'), and distinguishes itself among siblings by being the only bootstrap tool. The detailed conditional logic (resume vs create) adds further clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a first step ('Stage 1') but does not explicitly state when to use or not use this tool, nor does it compare to alternatives. While the context suggests it's a prerequisite, the lack of explicit usage guidance lowers the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: ephemeral, session-only persistence, no vector search indexing. Since no annotations exist, the description fully covers behavior. Could mention whether existing keys are overwritten or the value scope size limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a concise paragraph followed by bulleted arguments. No redundant sentences. Could be slightly more concise by removing 'any string, JSON, or text' redundancy, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the tool's purpose, usage context, and parameter meanings. With an output schema present, return values need not be explained. Lacks usage examples or edge cases, but sufficient for a simple write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description compensates by explaining each parameter: session_id as pipeline session ID, key as variable name with examples, value as any string/JSON/text. Adds meaning beyond schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a key/value pair to working memory, specifying the action ('write') and resource ('working memory'). It distinguishes from sibling tools like 'get_working_memory' and 'remember' by emphasizing ephemeral, session-scoped storage not indexed for search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for state needed mid-pipeline (intermediate results, decisions). Contrasts with vector search, implying when not to use (for persistent or searchable data). Provides clear context but could state exclusions more directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately discloses that the tool creates a span and returns an identifier. It notes the need to call end_span, which is a key behavioral trait. Could mention potential side effects (e.g., memory/performance) but the simplicity of the operation makes this sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence followed by a bullet-style Args list and a Returns line. It is somewhat verbose given the tool's simplicity, but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which likely defines the span_id return type), the description covers all necessary context: purpose, parameter details, return value, and the required follow-up call (end_span). It is complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter's meaning, defaults, and examples (e.g., 'name: Human-readable span label... kind: Span type...'). This adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Open a new tracing span') and the resource ('span'), and distinguishes it from sibling tools like 'end_span' and 'get_spans' by focusing on creation and returning a span_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage flow (pass span_id to end_span) but does not explicitly state when to use this tool versus alternatives, nor does it provide conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It describes sync behavior (incremental vs full) and environment requirements, but does not disclose potential side effects (e.g., overwrites, destructive actions) or rate limits. Adds value but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with purpose, then details. Every sentence is informative with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects, output schema exists), the description covers sync behavior, parameter usage, and prerequisites. Lacks error handling details but adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the 'full' parameter's effect (re-sync all items). Single parameter is clearly described, adding meaning beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool syncs Zotero library into Metis literature_metadata, with a specific verb 'sync' and resource, and distinguishes between incremental and full sync modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage guidance on the default incremental sync and how to trigger full sync with the 'full' parameter, plus mentions required environment variables. Lacks explicit differentiation from sibling tools like sync_zotero_local.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that it rejects missing or empty keys and treats output with suspicion. However, it does not state whether the tool is read-only or has side effects, but the validation action implies no mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a clear first sentence followed by a brief explanation and Args section. The inclusion of version number 'M5.7.4' is minor noise but does not detract significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It covers the tool's purpose, parameter semantics, and validation behavior, making it reasonably complete for a simple validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining both parameters: output_json is a JSON string of the sub-agent output dict, and required_keys is a comma-separated list. This adds meaning beyond the schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates a sub-agent output before passing to the next pipeline stage, using specific verb 'validate' and resource 'pipeline stage'. It distinguishes from siblings by focusing on validation between stages, which is unique among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it before passing output to the next stage and treats output with suspicion like external tool output. It does not mention when not to use or list alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 describes the tool as a write operation (recording an entry) and provides context about post-processing (review loop). However, it does not specify whether the tool is append-only, if it requires specific permissions, or if there are limits like one entry per run. For a logging tool, this is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a purpose header, a contextual paragraph, and a bullet list of parameters. No unnecessary words. Every sentence adds value. The key information is front-loaded, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 0% schema coverage, no annotations, and the existence of an output schema (not shown), the description covers all parameters and use case. It explains the downstream use (review by Coach loop). It does not explicitly mention return values, but the output schema likely handles that. A minor gap is not stating if the entry is saved immediately or if failure handling exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no descriptions in input schema), so the description carries full burden. It lists all 6 parameters with clear explanations: session_id is 'Pipeline session ID from session_bootstrap()', agent_slug is 'Which agent is writing the reflexion', and the three optional text fields are described with their 1-2 sentence length guideline. This adds substantial meaning beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The tool's purpose is clearly stated: 'Record an agent self-critique entry to the reflexion_log'. It specifies it is called at the end of every agent run to capture experience. This verb+resource combination distinguishes it from sibling tools like log_agent_run or add_journal_entry, which serve different logging purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Called at the end of every agent run'. It also explains the downstream use: entries are reviewed by the weekly Coach loop for self-improvement. While it doesn't explicitly list when not to use it or compare with alternatives, the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: writes to skill.md, marks as approved, creates backup. No annotations provided, so description carries full burden. Could mention failure modes or return value, but output schema exists to cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences plus an Args section. Every sentence provides necessary information without redundancy. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (single required parameter, output schema exists), the description covers the essential action and side effects. Could mention that the proposal must be pending, but this is implied by the purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning to the sole parameter 'proposal_id' by specifying it is 'The numeric ID from get_pending_proposals()', guiding the agent on how to obtain the correct value. Schema only says integer, so this adds significant value despite 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'approve' and the resource 'pending skill improvement proposal'. Distinguishes from siblings like 'reject_proposal' and 'propose_skill_improvement' by specifying that it applies the proposal by writing to skill.md and marking as approved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides clear context that this tool is for approving proposals from get_pending_proposals() and mentions the backup creation. It doesn't explicitly say when to use vs alternatives, but the purpose is self-evident given the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the transparency burden. It explains that the tool walks the folder recursively, adds files with recognized extensions to a `tracked_files` table, and includes a safety limit (max_files). This is adequate disclosure for a registration operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a clear separation of purpose, behavior, and parameter details. It is slightly repetitive in the first two sentences, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity, the description covers the tool's purpose, usage flow, parameter meanings, and behavioral constraints. An output schema exists, so return values are documented separately. It lacks error scenarios but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides detailed explanations for each parameter: folder_path (absolute path), label (short label with example), and max_files (safety limit with default). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Register all relevant files in a project folder so Metis can read them.' It lists recognized extensions and distinguishes from the sibling tool `read_file()` by noting this is a one-time setup operation per project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this once per project; after that, use read_file() to read any individual file.' This gives clear usage context and suggests an alternative, though it does not explicitly mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses idempotency, deduplication, and the 7-day working memory pruning threshold. However, it omits authorization requirements or side effects like potential data loss, though the details given are substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences of functional explanation plus one for idempotence. No filler, key information front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are covered. The description explains the core transformation (reflexions to semantic nodes, pruning) and key constraints (count threshold, dedup, window). Missing minor details like error states or performance implications, but overall sufficient for a knowledgeable agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains both parameters: min_count and days are directly referenced in '>= min_count times in the last `days`'. This adds meaning beyond the bare schema, though it could be more explicit about default behaviors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb-resource pair: 'distil recurring reflexion themes into semantic memory' and 'prune working memory'. It uses specific terms like 'min_count' and 'days' to define scope, distinguishing it from sibling consolidation tools like consolidate_old_memories and consolidate_session_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Runs the nightly self-improvement consolidation', indicating it's a periodic maintenance task. While it doesn't list when not to use it or alternative tools, the context is clear enough for an agent to infer appropriate scheduling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool creates a DB record and makes the project available for linking and memory search, but does not mention error handling (e.g., duplicate titles), permissions, or side effects. This is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence overview, a usage context sentence, an effect sentence, and a clear 'Args' list. No unnecessary words, and critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (4 parameters, 1 required) and the presence of an output schema, the description adequately covers the behavior (record creation, UI appearance, linking capability). No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by explaining each parameter: title (human-readable name with example), description (one sentence), domain (with examples), and source (with allowed values). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('register a new project'), the resource (Metis platform), and the effect (creates DB record, appears in Work tab). It distinguishes from siblings like create_project_full by implying this is the standard project creation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear scenario for when to call the tool ('when a researcher confirms they want a Claude conversation or project tracked permanently'). It does not explicitly mention when not to use or alternatives like create_project_full, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses that the tool returns a verdict (OK/REVIEW), the preferences to honor, and detected conflicts. It explains how to handle REVIEW results. With no annotations, the description carries full burden and does well, but could elaborate on edge cases (e.g., missing layers).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: first sentence states purpose and timing, second explains output, third defines args. Every sentence adds value, no fluff, and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (implied by context signals), the description appropriately omits return value details. It covers what the tool does, when to use it, how to handle output, and parameter purposes. Could mention prerequisites (e.g., existing layers) but implicit in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds meaning to each parameter: 'answer: your drafted answer text', 'session_id: current session (optional)', 'task_type: optional routing task_type for narrower preference recall'. This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Stage 6 — the evaluate gate' that 'checks the answer against the user's layers'. It specifies the verb (evaluate/check) and the resource (drafted answer against layers). Distinct from sibling tools by being a specific pipeline stage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'BEFORE you reply to the user, pass your drafted answer here' and 'Resolve REVIEW items before replying'. Provides clear context for when to use and what action to take on output, though no explicit alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool makes no LLM calls and is safe, but it does not detail potential latency or side effects. The step breakdown adds trust.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short paragraphs. The numbered list of steps is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema, the description adequately covers the tool's purpose and behavior. It could mention error handling or time expectations but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain any. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs all Metis update scans in sequence and returns a combined report, listing four specific scan types. This distinguishes it from individual scan tools like scan_news and scan_literature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it is safe to run at any time and makes no LLM calls, implying it can be used freely. However, it does not explicitly contrast with separate scan tools or state when to use the full scan vs. individual scans.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses reading two files and the fallback of listing agents if not found. It does not overtly state it is read-only, but the behavior is clear enough for an agent to infer safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences plus an Args list, all directly informative. No wasted words, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and an output schema (not shown but present), the description adequately covers the tool's action and error case. It does not repeat schema details, leaving return format to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'agent_slug' has no description in the schema (0% coverage), but the description adds meaning by defining it as the folder name and providing examples. This compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Load') and resource ('agent's system prompt and contract'), and distinguishes from sibling 'get_*' tools by specifying it reads two specific files from an agent folder. It also notes a fallback behavior if the agent is not found.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the tool's purpose (loading an agent's system prompt and contract) and includes an error-handling behavior. However, it does not explicitly compare to alternatives like 'get_context' or specify 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool creates a link, returns confirmation or error if the link already exists, and builds a knowledge graph. It does not specify permission requirements, existence checks on source/target, or directionality, but these are relatively minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise purpose statement, context about layers and knowledge graph, example relations, then a clean Args list, and finally return value. Every sentence adds value, and it is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations, has output schema), the description covers essential aspects: layers, relation types, parameter explanations, return behavior. No further details (e.g., rate limits) are necessary for a simple link creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the tool description provides a detailed Args section explaining each parameter (source_layer, source_id, etc.), including example relation types. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a typed relationship between two memory entries,' specifying the verb (Create), resource (typed relationship), and context (memory entries across episodic, semantic, etc., layers). It distinguishes from siblings like 'remember' or 'store_episodic_memory' by focusing on linking rather than storing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's purpose and the layers involved, but does not explicitly state when to use it vs. alternatives or when not to use it. No exclusions or alternative tools are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return format (list of dicts with specific keys) and error case (single-item error list). However, it does not mention any additional behavioral traits like rate limits, authorization requirements, or side effects. For a simple list operation, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at around 150 words, with clear sections (purpose, usage, args, returns). Every sentence adds value, and there is no repetition of schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (one optional parameter), no annotations, and an output schema, the description is complete. It covers purpose, usage context, parameter semantics, return structure, and error handling. It also references sibling tools for comparison.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is 'limit,' with type integer, default 20. The description adds meaning: 'Maximum number of summaries to return, most recent first (default 20).' Since schema description coverage is 0%, the description fully compensates by explaining default behavior and ordering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List the most recent session summaries, newest first.' It specifies the verb (list), resource (session summaries), and ordering (newest first). It distinguishes from sibling tools by mentioning complementary tools like search_session_memory and save_session_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool, such as 'to pick up where a previous conversation left off or review recent decisions and topics.' It also notes that it complements search_session_memory and save_session_summary, providing context for selection. While it lacks explicit when-not-to-use guidance, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries transparency. It discloses the tool never modifies the source file, performs a non-blocking PII column name scan, and returns a JSON structure with specific fields. This provides good insight into behavior, though no mention of permissions 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 10 lines), with a clear structure: purpose statement, supported formats, behavioral notes, and an Args section. Every sentence adds value; no fluff. Front-loaded with main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (though not shown) and only two simple parameters, the description covers essential aspects: supported formats, safety, PII scan, and return structure. It does not elaborate on every output field but that is acceptable with an output schema present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameter descriptions in the tool description are critical. The description provides clear explanations: 'path' as absolute local path, 'sample_rows' as including rows in output if > 0. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the verb 'Profile' and the resource 'tabular dataset', detailing specific outputs (shape, dtypes, null %, unique counts, distributions). It also lists supported formats and a PII scan, clearly differentiating from sibling tools like clean_dataset (which modifies) and compare_profiles (which compares).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description indicates when to use by specifying supported file formats and emphasizing it never modifies the source file, implying safe profiling. While it does not explicitly contrast with alternatives, the context of sibling tools makes the tool's role clear. No explicit 'when not to use' statement, but the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It covers filtering behavior and defaults but does not explicitly state that the tool is non-destructive or read-only. The behavioral traits are mostly clear, but some aspects (like side effects) are implied rather than stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise one-sentence summary, followed by a brief behavioral paragraph, then parameter documentation. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (returns not needed), the description covers purpose, parameters, and behavior completely. It explains the superseded concept and filtering options, leaving no obvious gaps for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides clear, detailed semantics for all three parameters: entity (partial match), since_date (ISO format), show_superseded (boolean, defaults to False). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'query' and resource 'research beliefs', highlighting temporal evolution and superseded claims. It clearly distinguishes this tool from siblings like search_memory or get_research_context by focusing on chronological ordering and belief history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains default behavior (superseded hidden) and when to show them (to trace reasoning). It implies context for usage but does not explicitly state when to prefer alternatives. Good but could be more thorough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: records timestamped beliefs, preserves a timeline, and explains the supersedes_id mechanism. It lacks details on permissions or error handling but discloses the core traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a summary and usage context, followed by a structured parameter list. It is slightly long but each sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no annotations, the description covers all inputs comprehensively, explains the timeline feature, and mentions superseding. It does not discuss output format, but an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides detailed explanations for all 7 parameters, including usage guidance (e.g., consistent entity names, confidence values, source types). This compensates for the 0% schema coverage, adding significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Record a timestamped research belief or finding about an entity,' using a specific verb and resource. It distinguishes from siblings like 'record_decision' and 'capture_idea' by focusing on research findings and the timeline of reasoning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this whenever you reach a conclusion, update a previous belief, or encounter evidence that changes your view.' It does not explicitly contrast with siblings, but the purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses key behaviors: scope='always' persists permanently with high priority, scope='once' is acknowledged but not stored, and the priority default beats seeds. It does not mention what happens with conflicting rules, but is transparent enough for the tool's simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, around 100 words, with a clear introductory sentence followed by a structured Args list. Every sentence contributes meaningful information, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (not shown but noted), the description provides sufficient context. It covers the core behavior and parameters, though some edge cases (e.g., duplicate rules) are left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It explains each parameter: phrase (trigger word), agent_slug (target agent), scope ('always' vs 'once'), and priority (lower = more specific, default 5 beats seeds). This adds significant value beyond the schema's type/default information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: recording the user's answer to Metis' routing preference question. It specifies the verb ('call this with their answer') and the resource (the routing preference). This distinguishes it from sibling tools, which are mostly unrelated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: after Metis asks the routing question. While it doesn't list alternatives or when not to use it, the context is very specific and leaves little ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behaviors: recursive directory walk, domain tagging, title-based deduplication. However, it doesn't specify what happens to duplicates (skip? overwrite?) or mention any authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences. Every sentence adds value: purpose, behavior details, and safety guarantee. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description covers main points (location, action, safety, dedup). Could mention supported file types beyond PDFs or behavior on existing entries, but it's largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the baseline is 4. The description adds operational context (subdirectory walk, tagging) that compensates for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('scan') and resource ('inputs/literature/ for new PDFs') and action ('register them in literature_metadata'). It clearly distinguishes from sibling tools like 'scan_folder_for_intent' or 'scan_news' by specifying the target directory and file type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that it walks all subdirectories, uses parent folder as domain tag, and deduplicates by title, making re-runs safe. While it doesn't explicitly contrast with alternatives, the context is clear enough to guide appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the action (checking for PII) and the return values (verdict, found, masked), but does not explicitly state whether the tool is read-only or if it has side effects. Given no annotations are provided, more explicit disclosure about safety traits would be beneficial, but the description still conveys core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (6-7 sentences), well-structured with a title, explanation, and a returns section. Every sentence adds value, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single input and a documented output schema (returning JSON with safe, found, masked), the description explains the output structure inline. It is complete and covers all necessary aspects for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'text', is clearly described in the description: 'The drafted response text to check.' This adds meaning beyond the schema, which only provides type and title. Since schema description coverage is 0%, the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'check a drafted response for leaked PII before it's sent.' It uses specific verbs and nouns ('check', 'drafted response', 'PII'), and distinguishes itself from sibling tools like 'check_data_safety' or 'scan_inbox' by emphasizing the output rail and complementing the read-side hook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs agents to call this on 'any response that might contain individual-level data' and mentions it enforces the constitution's rule. While it does not explicitly state when not to use or list alternatives, the context is clear and sufficient for deciding when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that previously tool-filled rows are replaced while user-curated or hand-added items are preserved. It also mentions the absence of an RSS source and that the tool is designed for Claude Desktop on the user's subscription (no API rate limit), providing key operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections, including a purpose statement, usage context, behavioral note, and structured parameter definitions. It is concise yet comprehensive, with every sentence serving a purpose. Minor redundancy exists (e.g., 'on the user's subscription, no API rate limit' could be integrated more smoothly), but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 adequately covers the tool's purpose, parameters, return format, and behavioral traits. It explains the niche use case (boards without RSS, desktop-only update method) and the replacement logic. The return value is described concisely, though it could be slightly more detailed about failure modes. Nonetheless, it is sufficiently complete for an AI 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate fully. It does so by defining the 'board' parameter as either 'events' or 'funding', and detailing the 'items' parameter as a list of objects with specified fields (title, url, optional date, optional description). It also includes usage guidance like 'Only include real items with a working http(s) URL', adding crucial semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool fills a Today-surface board (Events or Funding) with web-found items, precisely defining each board's content (congresses/conferences vs. funding calls). It distinguishes itself from sibling tools by specifying the unique use case (boards without RSS sources) and the replacement behavior (preserving manual entries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool after web-searching for the researcher's field and explains that it is invoked via the dashboard's 'Update with Claude' buttons. While it does not explicitly list when not to use or enumerate alternatives, the context is clear enough for an AI agent to infer appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses the regex-based nature, no execution, no data access, and no LLM exposure. It does not cover error handling or side effects, but the output schema covers return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short paragraphs plus an Args section. Every sentence adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description is complete. It explains the extraction method, limitations, and safety aspects, leaving no obvious gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'path' has 0% schema description coverage, but the description adds crucial context: 'Absolute path to the script file (.R, .Rmd, .qmd, or .py).' This specifies format and absolute path requirement, adding significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it parses R or Python scripts and extracts structured metadata. The verb 'parse' and resource 'script' are explicit, and it distinguishes itself from sibling tools by focusing on static analysis without execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains that parsing is regex-based with no execution, no AST, no data access, and code is not sent to an LLM. This provides clear guidance on when to use the tool safely, though it doesn't explicitly list alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently describes that the project's status is set to 'archived', data is kept, and visibility changes. It does not mention side effects or reversibility, but the 'unarchive_project' sibling partially addresses that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a parameter listing. All information is relevant and front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and existence of an output schema, the description covers the essential aspects: what the tool does, the effect on data availability, and the parameter. It is fully adequate for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description includes an 'Args' section that explains the required 'project_id' parameter. This adds meaning beyond the schema, though it could provide more detail (e.g., format or example).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Archive a project — marks it inactive but keeps all data.' It uses a specific verb ('archive') and resource ('project'), and distinguishes itself from siblings like 'remove_project' and 'unarchive_project' by clarifying that data is preserved and the project remains available for context and search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the effect ('disappears from active view but remains available for brainstorm context and search'), implying when to use it. However, it does not explicitly state when not to use it or compare with alternatives like 'remove_project'. The guidance is clear but could be more explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool fetches relevant ideas, notes, questions, and library notes, lists five steering modes with their meanings, explains session continuation via session_uuid, and describes the return format including session_uuid, turn_number, context, steering_prompts, and instructions. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary sentence, usage instruction, enumerated steering modes, and a parameter list. Every sentence adds value, though the parameter list could be more concise. Overall, it's appropriately sized for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (iterative brainstorming with multiple steering modes) and the presence of an output schema (mentioned in description), the description is complete. It covers purpose, when to use, all parameters with semantics, steering modes, session management, and return value fields. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains each parameter: topic (the brainstorm topic), steering (with explicit list of allowed modes), session_uuid (continuation vs new session), and turn_notes (optional notes). This adds complete semantic meaning beyond the schema's minimal type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run one turn of a brainstorm session, returning relevant context.' It specifies the verb and resource, and distinguishes from sibling tools like get_brainstorm_session and save_brainstorm_output by focusing on iterative turns with steering modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Call this at the start of a brainstorm and after each steering action.' This clearly indicates when to use. While it doesn't explicitly list when not to use, the context makes it clear this is for iterative brainstorming, and siblings cover other phases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It discloses no modification of original, authorization gate, and lists all supported operations with format examples. Returns expected output fields are noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, uses bullet points for operations, clearly highlights authorization. Slightly verbose but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema provided, description covers all necessary behavioral and operational details: never modifies original, authorization gate, all operations, parameter semantics. Fully equips agent to use tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description provides detailed meaning for each parameter: path (absolute path), authorized (boolean with auth flow explained), operations (list with examples), output_path (default behavior when empty).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Apply cleaning operations to a dataset and write a new file' with a specific verb and resource. It distinguishes from siblings by focusing on execution vs. suggestion (suggest_cleaning) and other data tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly explains never modifies original, always writes to output path, and authorization requirements. However, lacks explicit when-to-use vs. alternative tools like suggest_cleaning or profile_dataset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool enforces at least one decision, writes to episodic memory, and requires concrete decisions. It does not mention side effects or permissions, but provides adequate transparency for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a clear front-loaded purpose, usage note, and parameter list. It is slightly verbose but every sentence adds value. Could be slightly more concise, but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description covers the tool's role, when to call, parameter details, and storage behavior. It provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains the decisions parameter with examples, notes summary's optionality, describes key_topics as tags, and session_id as optional. This adds significant meaning beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'commit', the resource 'key decisions from this session', and explicitly distinguishes from the sibling tool 'save_session_summary' by noting its enforcement of at least one decision and separate episodic memory storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use: 'at the end of every agent-routed session, before delivering the final result'. Also gives an alternative tool ('save_session_summary') and explains the difference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses progressive disclosure behavior, search method (semantic+keyword fallback), and time filtering. Without annotations, description carries burden; it covers key traits but omits side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise overall, uses bullet and list for clarity, front-loaded with main purpose. Minor redundancy in threshold examples could be trimmed but generally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully explains behavior, input semantics, output format (progressive disclosure), and fallback logic. With output schema present, return values need no further detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description explains all 4 parameters in detail (natural language query, token budget, agent restriction, time window), adding significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Recall' and resource 'prior context within a token budget'. Unique progressive disclosure feature distinguishes it from sibling memory tools like search_memory or recall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for token budget and progressive disclosure thresholds, but does not directly 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states tools lists entries newest first, optionally filtered by date, and returns a formatted list or note. Does not disclose potential side effects or permissions, but as a read operation the behavior is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear one-line summary, usage paragraph, parameter list, and return note. It is slightly verbose (e.g., 'Use this to' repeats the first sentence) but overall efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown) and no annotations, the description adequately covers behavior, parameters, and return format. It explains default behavior and edge case (no entries). For a simple read tool, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 clearly explains 'date_from' format ('YYYY-MM-DD') and default behavior (no filter returns most recent), and 'limit' maximum count with default 10. This adds essential meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists journal entries from the knowledge base, newest first, and distinguishes it from other get_* tools by specifying it's for dated journal/log entries. The phrasing 'reflections, progress notes, and session handoffs' clarifies the content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides good usage context: 'look back over your dated journal/log entries' and 'rebuilding context at the start of a session.' It does not explicitly compare to alternatives but the use case is clear. Could be improved with direct exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes output format (text line with categories) and fallback message. No annotations provided, so description carries full burden, which it does adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs plus a 'Returns' section. Front-loaded with purpose, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully describes input (none), output format, and usage context for a simple tool with no parameters and an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100%. Description adds value by explaining why no parameters are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns all distinct project categories, with examples. Distinguishes from sibling set_project_category by noting it avoids inventing a new category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when you need existing categories; mentions sibling set_project_category. No explicit when-not-to-use but context is clear given no parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone discloses that it creates the config file with defaults if missing—an important side effect beyond a simple read. No other behavioral claims are made, but the disclosure is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the key action, no redundant words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with an output schema, the description fully explains returns and side effects. It is complete given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds value by explaining the output content (YAML with research interests, etc.), which is beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the full Metis user configuration from user-config.yaml, specifying the source and content (research interests, data sensitivity, etc.). It distinguishes from the sibling tool get_user_profile, so purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: it recommends get_user_profile for a lightweight summary, implying when to use this tool for the full config. It also notes the file creation behavior. No explicit when-not-to-use, but the alternative is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It details the return structure (fields, nested style dict) and implies read-only nature. It doesn't mention side effects or authorization, but for a simple profile lookup, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded. First sentence states purpose, then usage guidance, detailed output fields, and a code example. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an existing output schema, the description provides complete context: when to use, detailed output format, and a usage pattern. The code example further aids correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (input schema empty), so schema description coverage is 100%. Baseline for 0 params is 4. The description adds value by explaining output fields, though not param-related.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return the user's identity, interests, style, and model preference.' It specifies the resource (user profile) and action (return). Among siblings, it uniquely focuses on personal profile data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this at the start of any personalised run,' providing clear context for when to invoke. While it doesn't mention when not to use or list alternatives, the guidance is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 the tool clears items from the 'new publications' queue, stamps a read time, and that an empty list is a no-op. These behavioral insights are valuable beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence plus structured Args and Returns sections. Every sentence adds value. It front-loads the core purpose and efficiently covers necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 required param, output schema exists), the description covers purpose, usage context, parameter semantics, and return value. It ties to the sibling tool 'get_new_publications' and explains the effect. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 1 parameter 'ids' with no description (0% coverage). The description adds meaning: 'List of new_publications row IDs to mark as read; an empty list is a no-op.' This explains source of IDs and special behavior, compensating for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Mark' and resource 'new publications', and specifies it operates by IDs. It explains the effect: clearing from the queue and stamping read time. It distinguishes from sibling 'get_new_publications' by being the counterpart to mark items as read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'Use the IDs returned by get_new_publications', providing clear context for when to use this tool. It implies the workflow: get new publications then mark them read. It doesn't mention when not to use or alternatives, but the context is sufficient for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 transparently lists the checks performed and notes that it returns a structured report. There is no mention of side effects, but as a read-only diagnostic, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main purpose front-loaded. It uses bullet points for use cases, making it easy to scan. Every sentence adds value; no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema (per context signals), the description fully covers the tool's purpose and when to use it. The mention of a 'structured report' is sufficient for an agent to understand the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter description is needed. Schema coverage is 100%. The description does not waste space on parameters, earning the baseline score of 4 for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run a one-screen health check on Metis' and lists specific items checked (Python version, SQLite database, API key, etc.), making the purpose explicit and distinguishing it 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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases: 'when something feels broken', 'just before publishing', and 'after a git pull'. It does not explicitly state when not to use it, but the guidance is sufficient for typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses rate limiting (≤1 tip/20 min, ≤3/day), respects user settings (off/snooze/power-user), records to avoid repeats, and returns empty string when nothing to show. Does not mention side effects but operation is read-like and 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is about 120 words, front-loads purpose, and every sentence adds value. Minor redundancy in emphasizing 'earned discovery' but overall efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional param, no required, output schema exists), the description covers behavior, return values, when to call, and constraints. No additional information needed; output schema handles return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one optional parameter 'context' with no description in schema (0% coverage). Description explains it as 'comma-separated trigger tags describing what the user is doing', adding essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states that it returns one earned, not-yet-shown feature tip or empty string. Verb 'return' and resource 'feature tip' are specific. No sibling tools with similar purpose exist, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description lists explicit natural trigger moments (e.g., user starts a project, writes R code) and instructs to pass context as comma-separated tags. Does not explicitly state when not to use, but the context implies limited applicability. No alternative tool is mentioned, but no sibling tool serves a similar function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses lookup order (env var, config file) and return value (Path or None). No annotations exist, so description carries full burden, and it covers the read-only behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured: states purpose, motivation, technical details, and return type. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a zero-parameter tool with output schema. Covers all necessary aspects: configuration sources, return behavior, and integration context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so default is 4. Description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it resolves the Obsidian vault path, distinguishing it from note-indexing siblings like kg_index_notes. Uses specific verb 'resolve' and resource 'Obsidian vault path'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains it is used by note-indexing tools, providing context for when it might be called. Does not explicitly state when an agent should call it directly or mention alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes that decisions are 'recalled into context on future requests', indicating persistence. The scope parameter ('always' vs 'once') is explained in param semantics, adding behavioral detail. No annotations are provided, so the description carries the burden; it covers persistence and adaptability well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear opening sentence, usage guidelines, and a parameter list. It could trim slightly but remains efficient and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, the description fully covers purpose, usage, parameters, and behavioral implications. The existence of an output schema reduces the need to detail return values. No gaps remain for effective agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides thorough explanations for all four parameters: decision (plain language example), category (enumerated values), context (optional applicability), and scope (persist vs once). This adds critical meaning beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Record' and the resource 'user preference or decision', with a purpose ('so Metis adapts to the user over time'). It distinguishes itself from sibling tools like 'recall_decisions' and 'add_memory_entry' by focusing on decisions/preferences and referencing how they are recalled.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use ('whenever the user states a standing preference or makes a decision worth remembering') with concrete examples. Does not explicitly state when not to use or list alternatives, but the context and sibling list imply differentiation. Lacks full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently explains that content is classified into layers, stored with scope tags, and returns a confirmation message. It covers auto-classification and default behaviors, but lacks details on potential side effects or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for memory types and scope tags, making it easy to scan. It is slightly verbose but every sentence adds value. The main purpose is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, existing output schema), the description covers all necessary aspects: purpose, parameter details, memory classification, scope rules, and return value. It leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully document parameters. It explains all 8 parameters, including their types, defaults, and purposes. For example, it lists memory types with examples, scope options with visibility rules, and mentions auto-generated titles and comma-separated tags.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it stores content in memory with automatic classification and scope tagging. It uses specific verbs ('store', 'classify', 'tag') and distinguishes itself from retrieval tools like `recall()` by being 'the unified write interface to Metis's memory system'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool (to store memories) and implicitly distinguishes from alternatives like `recall()` for retrieval. It details memory types and scope tags, helping the agent choose appropriate parameters. However, it doesn't explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description covers the key behavioral trait: it deletes a marker file and is idempotent. It does not mention side effects or auth requirements, but for a simple file deletion, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences. It front-loads the action, then provides context and safety information. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool with an output schema (context indicates exists), the description provides complete context: purpose, timing, and safety. Minimal risk of misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema already fully defines inputs. The description adds context about the action but does not need to elaborate on parameters. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete', the resource '.first-run marker file', and the purpose 'to signal that the config wizard is complete'. It distinguishes itself from sibling tools, none of which are similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to call it ('at the end of the first-run wizard after all config files are written') and notes idempotency ('Safe to call even if the marker does not exist'). It does not explicitly mention when not to use it, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it renames the current database, overwrites the live database, loses all changes since backup, and requires a restart after restore.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, important warnings, and args. It is slightly verbose but front-loads critical information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature and existence of an output schema, the description adequately covers prerequisites, behavioral details, and post-action requirements, making it complete for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds crucial meaning: backup_path is described as a full path to .sqlite backup, and confirm must be the string 'YES' to proceed, which is not clear from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Restore the Metis database from a backup' with a specific verb and resource. It distinguishes itself from the sibling 'backup_db' by being the restore counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for restoring from a backup and warns about overwriting and restart, but does not explicitly guide when to use this tool versus alternatives like backup_db or list_backups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states this is a write operation (upsert), mentions that it affects the dashboard widget on next load, and notes that desktop and dashboard share a database. No contradictions with annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear top-level purpose, followed by contextual detail, and then a labeled Args section. It is concise but includes essential details. Minor improvement could be made by slightly tightening the prose, but overall it's effective and earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, but an output schema described in the Returns note), the description covers all necessary aspects: purpose, usage flow, parameter meanings, and return value. It references sibling tools (generate_daily_insight, get_daily_insight) and explains the shared database context, making it complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section that adds meaning to all 4 parameters: content is 'finished daily-brief prose', sources is 'comma-separated list', date is 'YYYY-MM-DD', model is 'for provenance'. The schema itself has no descriptions (coverage 0%), so the description fully compensates and provides clear semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it saves a composed daily brief to the dashboard widget. It distinguishes itself as the write-back half of the daily-brief round-trip, contrasting with generate_daily_insight() and get_daily_insight(). The verb 'save' combined with the resource 'daily brief' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains that this tool is used after composing the brief from generate_daily_insight() context, and that it upserts into the same table the dashboard reads. This provides clear when-to-use guidance. However, it does not explicitly state when not to use it or list alternative tools beyond the sibling get_daily_insight.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavior. It states 'save to persistent memory' and mentions return value, but lacks details on mutation effects (e.g., does it overwrite existing summaries?), permissions needed, or error handling. The description provides basic transparency but could be more comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: one paragraph for purpose, then bullet lists for arguments and return value. Every sentence adds value, no fluff. Front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple save operation with 4 parameters (1 required) and no output schema, the description covers purpose, parameters, return format, and usage timing. It could be more complete by describing behavior on duplicate session_id or storage limits, but overall it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the sole source for parameter documentation. It explains each parameter's purpose, required status, format (2-5 sentences for summary, list of tags for key_topics, etc.), and optional nature. This adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: saving a session summary to persistent memory for cross-session continuity. It uses specific verbs ('Save a summary') and directly distinguishes itself from sibling tool 'search_session_memory' (retrieval vs. storage).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Call this at the end of any substantive session.' It also mentions future retrieval via search_session_memory, providing clear context for usage without describing when not to use it in detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses a key side effect: matched papers are inserted into news_briefs with specific metadata. It also mentions the API is free and no key required. However, it doesn't mention rate limits, error handling, or the exact response format beyond the output schema existence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise intro, a contextual paragraph, and a clean Args list. Every sentence adds value without repetition. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description sufficiently covers the tool's purpose, behavior, and parameter details. It could be improved by briefly noting the return type or pagination behavior, but for a search tool with output schema, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 fully explains both parameters: query with an example and default behavior, max_results with default and maximum. This adds essential meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs citation-graph discovery on Semantic Scholar, using a specific verb ('Search') and resource ('Semantic Scholar'). It distinguishes itself from siblings by explicitly naming complementary tools (scan_pubmed_alerts, scan_openalex) and highlighting the unique value of 200M+ papers and citation counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for citation-graph discovery and complements PubMed/OpenAlex. It mentions no API key required, but does not explicitly state when not to use it or provide strict exclusions. The guidance is strong but lacks explicit when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: appends timestamped lines, can read when text is empty, single entry per calendar day. No annotations provided, so description bears full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise: two short paragraphs plus an Args section. Every sentence adds value — no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and existing output schema, the description covers purpose, usage, behavior, param semantics, and sibling differentiation completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully explains the single parameter 'text' — its role in appending vs reading, and the default empty meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb ('append to or read') and resource ('today's daily note') and distinguishes from sibling 'add_journal_entry' by noting the single-entry-per-day pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for when to use ('for fast, low-friction capture') and contrasts with the sibling 'add_journal_entry', though no explicit when-not-to-use is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description adequately discloses key behaviors: output file location (next to .enc or explicit output_path), that the passphrase is never stored, the format reversal, and the return structure. It could mention potential overwrite behavior or error conditions, but what is provided is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-organized: a one-sentence purpose, format details, output behavior, parameter listing, and return format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema that likely details the return structure, the description adequately covers the tool's purpose, behavior, parameters, and output. It fully addresses the needs of a decryption tool in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It provides clear, informative descriptions for all three parameters (enc_path, passphrase, output_path), explaining their roles in the decryption process. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states that the tool decrypts a .enc backup produced by encrypt_backup(), and explains the format it reverses. It clearly distinguishes itself from the sibling encrypt_backup by being its counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies the tool as the counterpart to encrypt_backup, establishing when it should be used (to decrypt backups). While it doesn't explicitly list exclusion criteria, the context of being the decryption complement provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses file output to outputs/exports/, return of path and preview, and all parameter defaults. It does not mention idempotency or side effects, but the behavior is well-covered for a read/export tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with a clear opening statement followed by a bullet-like list of arguments. Every sentence adds value, and the structure front-loads the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations and 0% schema coverage, the description covers purpose, usage, parameters, output (path + preview), and provides an explicit alternative. It is complete for the tool's complexity, and an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description provides detailed explanations for all 5 parameters (query, tag, collection, fmt, limit), including default values and behavior. 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports library references as a citation file (BibTeX) and uses specific verbs like 'Export library references as a citation file'. It differentiates from sibling 'mine_references' by noting RIS format is available there.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for use (cite-while-you-write) and explicitly names an alternative tool for RIS format. It does not explicitly state when not to use, but the alternative implies the exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full transparency burden. It discloses that the tool runs a fixed question set over the indexed library (PaperQA2) and assembles a markdown table with citations. It does not mention any destructive actions, which is appropriate for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (6 sentences), front-loaded with the main purpose, and each sentence adds value. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters (one required) and an output schema exists, the description covers the core functionality, parameter details, prerequisite, and use case. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description richly documents all three parameters: topic with example, fields with default set, and scope with valid values and prerequisite instruction. It adds significant meaning beyond the schema's bare titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts a structured, cited evidence brief from the PDF library using Elicit-style extraction, producing a markdown table. It distinguishes itself from sibling search tools by specifying the structured nature and fixed question set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is useful for systematic-review scaffolding and implies prerequisite indexing via scope mention. It lacks explicit when-not-to-use guidance but provides sufficient context relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it stores a placeholder row in daily_insights and that the Metis agent does the actual synthesis. It also details the data sources and time ranges. With no annotations provided, the description fully covers 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with a one-sentence summary, followed by detailed data gathering spec, workflow hint, parameter note, and return description. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, data sources, workflow, and return value. With an output schema present, it does not need to explain return values in more depth. It could mention error handling, but overall it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the baseline score is 4. The description explicitly states 'Takes no arguments,' which adds no extra meaning beyond the empty schema but is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assembles recent activity into context for a daily insight, specifying the exact types and time ranges of data gathered. It distinguishes itself from the sibling tool get_daily_insight by noting that get_daily_insight reads the stored result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow guidance: call this tool to generate the raw context, then use get_daily_insight to retrieve the synthesized result. It does not explicitly state when not to use this tool, but the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the read-only nature of the tool (no side effects implied) and details the returned information. With no annotations, the description carries the full burden, and it adequately describes what the tool does and returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear introduction, usage context, and return summary. While somewhat lengthy, every sentence adds value and it is front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no annotations, and presence of an output schema, the description fully explains what the tool returns and when to use it. It is complete for a simple stat retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the schema provides no info. The description implicitly states it takes no arguments, which adds value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it summarises the literature library, reporting total papers, breakdown by source and type, recent references, and sync status. It uses a specific verb ('summarise') and distinguishes itself from siblings like search_library and sync_zotero_library.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use: 'before searching or citing' to know library size and currency. It also notes it pairs with search_library and sync_zotero_library, providing clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 correctly states it reads the registry and enriches from folder cards if available. It also clarifies it is not just looking at folders on disk. Missing explicit mention of side effects (though it's read-only) or permissions, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then details, and an Args section. Every sentence adds value without fluff. Perfectly sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional param, read-only). The description, combined with the output schema (which exists), covers all necessary context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter project_id is fully explained: empty string lists all active projects, specific (exact or partial) shows that one. This adds significant meaning beyond the schema, which only shows a default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads the project REGISTRY table, which is the source of truth for the dashboard, and adds task completion counts. This sets it apart from sibling tools that might scan folders or manage projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use an empty project_id (all active) vs a specific one, and mentions partial matching. However, it does not explicitly contrast with sibling tools like get_project_categories or list_contexts, but the scope is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses retrieval behavior and quantifies result limit (20 entries) for the no-session case. Could mention side-effect free nature more explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an Args section, front-loaded with main functionality. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 optional param, output schema exists), the description fully covers behavior and parameter usage without omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter session_id is explained in detail: 'Pipeline session ID. Leave empty to get the 20 most recent entries across all sessions.' This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves working memory for a session, with conditional behavior based on session_id. This differentiates it from siblings like get_agent_context or get_related_memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use with or without a session_id, but does not explicitly mention when not to use or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, but the description details the indexing process (walks directories, uses PaperQA2 + Claude Haiku) and explains persistence for subsequent queries via ask_library(), providing solid behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (9 sentences), front-loads the main action, and introduces parameters in a clear list. Every sentence adds unique value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 optional params and an output schema, the description covers purpose, usage, behavior, and parameter details completely, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's meaning and effect: force_reindex (rebuild), topic_filter (folder name filter), scope (which library directory).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Build or rebuild a PaperQA2 index over the user's PDF library') and distinguishes the tool from siblings like ask_library which queries the index, making its purpose very clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Run once after adding new papers, or with force_reindex=True to rebuild.' This clearly states when to use the tool, though it does not directly exclude alternatives like index_pdf_library.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It explains the BFS algorithm, depth parameter behavior, and output grouping by distance, but omits side effects or safety guarantees. This is sufficient for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a bold first line, followed by an algorithm explanation and clear parameter docs. 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (context signal) and only two simple parameters, the description fully covers behavior and parameter usage, making it complete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides comprehensive parameter documentation, including file path format and default depth value, adding essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return the connected cluster around a given knowledge library note' with a specific verb and resource. It distinguishes from sibling tools like kg_paths and kg_memory_connections by its BFS flood-fill approach for community detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context ('Useful for surfacing related concepts when working on a specific topic') but does not explicitly state when not to use or mention alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses pseudonymisation, consistent mapping for record linkage, PII scrubbing, and local I/O. Could add error handling or file size limits, but current detail is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections and bullet points. Some slight redundancy (e.g., 'masked preview' repeated), but overall efficiently communicates key points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema described (returns JSON with rows, masked columns, counts). Parameter semantics covered. Could mention file size limits or permissions, but given complexity, it's adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0%, but description adds meaningful detail: 'path' is absolute local path to CSV/TSV/text, 'max_rows' has default 20. This goes well beyond the schema's bare type info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Read' and resource 'sensitive data file', returning a 'REDACTED preview' with specific output. Distinguishes from sibling check_data_safety by contrasting 'detects' vs 'returns a masked version'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly positions tool as 'the redaction half of /safe-analysis' and explains when to use it versus check_data_safety and the read-hook. Also notes local-only operation for privacy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that the tool stores per-variable entries, is idempotent (matching on dataset_name+project_id), and returns a confirmation with count or an error. This provides sufficient behavioral insight for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief paragraph explaining purpose and behavior, followed by a clear bulleted list of arguments. Every sentence adds value without repetition. No unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (2 required), no annotations, and an output schema (described as returning confirmation or error), the description is complete. It explains what the tool does, how each parameter works, and what to expect as output. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 detailed semantics for each parameter: dataset_name with example, variables with structure (strings or objects with optional fields like name, type, etc.), project_id and dataset_path with defaults and roles. This far exceeds the schema's minimal info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a data dictionary for a dataset, listing specific variable attributes (name, type, label, etc.). It distinguishes from sibling tools like 'register_code_artifact' or 'record_dataset_treatment' by focusing on variable metadata. The verb 'Record' is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it (to capture variable definitions for reproducibility) and notes idempotency (re-registering replaces). It doesn't explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to infer appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'Safe to run repeatedly — only processes gaps, never overwrites existing vectors.' Discloses non-destructive, idempotent behavior. Could add more on performance impact or locking, but sufficient for a recovery tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: concise purpose, behavioral detail, usage scenarios, Args, Returns. No superfluous sentences. Each element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a maintenance tool with two parameters and an output schema, the description covers purpose, behavior, usage, parameters, and return value. Complete enough for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 explaining both parameters: layers (comma-separated, defaults, valid values) and batch_size (memory vs speed trade-off). Adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Re-embed memory entries that are missing vector indexes.' It specifies the action (re-embed) and resource (memory entries). Distinguishes from siblings by focusing on missing vector indexes, and differs from tools like kg_index_memory or consolidate_old_memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage scenarios: 'Use this to recover from embedding failures, or after importing memories via raw SQL.' Also mentions it 'can be scheduled nightly via APScheduler.' Lacks explicit when-not-to-use or alternatives, but offers clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description details validation requirements (required sections in order), filename derivation, and return types (confirmation or rejection). Does not mention overwrite behavior or permissions, but adequately covers key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose and context, then validation rules, then parameters. 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple function (save a lesson draft), the description covers purpose, usage, validation, and return values. An output schema exists, so return explanation is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in input schema), but the description includes a full Args section explaining each parameter's purpose and usage, fully compensating for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Step 5 of the course build — save one drafted lesson to disk', specifying verb (save), resource (drafted lesson), and context, distinguishing it from sibling tools like save_course_curriculum or publish_course.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'call it once per lesson during drafting', providing clear context and expected frequency. Does not explicitly exclude alternatives, but sibling tools are distinct operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses file writing to specific path, default logging behavior, and confirmation return. With no annotations, this adequately informs about side effects and outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with paragraphs then structured Args and Returns. Front-loaded with purpose, every sentence adds value, concise without missing key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All 4 parameters documented, output described, tool behavior fully explained. No gaps given the presence of output schema and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description includes Args section with clear explanations for each parameter, including examples (e.g., 'epidemiologist') and default behavior for log_run, fully compensating for zero schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Save an agent's output as a review file and record the run.' Specific verb and resource, with context of standard persistence method, distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use it at the end of any substantive agent task so the result is filed and discoverable.' Provides clear context but does not name specific alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details that the tool pulls prior code, variables, paths, and cleaning steps, and does not indicate any destructive actions. Though no annotations are provided, it conveys a read‑only assembly behavior. It could be more explicit about non‑mutability, but overall it is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs and a bullet‑style argument list. It front‑loads the core purpose and provides all essential information without extraneous text. Every sentence is purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's straightforward purpose (scaffolding a new script), the description adequately covers what it does, what inputs are needed, and how to use it in sequence. An output schema exists, so full detail on return values is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema lacks descriptions (0% coverage), but the tool's description meaningfully defines all three parameters: goal, project_id, and language, explaining their purpose and defaults (e.g., language default 'r'). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Assemble the raw material to write a NEW script from previous work,' specifying the verb and resource. It distinguishes from sibling tools like 'analyze_script' by focusing on creating new scripts rather than analyzing existing ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'Call this, then write the script,' providing a clear sequence of use. It also explains the scope of project_id (prioritised then cross-project). However, it does not explicitly state when not to use this tool or mention alternatives, which would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It explains that the tool inserts into a database table and optionally writes a markdown file, and describes the return value. It lacks details on permissions or side effects, but is generally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (purpose, usage, args, returns) and is front-loaded. It is slightly long but every sentence is informative, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, 3 required) and the presence of an output schema, the description fully covers input semantics, behavior (database insert and optional file write), and return format. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds comprehensive meaning for each parameter, including allowed values for 'entry_type', comma-separated format for 'topics', and the role of 'detail' in creating a markdown file. This goes well beyond the basic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a new memory entry to the memory palace' with a specific verb and resource, and explicitly distinguishes itself from sibling tools 'store_episodic_memory' and 'store_semantic_memory'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides when to use this tool ('human-curated memory palace note') and when to use alternatives ('For machine/agent event logging use store_episodic_memory; for a distilled concept/definition use store_semantic_memory').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description covers key behaviors: records modification time, sets watch, re-add updates, file must exist, returns confirmation or error. No hidden side effects mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with summary, details, Args, Returns. Slightly verbose but adds necessary context. Efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description still clarifies return values. Covers prerequisites, re-add logic, alternative tool. Fully adequate for a simple file-tracking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0%, so description adds full meaning: path must be absolute and exist, label is optional with default empty and on re-add empty label leaves old unchanged. Outperforms basic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Add a single file to the tracked-files list and start watching it.' Identifies specific verb, resource, and action. Distinguishes from sibling 'connect_project_folder' for bulk registration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (register one file) and when not ('To register a whole project at once, use connect_project_folder'). Also explains re-adding behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that the tool takes no arguments and returns a text summary describing multiple metrics. It does not explicitly state it is read-only or non-destructive, but the reporting nature implies it. The behavioral summary is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 sentences), front-loaded with the primary action, and structured logically: purpose, detailed output, usage hints, and no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite zero parameters and existing output schema, the description fully covers the tool's purpose, invocation context, and return value format, making it self-contained for an agent to understand and use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with no parameters, so the description's statement 'Takes no arguments' adds clarity beyond the schema, achieving the baseline of 4 for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reports the discovery-tips state and adoption read, with specific details (on/off, mode, snooze, counts). It distinguishes from siblings by naming them and explaining the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly suggests use cases ('answer are tips on?', 'sanity-check before changing') and mentions sibling tools for alternative actions (discovery_intro, next_discovery_tip, set_discovery_tips). Provides clear context for when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description fully discloses key behaviors: no row-level data leaves the machine, only aggregates reported, output format matches register_data_dictionary schema. Safety promise is explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet complete: one-line summary, behavioral notes, and args section. No redundant sentences; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers output format and safety guarantees. Lacks mention of prerequisites (e.g., R/Python installed) and error scenarios, but given output schema is present, description does not need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Args section explains each parameter beyond schema metadata (e.g., dataset_path usage, language options). Schema had 0% coverage, so description fully compensates with clear semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb ('Generate'), resource ('profiling script'), and tailoring ('tailored to a specific dataset'). It distinguishes from sibling 'profile_dataset' by emphasizing safety and aggregate-only output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use, including optional checks for existing data dictionary entries. Lacks explicit when-not-to-use or alternative tools, but purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully compensates by disclosing key behaviors: it takes no arguments, creates bidirectional edges, uses REPLACE semantics (safe to re-run), and returns a summary. It also explains the outcome (cross-pollination discoverable). No behavioral traits are hidden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five short sentences front-loaded with the main action, followed by specifics, safety note, and return value. 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, an existing output schema (mentioned as summary), and no annotations, the description provides a complete picture of what the tool does, what it scans, its idempotency, and its purpose within the knowledge graph workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. The description confirms 'Takes no arguments,' which is sufficient. Baseline 4 is appropriate since no additional parameter meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool builds a knowledge graph from memory entries by linking shared topics. It lists the specific memory resources scanned and the output (bidirectional edges). This distinguishes it from sibling tools like kg_memory_connections and kg_paths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description notes that it is safe to re-run with REPLACE semantics, implying idempotent usage. However, it does not explicitly state when to use this tool over alternatives or when not to use it, though the purpose is clear enough in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it lists entities with claim count and last update, which is appropriate for a read-only list operation. However, it does not mention potential traits like pagination, performance, or safety, but given the simplicity of the tool, it is 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with no waste. The first sentence states the core functionality, and the second provides usage guidance. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (0 params, output schema exists), the description provides enough context: what it lists (entities, claim count, last update) and how it fits into a workflow (overview before drilling). No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100%. The description does not add parameter info because none exist. According to guidelines, 0 parameters yields a baseline of 4, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'list', the resource 'entities in the research timeline', and the included fields 'claim count and last update'. It clearly distinguishes itself from the sibling tool 'query_research_timeline' by positioning as an overview tool before drilling into specifics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this to get an overview of what topics have tracked beliefs, before drilling into a specific entity with query_research_timeline()'. It names an alternative and implies when not to use (when you need detail on a specific entity).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: it searches 6 memory layers, uses Reciprocal Rank Fusion, returns ranked results with source attribution, and explains recency weighting with a half-life parameter. There is no destructive action implied, and the merging mechanism is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary line, explanation, examples, and parameter list. It is longer than minimal but every sentence adds value; the examples and parameter details are necessary for clarity. Slightly less than perfect conciseness due to length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no annotations, an output schema exists but description still covers return values), the description is complete. It explains all parameters, behavior, merging strategy, and return format, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates fully by detailing each parameter: query, scope, agent_id, project_id, layers, top_k, and recency_half_life, including default values and examples. This provides rich semantic meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description immediately states 'Search across ALL memory layers in one call' with a clear verb and resource. It distinguishes itself from sibling search tools (e.g., search_memory, search_session_memory) by positioning as the unified front door that covers 6 specific layers, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage examples showing how to narrow results using scope, agent_id, and project_id, and implies broad vs. narrowed use. It does not explicitly mention when not to use it or list alternative tools, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: the file on disk is never touched, only the tracking record is deleted. It also explains what the tracking record is for and what the return value will be, leaving no ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at ~150 words, well-structured with a clear opening sentence, a paragraph on usage, and a bulleted Args/Returns section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no annotations, referenced output schema), the description is fully sufficient. It covers purpose, usage, behavior, parameter details, and return value. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds key semantics for the 'path' parameter: it must be an absolute path exactly as registered. This is essential information. Could also mention that it's the only parameter, but schema already indicates one required param.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'remove' (or 'stop tracking') and the resource 'tracked file', and distinguishes it from sibling 'add_tracked_file' by labeling it as the inverse. It also specifies the context of the tracked-files list in the Planning tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('file no longer relevant or added by mistake'), and implies when not to use (do not want to delete the file on disk). It also references the sibling 'add_tracked_file' as the opposite operation. Could mention 'scan_tracked_files' to find paths, but it's not essential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 it runs a substring search across indexed references, matches against title/authors/abstract/tags, returns newest first, and returns a formatted list or no-papers message. This is good behavioral context, though it doesn't explicitly state it is read-only or mention any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise first sentence, a paragraph explaining scope and alternatives, another on behavior, then clearly labeled Args and Returns sections. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, the description covers purpose, usage guidelines, parameters, and return format. It mentions output schema implicitly by describing the return. Minor details like case sensitivity or pagination are missing, but overall it is quite complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates fully. It explains 'query' as substring search against title/authors/abstract/tags and 'limit' as max number of papers, ordered newest first, with a default of 10. This adds significant meaning beyond the schema's type and required constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the local literature library for matching papers, specifying the resource (local literature library) and the action (search). It distinguishes from siblings by mentioning alternatives for PDF body text search and online lookup, which helps the agent differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use: searches saved reference metadata before going to the internet, and for different types of searches (PDF body, exact keyword, online) it directs to specific sibling tools. This provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool logs a time-stamped event, indexes it for vector search, and returns a TextContent with row id and type, or errors for missing dependencies or write failures. While it covers key behaviors, it could be more explicit about side effects (e.g., that it is a write operation). No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief intro, usage guidance, parameter descriptions, and return value. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 1 required) and presence of an output schema, the description fully covers purpose, usage, parameters, return value, and error conditions. It is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning by explaining each parameter: content (text), event_type (enumerates options), session_id (optional), metadata (JSON with extras). It adds value beyond the schema, though it does not explicitly mention that content is required or the default values for event_type and session_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool stores an event in episodic memory and indexes it for vector search. It distinguishes itself from siblings like store_semantic_memory and add_memory_entry, and provides concrete examples of event types, making the purpose clear and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit guidance on when to use this tool versus alternatives: 'For a distilled, timeless concept/definition use store_semantic_memory; for a human-curated palace note use add_memory_entry.' It also clarifies that episodic memory is a chronological log, helping agents decide appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description covers the behavior well: it stores a concept, is part of semantic memory, and mentions error conditions (missing database, missing fastembed, write failure). However, it does not explicitly state whether the operation is idempotent or if it overwrites existing entries, and lacks details on side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear intro, usage guidance, parameter list, and return info. It is slightly verbose but still efficient. Every sentence adds value, though some repetition could be trimmed (e.g., 'what I know' is stated twice).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (2 required), no nested objects, and an output schema (mentioned), the description covers all essential aspects: purpose, usage context, parameters, and return values. It is complete for an AI agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides detailed parameter explanations including examples for concept, definition, related_concepts, source_type (with enumerated values), and source_id. 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it stores a 'distilled knowledge node in semantic memory' for timeless concepts, and explicitly contrasts with store_episodic_memory and add_memory_entry, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (for storing concepts/definitions) and when not to (use store_episodic_memory for time-stamped events, add_memory_entry for curated notes). It also explains the role of semantic memory in retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that only passed fields are changed, empty arguments leave values untouched. Specifies that marking a recurring task 'done' creates next occurrence. Mentions return confirmation or not-found note. No annotations provided, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a brief purpose sentence, companion context, and bullet-like Args. Slightly lengthy but front-loaded and organized. Could be a bit more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all needed context: how to get task_id (get_tasks), what outputs (confirmation or not-found note), behavior of partial updates and recurrence. Given no annotations and 7 parameters, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully with an Args section explaining each parameter: task_id required, status options, title, owner, notes, due_date format, recurrence options and 'none' to clear. Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing task' with specific fields (status, title, owner, notes, due date, recurrence). It distinguishes itself from sibling tools like create_task, get_tasks, and delete_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly identifies as companion to create_task and get_tasks, and tells when to use: mark done/blocked, reschedule, reassign, edit. Also mentions delete_task for removal, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it modifies user-config.yaml, creates the file with defaults if absent, updates instead of duplicating on name match, and explains the active_by_default parameter's effect on activation state. The return value type is also specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: opening sentence for purpose, explanatory paragraphs, a 'Related tools' line, then 'Args:' and 'Returns:' sections. Every sentence provides value, with no redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and an output schema, the description covers all necessary aspects: purpose, behavioral details, parameter semantics, and return value. It enables an agent to correctly select and invoke the tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains each parameter: name as short label and dedup key, description as one/two sentences, and active_by_default with behavior (immediate activation vs storage/inactivation). This adds critical meaning beyond the schema's title and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (add or update) and the resource (specialist context). It distinguishes between adding and updating, and the context of routing/search tailoring provides specificity. The sibling tools list includes toggle_context and list_contexts, which helps differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to add or update specialist contexts for tailoring) and mentions related tools (toggle_context, list_contexts). However, it does not explicitly state when not to use it or provide alternatives beyond listing related tools, leaving room for slight ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden. It details the replacement behavior (list of PII types), modes ('full' vs 'preview'), and the optional name replacement heuristic. It also describes the output JSON structure, leaving no ambiguity about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive, using bullet points for replacements and clear sections for args. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, an output schema, and no nested objects, the description covers all necessary aspects: what it does, how to use it (args), and what to expect (output JSON with 'anonymized' and 'replacements'). It is fully complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no descriptions in schema). The description compensates by explaining all three parameters: content (text to anonymize), mode (full/preview), and replace_names (heuristic for CAPITALIZED tokens). It also explains the output format, adding significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Scrub PII from text and return anonymized version + replacement map.' It lists specific PII types and their replacements, distinguishing it from sibling tools like redact_data_file or diff_anonymization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's purpose and parameters (mode, replace_names) but does not explicitly state when to use this tool versus alternatives like redact_data_file or diff_anonymization. However, the context is clear enough for an agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that deletion is permanent and cannot be undone, and describes return values (confirmation or note if task not found). No annotations provided, so description fully carries the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections but slightly verbose. The 'Args' and 'Returns' format is helpful but could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: purpose, usage context, parameter detail, return value, and irreversibility. Appropriate for a simple tool with output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema by explaining task_id is obtained from get_tasks and is required. Schema coverage is 0%, so description compensates well. Could include format hint but sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Permanently delete a task from the database' with a specific verb and resource. Distinguishes itself from siblings by contrasting with create_task and update_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use (tasks created in error or no longer relevant) and when not (use update_task with status='done'). Also tells how to obtain task_id via get_tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses ordering (newest first), default parameters, and return format ('formatted list' or 'friendly note'). Minor gap: doesn't specify pagination limits beyond limit parameter, but adequate for simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose, one for usage context, then structured Args and Returns sections. Every sentence adds value, with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers everything an agent needs: purpose, parameters, expected output, and usage context. It references sibling tools and explains the scope options, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions in schema), but description compensates fully. It explains scope enum values with defaults and limit max, adding essential meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List captured ideas') and resource ('from your knowledge base, newest first'). It distinguishes itself from sibling tools by naming capture_idea and cross_pollinate, which are nearby in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'review what you've been thinking about over a chosen time window.' Provides context: 'ideas you logged with capture_idea.' Mentions sibling tools for adding and connecting, giving clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool as a reporting function with no side effects, which is clear. However, it does not explicitly state that it is read-only or non-destructive, though implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a concise purpose sentence, a usage paragraph, and then explicit Args and Returns sections. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, input, output contents, and sibling relationships. With output schema present, the return description is sufficient. Complete for a single-parameter reporting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'database' has no schema description (0% coverage), but the description explains its default behavior (empty string reports all databases), provides an example slug, and clarifies its optional nature. This fully compensates for the lack of schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Report indexing status and coverage for your PDF knowledge bases' and specifies the data shown (counts, last built, domain breakdown, un-indexed PDFs). It explicitly distinguishes from sibling tools index_pdf_library and search_pdf_knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use: 'check how complete your RAG corpus is before relying on grounded answers' and pairs with related tools for indexing and querying. This provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully covers behavior: it records a signal, returns confirmation or error for invalid event_type, and explains the long-term effect. This is transparent and complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an intro, purpose, usage guidance, parameter list, and return info. Every sentence adds value, making it informative without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter count (5), one required, and an output schema, the description covers behavior, parameters, return values, and usage. It is complete for a recording tool with clear context and no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 explaining each parameter, defaults, and constraints. This adds significant value beyond the schema, especially for event_type with its explicit list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a signal about thinking and working to personalize Metis. It lists specific event types and explains how it feeds a thinking profile, distinguishing it from related tools like get_thinking_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to call it 'whenever a meaningful preference moment occurs' and points to get_thinking_profile for reading the profile. It does not explicitly state when not to use alternatives, but the examples and context provide clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Describes search scope (library_fulltext table), stop-word handling, and return format (snippet with title/filename). Lacks detail on user scoping or performance, but covers key 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet complete: uses clear sections, front-loads purpose, and includes Args list. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two simple parameters and no output schema provided, the description covers purpose, usage, parameters, and return format comprehensively. Output schema is described in text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully documents both parameters: query (space-separated, with stop-word filtering) and max_results (default 10). Adds meaning far beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it performs full-text keyword search across all indexed PDFs, with verb (search), resource (full text), and scope (all PDFs). Explicitly distinguishes from siblings by naming alternatives for semantic search and metadata-only search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool (exact keyword search) versus alternatives (search_pdf_knowledge for semantic search, search_library for metadata). Mentions it is more powerful than title/abstract search, aiding correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the vector search method (768-dim nomic-embed), result structure (title, score, layer, etc.), and behavior for no matches. It could mention that it only searches indexed PDF chunks, but the mention of 'nothing is indexed yet' implies this. Overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet thorough, with clear sections: purpose, sibling comparison, technical detail, args, and returns. It uses about 10 sentences with no unnecessary words, front-loading the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no nested objects) and the output schema existing (described as TextContent with detailed result format), the description is complete. It covers input semantics, behavioral constraints, return values, and usage context. No gaps evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema's type/default info. It provides natural language explanations for each parameter (query, databases, top_k), includes examples for databases, and clarifies the role of query as 'natural language question or keyword phrase.' This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Semantic search across one or more knowledge database layers.' It identifies the specific verb (search) and resource (PDF knowledge), and distinguishes from siblings by specifying when to use alternatives like search_fulltext, search_library, and semantic_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool and when to use alternatives: 'For exact keyword matches use search_fulltext; for reference metadata use search_library; for your own notes/memory (not documents) use semantic_search.' This helps the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it returns 3-5 capabilities, is a no-op (returns empty string) if already given or tips are off, and implies idempotency. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each essential. Front-loaded with main purpose, then usage rules, then edge conditions. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema, the description explains the output (3-5 capabilities, empty string in some cases) and references the sibling tool. Fully adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds value by explaining the return behavior and conditions for empty string, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns 'the 3-5 highest-value capabilities' for a first-run orientation, and distinguishes itself from sibling 'next_discovery_tip' by specifying that after this intro, that tool should be used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly defines when to use: 'Use ONCE for a brand-new user (or when they ask what can you do?)' and specifies post-use behavior: 'After this, rely on next_discovery_tip for the long tail.' Also notes no-op conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully discloses the retrieval pipeline (embedding, vector search, keyword search, RRF fusion, dedup), scope constraints, and the fact that it returns fused results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a summary, restrictions, pipeline details (step-by-step), and parameter documentation. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and an output schema, the description covers the retrieval process, scope, parameters, and return format completely, leaving no gaps for an agent to misunderstand.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 (query, layers, top_k), their types, defaults, and for layers the allowed values. Could be slightly more precise about layers format but adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches across memory layers using vector similarity and RRF fusion, and explicitly distinguishes from sibling tools search_pdf_knowledge and search_library.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (personal memory layers) and when not to use (document library), with clear alternatives for other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: upsert semantics (keeps created_at, overwrites definition) and return type (confirmation message). This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear summary followed by detailed args and returns. Each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 string params) and the presence of an output schema, the description covers all needed context: upsert behavior, use case, and retrieval sibling. It is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining that 'term' is the unique key and 'definition' is the stored text. With 0% schema coverage, this is essential.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds or updates a glossary term, specifying the action and resource. It distinguishes from the retrieval sibling 'get_glossary' by mentioning retrieval separately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it (maintaining a personal glossary for consistent definitions) and explicitly describes the upsert behavior. It also directs to 'get_glossary' for retrieval, providing clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: how decisions are grouped and summarized, session summaries archived, reflexions consolidated monthly. It clarifies that originals are marked archived but still queryable, and that recall is kept fast. No contradictions with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and separate sections. Efficiently communicates three consolidation rules and parameter details without unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete coverage: explains what the tool does, how it works for each memory type, parameter details, and return value (a report of actions). No gaps given the tool's complexity and parameter count.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates fully by explaining each parameter's purpose and default values in the Args section. dry_run is clearly described as a preview mode, decision_age_days and session_age_days have clear functions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifically states it consolidates old memories into monthly summaries and archives originals, with clear breakdown of three memory types. It distinguishes from sibling tools like consolidate_reflexions and consolidate_session_memory by being the comprehensive consolidation tool for all old memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to run with dry_run=True first to preview changes. Also provides default age thresholds and explains the tiered retention behavior, giving clear guidance on when to use this tool for memory maintenance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it deletes a row from library_seeded, default file left untouched, delete_file guarded to PKM root only, and returns confirmation or error. No hidden traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a short summary followed by detailed Args and Returns sections. Every sentence adds value without redundancy. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return values (confirmation/error), behavior, safety mechanism, and alternative tool. Given the presence of an output schema (implied by return description), no gaps remain for a removal operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% parameter description coverage, but the description provides thorough explanations for both parameters: relative_path as primary key, delete_file with default and safety condition. This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it removes a library item from the Metis index with optional file deletion, and explicitly contrasts with archive_library_item for hiding. The verb 'remove' and resource 'library item' are specific and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the alternative (archive_library_item instead of remove), and explains the two modes (index-only vs file deletion) with a safety guard. Provides clear guidance on setting delete_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully carries the burden. Discloses it searches a specific SQLite table, uses case-insensitive substring matching, returns markdown table or error message on missing data. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with purpose, sibling alternatives, details, args, returns. Every sentence adds value. Front-loaded with core purpose. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and high sibling count, description sufficiently covers purpose, parameters, behavior, return format, and error handling. Output schema exists, and description complements it by describing the table format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description explains each parameter: query as case-insensitive substring, field with allowed values (all, disease, method, geography, article), limit with default 20. Adds complete meaning beyond bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'search' plus specific resource 'curated/seeded literature catalogue' and explicit facets (disease, method, geography, keyword). Distinguishes from three sibling tools by naming them and their use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use sibling tools (search_library, search_fulltext, search_pdf_knowledge) for different content, and when to use this tool for structured facets. Provides clear context for agent decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SVerITG/Metis'
If you have feedback or need assistance with the MCP directory API, please join our Discord server