mu

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

With only a title annotation and no read-only or destructive hints, the description carries the burden of behavioral disclosure. It does not mention side effects, costs, rate limits, or whether the agent may perform actions beyond searching. The focus on 'search' implies read-only behavior, but this is not explicitly stated.

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

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

The description is only two sentences, with the action stated upfront and the capability list in a compact second sentence. It is concise, front-loaded, and every word earns its place.

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

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

The tool is relatively simple (one param) and the description covers the core function and capabilities. However, with no output schema, it doesn't describe the response format, and it fails to differentiate this agent from the 'chat' sibling or individual search tools, leaving some contextual gaps.

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

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

The single parameter 'prompt' is fully described in the schema ('Your question or request'), and the description reinforces it by saying 'Ask the AI agent a question.' With 100% schema coverage, the description adds no extra meaning beyond confirming the prompt is the question.

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

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

The description clearly states the tool's function: 'Ask the AI agent a question' and lists the domains it can search (news, markets, web, video, weather, places). This makes the purpose specific and distinguishes it from more focused siblings like web_search, though the 'and more' is vague and doesn't explicitly separate it from 'chat'.

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

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

The description implies when to use the tool (for broad questions needing cross-domain search) but provides no explicit when-not-to-use or alternative tools. It states the agent 'can search news, markets, web, video, weather, places, and more,' which suggests a general-purpose query tool but doesn't clarify when to prefer a dedicated search tool.

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

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

The description discloses the key behavior (builds, saves, returns URL) and adds constraints on app types. With only 'title' annotations, the description carries the burden of transparency, but it does not mention potential side effects, permissions, or constraints like whether an app can be overwritten. It is adequate but not thorough.

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

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

The description is concise, using two sentences to cover action, process, and constraints. It is front-loaded with the main verb and resource, and each sentence adds value without padding. This is an exemplar of efficient writing.

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

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

For a tool with a single simple parameter and no output schema, the description adequately covers the main purpose, input constraints, and expected output (app details with URL). It does not elaborate on the exact structure of the returned app details, but that omission is acceptable given the simplicity of the tool.

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

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

The input schema already documents the single 'prompt' parameter with examples. The description adds meaningful semantic constraints by stating the app must be one of three specific types, which directly informs how the prompt should be phrased. This goes beyond the schema's generic description, so it earns a 4.

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

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

The description clearly states the tool's function: building a small app from a natural language description, saving it, and returning a URL. It also specifies the three app types (tracker, checklist, counter), which adds scope clarity. However, it does not explicitly differentiate this from sibling tools like apps_create, so it falls short of a 5.

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

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

The description provides clear context on when to use this tool by enumerating the allowed app types ('Apps are one of: a tracker, a checklist, or a counter'). This implicitly tells the agent which prompts are acceptable. However, it does not explicitly mention alternatives or contrary cases, so it lacks the 'when-not-to-use' guidance needed for a 5.

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

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

With annotations containing only a title (no readOnlyHint or destructiveHint), the description bears full responsibility for disclosing behavioral traits. It merely states 'Create a new app' without indicating side effects, authentication needs, whether the resource publishes immediately, or what the response looks like. This is a significant gap for a mutating operation with no 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.

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

The description is a single, front-loaded sentence that efficiently communicates the tool's purpose without redundancy. It immediately states the action ('Create') and the object ('a new app'), then enriches the meaning with a concise definition ('a small, self-contained HTML tool hosted on Mu'). No words are wasted.

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

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

Even though the schema covers parameters, the description lacks any mention of return values, side effects, or operational behavior. There is no output schema, so the description should compensate, but it does not explain what happens after creation or how the created app is represented. For a 6-parameter creation tool with no annotations, the description remains too sparse to be considered complete.

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

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

The input schema provides complete descriptions for all six parameters, including required fields like name, slug, description, and html, achieving 100% coverage. The description adds no additional parameter semantics, but the schema already carries that weight. Baseline 3 is appropriate because the schema handles the heavy lifting.

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

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

The description uses the specific verb 'Create' and identifies the resource as 'a new app,' while also clarifying the app type as 'a small, self-contained HTML tool hosted on Mu.' This distinguishes it from sibling tools like apps_edit, apps_fork, and apps_read, which clearly imply different operations. The definition of 'app' adds valuable context beyond the name.

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

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

The description provides no guidance on when to use this tool versus alternatives such as apps_edit or apps_fork. It does not mention prerequisites, when not to use it, or how to choose between the app-related tools. The only usage signal is the verb 'Create,' which implies new app creation but lacks explicit contextual direction or exclusions.

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

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

Annotations provide only the title with no readOnly or destructive hints, so the description carries full responsibility. It communicates the mutation ('Edit') and ownership requirement, but gives no details about side effects, permissions, reversibility, or failure behavior, which are critical for an edit tool.

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

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

The description is a single sentence that front-loads the action and resource, then lists the editable attributes. Every word adds value with no redundancy or filler, making it highly concise and easy to scan.

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

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

Given the 7-parameter complexity and no output schema, the description does a good job of covering which fields can be edited and the ownership prerequisite. It falls short on usage exclusions and behavioral details, but the core editing scope is fully described.

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

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

Schema coverage is 100%, so the baseline is 3. The description lists the same fields as the schema but adds no extra meaning beyond natural-language naming; the schema already provides detailed per-parameter descriptions (e.g., max 256KB for html).

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

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

The description uses a specific verb ('Edit') with the resource ('an existing app you own') and explicitly lists the updatable fields (name, description, tags, icon, HTML code, price), clearly distinguishing it from siblings like apps_create, apps_fork, and apps_read.

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

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

The phrase 'an existing app you own' provides clear context for when to use this tool, implying it is for updating apps you already own and not for creating or forking. However, it does not explicitly name alternative tools or explain when not to use it, so it stops short of full exclusionary guidance.

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

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

With no annotations beyond the title, the description carries the full burden of behavioral disclosure. It states that the tool creates a copy under the user's account and that the copy can be modified independently, which implies the original app is unaffected. However, it does not disclose permissions requirements, what data is copied, or any potential side effects. This adds some value but lacks rich 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.

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

The description is a single sentence that front-loads the core action ('Fork an existing app') and includes only essential information. There is no fluff or redundancy; every word contributes to clarity.

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

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

For a simple tool with two parameters and no output schema, the description provides sufficient context about purpose and outcome. It omits details like auto-generation of new_slug, but the schema covers that. The description is complete enough for an agent to invoke the tool correctly, though a brief mention of the return value would make it slightly more complete.

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

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

The input schema provides 100% coverage with descriptions for both parameters (slug and new_slug). The description does not add extra parameter-level meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description clearly states the tool's purpose: 'Fork an existing app — creates a copy under your account that you can modify independently.' It identifies the specific verb (fork/copy) and resource (existing app), and distinguishes it from sibling tools like apps_create (which creates a new app from scratch) and apps_edit (which modifies an existing app) by emphasizing the copy-and-modify-independently behavior.

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

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

The description implies use cases: when you want to replicate an existing app and work on your own version. It provides clear context (existing app, copy under your account) but does not explicitly compare with alternatives like apps_create or apps_edit, nor does it state when not to use the tool. This earns a 4 rather than a 5.

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

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

The annotations already indicate readOnlyHint and idempotentHint. The description adds no additional behavioral context beyond restating the action; it does not disclose return format, error behavior, or any side effects. It essentially duplicates the title and parameter information.

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

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

The description is a single, concise sentence with no filler or unnecessary words. It front-loads the verb and resource, making it easy to scan.

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

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

For a simple read tool, the description is minimally viable but lacks any indication of what 'details' encompasses or what happens if the slug does not exist. There is no output schema, so a bit more context about the response would improve completeness.

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

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

The input schema has 100% coverage with a description for 'slug'. The description's phrase 'by its slug' is redundant with the schema and adds no further meaning about the parameter format or constraints.

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

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

The description clearly states the action ('Read'), the resource ('details of a specific app'), and the scope ('by its slug'). This distinguishes it from sibling tools like apps_search (which searches) and apps_run (which executes).

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

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

The description implies usage when you have an app slug and want its details, but it does not explicitly mention alternatives or when not to use this tool. It lacks guidance such as 'use apps_search if you don't have a slug'.

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

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

The description mentions 'sandboxed environment' and 'return the result', offering some behavioral context. However, it does not disclose that the code can access mu.db and mu.store, which could cause side effects or state changes. Annotations do not provide safety hints, so this is a notable gap.

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

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

The description is only two sentences, front-loaded with the main action. It delivers the purpose and usage instructions without any unnecessary words.

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

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

For a single-parameter tool with no output schema, the description effectively conveys purpose and usage. The schema handles parameter details, but the description could mention execution limits or potential side effects. Overall, it is fairly complete.

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

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

The schema description for the only parameter 'code' is comprehensive, covering syntax and platform access. Since schema_description_coverage is 100%, the baseline is 3; the tool description itself adds no further parameter detail.

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

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

The description clearly states the tool runs JavaScript code in a sandboxed environment and returns the result, using a specific verb and resource. It distinguishes from sibling tools like apps_build or apps_read by focusing on execution rather than creation or retrieval.

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

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

The description provides clear usage context: 'Use for calculations, data processing, or any computation the user needs.' However, it does not mention any alternatives or when not to use the tool, so it lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds minimal behavioral context beyond restating the purpose, such as 'small, useful tools', but does not describe return format, filtering behavior, or other operational traits. It does not contradict the annotations.

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

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

The description is a single, concise sentence that is front-loaded with the action and resource. Every word serves a purpose, with no redundancy or fluff.

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

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

For a simple search tool with two optional parameters and no output schema, the description adequately conveys the core purpose. However, it does not explicitly state that the tool returns a list of matching apps or how tag and query combine, which would be useful given the lack of an output schema. Overall, it is mostly complete but leaves minor gaps.

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

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

Schema description coverage is 100%, with both 'tag' and 'query' described in the schema. The description adds no additional parameter information, so the baseline of 3 is appropriate. It does not clarify how tag and query interact (e.g., AND/OR), but the schema is sufficient for basic use.

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

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

The description uses a specific verb 'Search' and identifies the resource 'apps directory' and the object 'small, useful tools'. It clearly distinguishes this as a search operation from sibling tools like apps_read or apps_run, which have different purposes.

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

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

The description implies the tool is used when you need to find apps in the directory, but it does not explicitly state when to use this over alternatives like apps_read or other search tools. No exclusions or alternative tool names are provided, so the guidance remains implicit rather than explicit.

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

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

Annotations provide only a title, so the description carries the burden of conveying behavior. It does disclose that the tool executes API calls server-side and returns pass/fail results, which is useful. However, it does not indicate whether this action has side effects (e.g., modifies the app, sends real requests, requires specific permissions) or any limitations, 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.

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

The description is two sentences, front-loaded with the primary action, and there is no wasted wording. It efficiently explains the mechanism and the expected output.

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

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

For a simple one-parameter tool with no output schema and minimal annotations, the description is largely complete: it covers the action, method, and result. However, it could be slightly enriched with context on when to use it (e.g., after building an app) or mention of any side effects, but these gaps are not critical given the tool's simplicity.

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

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

The input schema already fully describes the only parameter ('slug') with 100% coverage, so the description adds no additional parameter-level detail. This aligns with the baseline of 3 where schema handles parameter documentation.

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

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

The description clearly states the tool's function with a specific verb ('Test') and resource ('an app'), and details the method: checking HTML structure and executing mu.api calls server-side. This distinguishes it from sibling tools like apps_run or apps_read, which likely run or view apps rather than test them.

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

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

The description implies that this tool is used for testing an app's API calls, but it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites. Given the many sibling tools, more explicit guidance would be beneficial, but the core context is clear.

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

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

Annotations already include destructiveHint: true, and the description adds the specific behavioral outcome of hiding all content from the user's view. This goes beyond the annotation by clarifying what is affected.

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

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

The entire description is a single, front-loaded sentence that conveys the action and its effect with no extraneous words. Every token earns its place.

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

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

For a simple tool with one parameter, a clear destructive hint, and no output schema, the description is sufficient. It could mention reversibility via unblock_user, but the sibling list provides that context, making the description adequately complete.

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

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

The input schema has one parameter with full description coverage ('User ID to block'). The tool description adds no extra parameter semantics; therefore, a baseline of 3 is appropriate given the schema already documents the parameter.

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

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

The description clearly states the action with a specific verb ('Block'), the resource ('a user'), and the consequence ('hides all their content from your view'). This distinguishes it from siblings, especially unblock_user.

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

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

No guidance is provided on when to use this tool or alternatives. It does not mention the existence of unblock_user or any prerequisites or edge cases, leaving the agent without explicit usage direction.

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

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

No annotation hints are provided (only a title), so the description carries the full burden. It accurately states the action ('Create a new blog post') but does not disclose any additional behavioral details such as whether the post is published immediately, if permissions are required, or what the response contains. It is not misleading but is minimal.

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

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

The description is a single, focused sentence that conveys the essential purpose without any redundant information. It is appropriately sized and front-loaded, earning its place with zero waste.

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

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

The tool is simple (2 params, no output schema) and the description is minimally viable: it states the core action but omits any guidance about return values, side effects, or relationship to sibling operations. Given the simplicity, the description is adequate but not enriched beyond the bare minimum.

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

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

The input schema already provides full descriptions for both parameters (title and content) with 100% coverage. The tool description adds no extra parameter context, so it does not exceed the baseline for high schema coverage.

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

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

The description uses a specific verb ('Create') and resource ('a new blog post'), clearly distinguishing it from sibling tools like blog_update, blog_read, blog_delete, and blog_list. It unambiguously states the tool's function.

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

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

The description implies usage for creating new blog posts, but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. The CRUD sibling set provides context, but the description itself offers no explicit guidance on when to choose this over blog_update or other tools.

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

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

Annotations include destructiveHint: true, which already signals destructive behavior. The description adds the author-only permission constraint, a useful behavioral detail beyond the annotation. It does not mention permanence or side effects, but for a simple delete operation with destructiveHint, 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.

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

The description is a single concise sentence that front-loads the action ('Delete a blog post') and adds a key constraint ('author only'). Every word earns its place, with no unnecessary detail.

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

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

For a simple delete tool with one parameter and no output schema, the description is complete. It states the operation and the critical authorization requirement, making it sufficient for an agent to select and invoke the tool correctly.

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

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

The input schema fully describes the only parameter 'id' with a clear description ('The blog post ID to delete'), and schema description coverage is 100%. The tool description does not add any additional parameter semantics, so the baseline score of 3 is appropriate.

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

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

The description 'Delete a blog post (author only)' clearly states a specific verb and resource, and the parenthetical 'author only' distinguishes it from sibling tools like blog_create, blog_read, and blog_update. It precisely identifies what is being deleted, a blog post rather than the blog itself.

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

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

The description provides clear context by restricting usage to 'author only', which implies who may use it. However, it does not explicitly mention alternatives or when not to use it, but the sibling tool names (blog_create, blog_list, blog_read, blog_update) provide implicit context.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds value by specifying the return content (titles, snippets, ids) and the 'recent' filter, which are behavioral traits not present in the annotations or schema. However, it does not mention potential pagination or rate limits, so it is not fully exhaustive.

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

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

The description is a single, well-structured sentence. It front-loads the primary action, then parenthetically adds the return fields and a pointer to the sibling tool. Every word earns its place with no redundancy or irrelevant detail.

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

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

For a simple listing tool with no parameters and no output schema, the description is complete: it states what is returned, the recency scope, and directs users to blog_read for detailed content. No further behavioral or return information is necessary for an agent to use this tool correctly.

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

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

The tool has zero parameters and the input schema is empty, so there are no parameter semantics to clarify. According to the rubric, the baseline is 4 for no-parameter tools, and the description does not need to add parameter information.

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

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

The description clearly states the tool's function: 'Get recent blog posts' with a specific verb and resource. It distinguishes itself from the sibling tool blog_read by noting that blog_read is for viewing a single post in full, making the scope of blog_list clear (listing multiple posts with titles, snippets, and ids).

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

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

The description explicitly directs users to blog_read 'for one in full', providing an alternative for a specific use case. This gives clear guidance on when to use blog_list versus a sibling tool, satisfying the 'alternatives' criterion.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safe, non-mutating behavior. The description adds no further behavioral context beyond the fact that it reads by ID, which is largely parameter-related. It does not contradict annotations.

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

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

The description is a single, front-loaded sentence that communicates purpose without any filler. It is appropriately concise for such a simple tool.

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

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

For a tool with one well-documented parameter and annotations covering safety, the description is nearly complete. It clearly implies the tool returns the blog post content, though it does not explicitly state the return format. Given the low complexity, this is adequate.

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

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

The input schema has 100% coverage, with the 'id' property described as 'The blog post ID'. The description's mention of 'by ID' reinforces this but does not add new semantic details beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Read') and resource ('specific blog post by ID'), making the tool's purpose unambiguous. It clearly distinguishes itself from siblings like blog_list (which lists posts) and blog_create/blog_update (which modify posts).

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

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

The phrase 'by ID' provides clear context for when to use this tool: when you have a blog post ID and want to read that exact post. It does not explicitly mention alternatives like blog_list for browsing, but the intended use case is obvious from the description.

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

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

The description adds the important permission constraint 'author only' beyond the schema. However, it does not disclose update semantics—whether it does a partial or full update, or what happens to unspecified fields. With annotations providing no safety hints, more behavioral detail would be valuable.

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

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

One concise sentence, front-loaded with the key verb and resource, and no redundant words. It effectively communicates the core purpose and a key constraint in minimal space.

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

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

Given the low complexity and full schema coverage, the description is largely complete. It establishes the purpose and the author-only constraint, and sibling tools provide context. It does not describe return values or error cases, but for a simple update tool this is acceptable.

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

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

Schema description coverage is 100%, so the schema documents all parameters (id, title, content). The description does not add extra parameter meaning beyond reaffirming the target is an 'existing blog post'. Baseline 3 is appropriate since structured data carries the semantics.

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

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

The description clearly states the action ('Update') and resource ('existing blog post'), and the 'author only' qualifier distinguishes it from blog_create, blog_delete, and blog_read. The verb+resource combination 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.

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

The description implies usage context: update an existing post, not create/delete/read. Sibling tool names (blog_create, blog_delete, blog_read) make the distinction obvious. However, it does not explicitly state when not to use it or mention alternatives, but the context is clear enough.

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

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

With no annotations (other than title), the description carries the full burden of behavioral disclosure. It does not mention whether the chat maintains context, whether it's read-only, authentication requirements, or any side effects. The description only states the action, leaving the agent unaware of important behavioral traits.

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

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

The description is a single, concise sentence that directly states the tool's function without any fluff. It is front-loaded and efficient, using exactly the words needed to convey the core purpose.

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

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

The tool is simple (one parameter, no output schema), but the description is extremely minimal. It does not specify what the tool returns (e.g., text response, stream), whether it supports multi-turn context, or any usage constraints. Given the lack of annotations and output schema, the description is insufficiently complete for an agent to confidently use it.

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

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

The input schema already provides 100% coverage: the only parameter 'prompt' is described as 'The message to send to the AI'. The description adds no additional parameter guidance, so it meets the baseline but doesn't exceed it.

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

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

The description 'Chat with AI assistant' clearly identifies the tool as a conversational interface with an AI. It uses a specific verb ('chat') and specifies the resource (AI assistant). However, it does not explicitly differentiate from sibling tools like 'agent' or 'web_search', making the purpose clear but not distinguished.

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

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

The description provides no guidance on when to use this tool versus alternatives. There is no mention of appropriate scenarios, exclusions, or alternative tools. For an agent, it's also unclear whether this is for one-off questions or multi-turn conversation, so the usage context is missing.

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

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

The description discloses a key behavioral trait: it updates existing contacts rather than creating duplicates. Since annotations are minimal (only title), the description carries the burden, and while it does not cover permissions or return values, the disclosed upsert behavior is valuable and non-obvious.

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

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

The description is extremely concise: two short sentences. The first sentence delivers the primary purpose immediately, and the second adds a critical nuance without any wasted words.

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

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

For a simple tool with four parameters and no output schema, the description covers the core purpose and the important update behavior. It does not explain return values or error handling, but these are less critical for such a straightforward operation, making it sufficiently complete.

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

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

Schema description coverage is 100%, so all parameters (name, note, email, phone) already have clear descriptions in the schema. The tool's description adds no additional parameter-level meaning, so the baseline score of 3 applies.

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

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

The description clearly states the tool's purpose with a specific verb ('Save') and resource ('someone to your address book'). It also distinguishes itself from sibling tools like contacts_find and contacts_list by indicating it adds or updates contacts rather than reading them.

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

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

Usage context is implied: you would use this to add a contact. The description notes that adding an existing name updates rather than duplicates, which hints at usage for both new and existing contacts, but it does not explicitly mention alternatives or exclusions compared to other contact tools.

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

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

Annotations already provide destructiveHint: true, and the description simply repeats the delete concept without adding extra behavioral context such as irreversibility, permission requirements, or side effects. It is consistent but does not go beyond the annotation.

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

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

The description is a single concise sentence that fully communicates the tool's purpose without any filler or redundant content. It earns its place in the tool definition.

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

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

For a simple delete operation with one required parameter, a destructiveHint annotation, and clear purpose, the description is complete. No output schema is needed for a delete operation, and the description covers all essential usage aspects.

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

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

The schema covers the single parameter 'id' with a description ('The contact's id'), and the tool description adds no additional information about parameter usage. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description 'Remove someone from your address book' is a specific verb+resource construction that clearly states the tool's purpose. It distinguishes from sibling tools like contacts_add, contacts_find, and contacts_list by explicitly indicating a removal action.

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

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

The description clearly implies when to use the tool (deleting a contact) and the sibling context makes it obvious. However, it does not explicitly mention alternatives or when not to use it. The clarity of the delete intent and the simple sibling set justify a high score.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the agent knows it is a safe read operation. The description adds the search scope (by name, part of a name, or address) but does not disclose return format or behavior when no match is found. Given the annotations cover safety, a 3 is appropriate.

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

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

The description is two short sentences, front-loaded with the action and immediately followed by a practical usage tip. Every sentence earns its place with no redundancy or filler.

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

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

This is a simple one-parameter, read-only tool with generous annotations. The description provides purpose, usage context, and query semantics. It doesn't explain return values, but the simplicity and sibling context (e.g., contacts_list) make this adequate. A 4 reflects that it's complete enough for the tool's complexity.

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

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

The input schema has 100% coverage for the single parameter 'query', with its description already stating 'A name, part of a name, or an address'. The tool description essentially repeats this information, adding no extra meaning beyond the schema. Baseline 3 is correct.

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

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

The description clearly states the tool looks someone up in the address book by name, part of a name, or address, using the specific verb 'Look someone up' and the resource 'address book'. This distinguishes it from sibling tools like contacts_list and mail_send by indicating a search/lookup action rather than listing or sending.

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

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

The description provides explicit usage context: 'Use this before sending mail to a person named rather than addressed.' This tells the agent when to use the tool. It does not explicitly mention alternatives or when not to use it, but the clear use-case guidance earns a 4.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description does not need to restate these. The description adds the scope 'everyone' (implying no filtering), but does not disclose additional behavioral details such as return format or ordering, which are absent from 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.

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

The description is a single clear sentence: 'List everyone in your address book.' It is concise and front-loaded, with every word contributing to the tool's purpose. No filler or redundancy.

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

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

Given the tool's simplicity (zero parameters, read-only, idempotent), the description is nearly complete. However, there is no output schema, and the description does not specify what the returned contact entries look like, which is a minor gap for an agent expecting structured output.

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

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

The tool has zero parameters, and the input schema is empty. According to the baseline for 0 params, no parameter explanation is needed; the description does not attempt to add param semantics, which is appropriate.

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

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

The description clearly states the verb 'List' and the resource 'everyone in your address book,' which precisely defines the tool's function. It distinguishes from siblings like contacts_add, contacts_delete, and contacts_find by indicating a full-list operation.

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

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

The description implies usage when you want to list all contacts, but does not explicitly mention alternatives or exclusions. There is no reference to contacts_find for searching or contacts_add for adding, so the guidance is implicit rather than explicit.

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

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

Annotations only include a title, so the description carries the full burden. It discloses privacy defaults ('Private by default'), sharing behavior ('set public=true to share it'), and ownership requirement for updates ('a record you own'), adding useful 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.

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

Three short, front-loaded sentences with no redundant text. Every clause adds value: storage action, privacy default, sharing, and update behavior.

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

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

For a 4-parameter create/update tool with no output schema, the description covers core behavior, privacy, and ownership. It does not detail return values, but that is acceptable given the tool's simplicity.

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

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

The input schema already describes all four parameters with 100% coverage. The description reinforces the schema (public default, id for updating) but adds minimal new meaning beyond the schema, such as the ownership nuance for id.

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

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

The description clearly states the primary action with a specific verb and resource: 'Store a record in your database (a named collection).' It also covers the update variant, distinguishing it from related db_delete, db_get, and db_list tools.

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

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

It provides practical guidance on when to use public=true and when to pass an id for updates. The sentence 'Pass an id to update a record you own' explicitly differentiates create from update usage, though it doesn't mention alternatives or exclusions.

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

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

The destructiveHint annotation already signals destructive behavior. The description adds the ownership requirement and the 'by id' deletion method, which are useful constraints. However, it does not disclose error conditions, reversibility, or side effects on related data, so it provides only modest additional transparency beyond the annotation.

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

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

The description is a single, front-loaded sentence that conveys the action, resource, method, and a condition. There is no filler or redundant content; every word is purposeful.

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

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

For a simple delete operation with two fully described parameters and a destructive annotation, the description is largely sufficient. It lacks details on return values or error handling, but given the absence of an output schema and the strong annotation, it provides the essential context for an agent to select the tool.

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

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

The input schema already provides 100% description coverage for both parameters (id and collection). The description reinforces that deletion is by id, but it does not add significant meaning beyond the schema, aside from the ownership condition applying to the record.

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

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

The description clearly states the action ('Delete'), the resource ('a record you own by id'), and a specific condition (ownership). This distinguishes it from sibling delete tools (blog_delete, contacts_delete) and other db_* operations by identifying the precise operation and input.

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

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

No guidance is provided for when to use this tool versus alternatives such as blog_delete or files_delete. The description only implies a precondition (owning the record) but does not mention context, exclusions, or when to choose db_delete over other tools.

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

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

Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds a meaningful behavioral constraint ('must be yours, or public'), which goes beyond what annotations provide. No contradictions with annotations are present.

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

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

The description is a single, front-loaded sentence with no wasted words. It includes the essential action, resource, and a key access condition without redundancy.

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

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

For a simple read tool with two parameters and no output schema, the description covers the core purpose and access criteria. It does not specify return behavior or error handling, but these are arguably implied for such a basic get operation. It is reasonably complete given the tool's simplicity.

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

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

Schema description coverage is 100%, so both parameters (id and collection) are already fully described in the input schema. The description adds no extra parameter-level detail, such as formats or constraints. Per the rubric, a baseline of 3 is appropriate.

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

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

The description clearly states that the tool retrieves a single record by ID from a collection, using a specific verb and resource. It also includes a scoping condition ('must be yours, or public') that distinguishes it from other read tools like db_list. This is a precise, non-tautological statement of purpose.

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

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

The description provides clear context for when to use the tool: when you need one record by ID from a collection, and only if the record is yours or public. However, it does not explicitly mention alternatives (e.g., db_list for multiple records) or when not to use it. This is 'clear context, no exclusions', qualifying for a 4.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description doesn't need to restate safety. It adds meaningful context by explaining the semantics of the scope parameter ('mine' vs 'public' vs 'all') and the default scope, which goes beyond the schema/annotations.

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

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

One concise sentence that front-loads the core purpose ('List records in a collection') and follows with compact parameter notes. Every word earns its place; no redundancy.

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

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

Given the moderate complexity (6 params, one nested object), strong annotations, and no output schema, the description covers the essential behavioral aspects. It could mention default sort/order or pagination, but the schema already carries those defaults, so the description is adequate.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying the scope values and default, and by mentioning the where filter and sort field as optional, which helps the agent understand parameter relationships beyond the raw schema descriptions.

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

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

The description clearly states 'List records in a collection' - a specific verb and resource - and differentiates from sibling db tools (create, delete, get) by indicating this is for listing. The scope options add useful specificity.

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

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

The description implies usage through 'List records in a collection' and the scope/filter options, but it does not explicitly mention when to use this over alternatives like db_get. No exclusions or alternative tool references are provided, so it relies mainly on inference.

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

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

The annotation includes destructiveHint:true, which already signals potential state modification. The description merely repeats the action ('hide') without adding context about reversibility, scope (e.g., only personal view vs. global), or consequences. It adds no value beyond the structured annotation, so transparency is lacking.

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

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

The description is a single, concise sentence with no fluff or irrelevant information. It is front-loaded with the action and object. While extremely brief, it is appropriately sized for a simple tool, though it could use a bit more detail for clarity.

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

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

Given the destructive hint and lack of output schema, the description is too thin to provide complete context. It does not clarify whether the hide action is permanent or reversible, what types of content are eligible, or how this differs from other content-hiding operations. The agent is left with an ambiguous understanding of the tool's effects.

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

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

The schema covers 100% of parameters with 'Content ID' and 'Content type'. The description does not elaborate on parameter semantics or interactions, so the baseline of 3 applies. The description's reference to 'content' does not add meaning beyond the schema.

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

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

The description uses a specific verb 'hide' with a clear resource 'content', indicating the tool's function. However, it does not differentiate from sibling tools like 'block_user' or 'flag', which also deal with content visibility. Overall, it clearly states what the tool does but lacks sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives such as 'save', 'unsave', 'block_user', or 'flag'. It does not mention prerequisites, exclusions, or any context for appropriate use. This leaves the agent without direction on tool selection.

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

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

Annotations contain only a title, so the description carries the burden for behavioral disclosure. It explains the mail-on-fire behavior for prompts and how repeat creates recurring events, adding meaningful context beyond the generic 'create' semantics.

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

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

Two sentences with no wasted words. The first sentence states the core purpose; the second packs the advanced options and a concrete example efficiently. The dash-separated clause is slightly long but still clear.

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

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

Coverage is strong: schema documents all parameter details, and the description explains the two non-obvious behavioral features (recurring + agent execution). With no output schema, not detailing return values is acceptable. Slight gap: no mention of what happens after creation (e.g., confirmation), but this is unlikely to block correct invocation.

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

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

Schema covers 100% of parameters, so baseline is 3. The description adds value by linking repeat and prompt together, showing how they combine for standing instructions — a relationship not explicitly stated in the individual parameter descriptions.

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

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

The description uses a specific verb ('Schedule') and resource ('reminder or event'), clearly distinguishing this creation tool from siblings like events_list and events_free. It also surfaces the key recurring/agent-execution capabilities that set it apart.

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

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

Provides clear guidance on when to use repeat and prompt, with a concrete example (morning briefing) for standing instructions. It does not explicitly name alternatives or exclusion criteria, but the context is strong and actionable.

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

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

Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds valuable behavioral context: it returns open slots, respects working hours, and takes a duration input. It does not contradict annotations.

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

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

The description is two sentences, front-loaded with the main purpose, and every word earns its place. It is concise without sacrificing clarity.

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

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

For a simple read-only tool with comprehensive schema and safe annotations, the description adequately explains the core functionality and output. It does not mention defaults for from/to or the exact working hours calculation, but these are documented in the schema.

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

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

Schema coverage is 100%, so parameters are already documented. The description adds context by referencing 'how long you need' (minutes) and 'within working hours' (day_start/day_end), but does not elaborate on from/to or parameter relationships beyond the schema.

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

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

The description clearly states the tool's purpose with a specific verb ('Find') and resource ('when you have nothing booked'). It distinguishes itself from sibling tools like events_create and events_list by focusing on availability search rather than event management.

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

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

The description implies usage by instructing the user to provide a duration and promising open slots within working hours, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool references are provided.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds behavioral context about filtering (upcoming) and sorting (soonest first), which goes beyond what annotations alone provide.

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

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

A single, focused sentence conveys both purpose and behavior. No wasted words, clearly front-loaded.

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

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

Given the tool has no parameters and is a straightforward list operation, the description is sufficiently complete. It explains scope and ordering, though it doesn't describe the exact return format, which is acceptable for a list tool.

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

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

There are zero parameters, and the baseline for zero-parameter tools is 4. No additional parameter explanation is needed since the schema is complete and trivial.

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

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

The description uses a specific verb ('List') and identifies the resource ('your upcoming scheduled events and reminders') with a clear ordering ('soonest first'). This clearly distinguishes it from event creation (events_create) and other browse tools.

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

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

The description conveys clear context: it returns upcoming scheduled events and reminders in chronological order. It doesn't explicitly mention alternatives or exclusions, but the 'upcoming' scope implies when to use it.

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

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

The destructiveHint annotation already signals that this is a destructive operation. The description adds context that the file must be owned by the user and that contents are deleted, which hints at the deletion scope. However, it does not disclose whether deletion is permanent or irreversible, which would be valuable beyond the generic destructive hint.

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

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

The description is a single, concise sentence that immediately states the action and resource. The phrase 'and its contents' is slightly redundant for a simple file but does not add unnecessary length. No filler or repetition; it effectively front-loads the core purpose.

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

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

For a simple one-parameter destructive tool with a destructiveHint annotation and no output schema, the description covers the action and a key constraint (ownership). However, it leaves ambiguity about the nature of 'contents' and does not explicitly state that deletion is permanent. This is a minor gap given the tool's simplicity.

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

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

The input schema provides 100% coverage for the single parameter 'id' with the description "The file's id". The tool description adds no further meaning about the parameter, such as format, source, or constraints. Since schema coverage is complete, the baseline of 3 applies, and no additional credit is earned.

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

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

The description clearly states the action (Delete) and the resource (a file you own), and further specifies that the file's contents are also deleted. This immediately distinguishes it from sibling tools like files_get or files_put, while the ownership qualifier adds a useful constraint without obscuring the purpose.

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

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

No guidance is provided on when to use this tool versus alternatives, nor are any exclusions or prerequisites mentioned. The ownership note implies a condition but does not explain when deletion is appropriate or what alternatives exist (e.g., whether to use files_put or share instead).

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description adds value by disclosing the return format: text comes back as text, anything else as base64. This is useful behavioral context beyond what annotations and schema provide.

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

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

Two short sentences with no wasted words. The key information is front-loaded and every sentence earns its place.

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

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

For a simple one-parameter read tool with supporting annotations and no output schema, the description covers purpose, id usage, and return encoding. It is complete for the tool's complexity.

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

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

Schema coverage is 100%, with the id parameter fully documented. The description only restates 'by its id' and does not add new semantic details, so it meets the baseline but does not exceed it.

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

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

The description clearly states a specific verb ('read'), resource ('stored file'), and access method ('by its id'). This distinguishes it from sibling tools like files_put, files_delete, and files_list, 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.

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

The context is clear: use this tool to retrieve a file by its id. However, it does not explicitly compare to alternatives or state when not to use it, missing the level of explicit guidance seen in high-scoring examples.

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

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

The annotations already declare read-only and idempotent behavior, so the description doesn't need to restate that. It adds behavioral detail beyond the annotations by specifying the sort order ('newest first') and the return fields ('URLs and ids'), which helps the agent understand what to expect. 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.

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

The description is a single, concise sentence that front-loads the main action and immediately provides key details. Every word adds value, with no redundancy or filler.

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

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

Given the tool's simplicity (no parameters, no output schema), the description covers the essential information: it lists files, sorting order, and key fields returned. It does not explain pagination or exact response format, but for a straightforward list tool with rich annotations, this is adequate. A higher score would require more detail, but the current level is sufficient.

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

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

The tool has zero parameters, and the schema is empty, so the baseline is 4 per the rubric. The description adds context by noting 'your stored files', implying user-specific data, which is useful. No parameter details are needed since none exist.

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

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

The description clearly identifies the tool's action ('List'), the resource ('your stored files'), and adds specific detail ('newest first, with their URLs and ids'). This distinguishes it from sibling tools like files_get, files_put, and files_delete, 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.

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

The description clearly implies when to use this tool: when you need to browse or list stored files. While it does not explicitly mention alternatives or exclusions, the context is clear enough given the presence of sibling file operations like get, put, and delete, and the title 'Browse files' reinforces the intended usage.

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

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

Annotations provide only the title, so the description carries the transparency burden. It reveals that the tool returns a URL and is intended for user-produced content, but it does not mention overwrite behavior, persistence guarantees, authentication needs, or 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.

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

The description is only two sentences. The first sentence is a direct statement of action and outcome; the second adds a practical use case. No filler or redundancy.

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

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

For a simple file-store tool with a rich input schema, this description is largely complete: it explains what the tool does and what the caller receives (a URL). It omits edge-case details like overwrite behavior and file size limits, but the low complexity and lack of an output schema make this acceptable.

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

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

Schema coverage is 100% and each parameter already has a clear description. The tool description adds examples like 'CSV' and 'transcript,' but these map loosely to existing schema descriptions without introducing new parameter semantics.

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

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

The description clearly states the action and resource: 'Store a file and get a URL for it.' It distinguishes this from sibling tools like files_get, files_list, files_delete, and files_share by focusing on creating/persisting a file and returning a link.

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

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

The description gives a clear use case: 'keep something you produced... and hand back a link.' This implies it is for saving generated artifacts, not for reading or managing existing files, though it does not explicitly name alternative tools.

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

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

The description discloses the core behavioral effect (public vs. private) and its reversibility ('or private again'). Annotations provide minimal information (only a title), so the description carries the burden; it does so adequately, though it does not mention potential security implications beyond 'anyone holding its URL'.

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

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

The description is a single, front-loaded sentence with no filler words, conveying purpose and effect efficiently.

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

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

For a simple 2-parameter tool with full schema coverage and no output schema, the description adequately covers the tool's purpose and behavior. No significant gaps remain.

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

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

The input schema already provides descriptions for both parameters, covering 100% of them. The description adds little new information about the parameters, mostly rephrasing the 'public' boolean effect. Baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Make') and resource ('stored file') with a clear outcome ('readable by anyone holding its URL, or private again'). This distinguishes it from sibling file tools like files_get, files_put, and files_delete.

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

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

The description clearly implies the tool is for toggling a file's public sharing status, which is distinct from upload/download/delete operations. However, it does not explicitly refer to alternatives 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.

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

Annotations only include a title and no readOnly/destructive hints, so the description carries the full burden. It states the action but does not disclose consequences such as reversibility, moderator notification, or visibility changes. No contradiction, but limited transparency.

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

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

A single, direct sentence that states the tool's purpose without filler or redundancy. It is front-loaded and appropriately sized for a simple action.

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

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

With no output schema and minimal annotations, the description should compensate by explaining usage context and side effects. It only covers the basic purpose; schema handles parameters, but the overall behavioral and contextual picture is thin for a mutation-like tool.

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

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

The input schema has 100% coverage with descriptions for both 'id' and 'type', so a baseline of 3 applies. The description adds no additional meaning or format expectations beyond what the schema already provides.

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

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

The description uses the specific verb 'Flag' and identifies the resource as 'content', while also stating the intent 'for moderation'. It is clear and distinguishes meaning from siblings like block_user or dismiss, though it does not explicitly contrast with them.

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

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

No guidance is provided on when to use this tool versus alternatives such as block_user, dismiss, or save. The phrase 'for moderation' implies a use case, but there are no exclusions, prerequisites, or comparisons to other tools.

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

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

Annotations provide no safety hints (no readOnlyHint, destructiveHint, etc.), so the description must bear full burden. It describes a lookup action but does not disclose potential limitations, required permissions, error behavior, or return format. Minimal information beyond the basic action.

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

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

The description is two short sentences, front-loaded with the core purpose and followed by a direct usage instruction. Every word earns its place, with no redundant phrasing.

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

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

Given the tool's simplicity (single optional parameter, no nested objects, no output schema), the description covers the essential usage. It implies the return of hadiths from the specified book, which is sufficient for a straightforward lookup tool.

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

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

Schema already documents the one parameter 'book' as 'Book number' (100% coverage). The description adds little beyond restating the parameter; it does not specify valid book numbers or range, so baseline of 3 is appropriate.

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

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

The description clearly states a specific action ('Look up hadith') with a precise resource ('Sahih Al Bukhari') and input ('book number'). It distinguishes from siblings like quran_search by focusing on hadith specifically.

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

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

It gives clear usage instructions: 'Pass a book number to get hadiths from that book.' However, it does not explicitly mention when to use this tool over alternatives, nor 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.

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

Annotations provide no behavioral hints (only title), so the description must carry the full burden. It discloses the core behavior (generation) and return format (URL), but omits potential caveats like authentication requirements, URL expiration, or content moderation. This is a reasonable but not exhaustive disclosure.

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

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

Two efficient sentences with no redundancy. The description is front-loaded with the action and resource, and every word earns its place. Ideal conciseness for a simple tool.

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

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

For a one-parameter tool with no output schema, the description covers the essential purpose and return format. It is nearly complete, though it could mention potential errors or limitations (e.g., service availability). Given the simplicity, the gap is minor.

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

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

Schema description coverage is 100% for the 'prompt' parameter, so the baseline is 3. The tool description adds no new meaning beyond restating that the input is a text prompt, which the schema already describes. No further elaboration is provided.

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

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

The description clearly states 'Generate an image from a text prompt' with a specific verb and resource, and distinguishes it from sibling tool images_search by focusing on generation rather than search. It also specifies the output format (URL), making the purpose unmistakable.

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

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

The description implies use when a new image is required from a text description, but it does not explicitly mention alternatives or exclusions. For instance, it doesn't say 'use images_search for existing images.' This is adequate but not explicitly guided.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds value by stating the output (image URLs) and that the library is public/community stock, but does not detail potential multi-page results or licensing nuances. This is a reasonable addition beyond annotations, yielding a 3.

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

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

The description is two concise sentences with the verb and resource front-loaded. Every word contributes to clarity, and there is no filler or redundancy.

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

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

For a simple single-parameter read-only search tool with strong annotations, the description provides complete context: what is searched (public image library), how (by description), and what is returned (image URLs to reuse). No output schema exists, so the description adequately covers return behavior.

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

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

The input schema has one parameter 'query' with description 'Search text', and the description reinforces that the search is by description. With 100% schema coverage, the description adds minimal semantic value beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool searches the public image library (community stock) by description, which is a specific verb+resource+scope. It distinguishes itself from siblings like images_generate by limiting to community stock images, 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.

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

The description implies usage context: it is for finding existing community stock images by description. It does not explicitly mention alternatives or exclusions, but the phrase 'community stock' effectively communicates the appropriate scenario, giving the agent enough context to choose this tool over image generation or web search.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description only needs to add extra context. It does so by disclosing the exact data sources searched (including the user's own mail) and noting that the output includes IDs. This exceeds baseline without contradicting annotations.

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

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

The description is two sentences with clear front-loading of the primary purpose. It includes a concise list of use-case examples without unnecessary fluff. Every word contributes.

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

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

For a cross-source search tool with no output schema, the description covers the scope of data, the output format (IDs), and real user intents. It could be more complete about result structure or ordering, but the essentials are present and the tool's behavior is clear enough for an agent to select and invoke it.

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

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

Schema description coverage is 100% for both parameters, so the baseline is 3. The description adds no new parameter semantics beyond what the schema already provides (e.g., no examples, defaults, or formats). It merely hints at query behavior through the overall purpose.

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

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

The description states a specific action ('Search across everything mu knows') with a clear scope of sources (indexed news, blog, social, video, mail) and an explicit output ('most relevant items with ids'). It distinguishes itself from sibling search tools (web_search, news_search, etc.) by emphasizing cross-source coverage.

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

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

The description explicitly lists when to use the tool with example queries ('do you remember', 'what did I get about X', 'search my stuff') and mentions 'cross-source lookups'. While it doesn't explicitly name alternatives or when-not-to-use, the examples implicitly differentiate from single-source search tools.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the output detail of 'which prayer is next' but does not explain calculation methods or timezone handling, which are only implied by the schema's tz parameter.

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

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

The description is a single, front-loaded sentence that immediately identifies the operation and key output. It contains zero waste.

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

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

For a simple read-only tool with three parameters and no output schema, the description covers the core purpose and highlights the notable next-prayer output. It omits return format details, but that is a minor gap given the tool's simplicity and the schema's completeness.

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

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

The input schema provides full (100%) coverage for all three parameters, so the baseline of 3 applies. The description's 'for a location' maps to lat/lon but adds no further semantic detail beyond the schema.

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

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

The description clearly states the tool retrieves today's Islamic prayer times for a location, explicitly listing the five prayers and adding the next-prayer feature. This is specific and distinguishes it from sibling tools like islam_qibla and islam_today.

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

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

The description implies the use case—getting prayer times for a location—but does not explicitly discuss when to choose this tool over alternatives or mention exclusions. Sibling names suggest differentiation, but the description itself lacks direct guidance.

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

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

Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds value by specifying the exact outputs (direction and distance) and clarifying what 'qibla direction' means (compass bearing to the Kaaba). No contradictions found, and the extra context about return values is useful for the agent.

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

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

The description is a single, focused sentence that front-loads the action and includes all necessary details. It is concise with no wasted words.

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

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

For a simple two-parameter tool with no output schema, the description adequately explains what the tool returns: qibla direction (bearing) and distance to Mecca. Minor details like units are not specified, but the core functionality is clear and complete for the intended use.

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

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

Schema description coverage is 100%, both lat and lon are described. The description does not add extra parameter semantics beyond what the schema already provides. Baseline score of 3 is appropriate since the schema handles parameter documentation.

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

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

The description clearly uses the verb 'Get' and specifies the resource: the qibla direction (compass bearing to the Kaaba) and distance to Mecca. This distinguishes it from sibling tools like islam_prayer or hadith, which serve different purposes.

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

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

The description provides clear context for when to use the tool: when you need the qibla direction and distance for a location. It does not explicitly list exclusions or alternatives, but the purpose is specific enough to imply appropriate usage. A score of 4 is appropriate for clear context without explicit alternatives.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds that the reminder includes a verse, hadith, and name of Allah, which gives useful context about the return content. However, it does not disclose the output format, language, or any other behavioral details beyond what annotations already imply. This is acceptable but not richly transparent.

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

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

The description is a single, well-structured sentence that front-loads the action and lists the key contents. Every word adds value, with no filler or redundancy. It is appropriately sized for the tool's simplicity.

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

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

Given the tool's minimal complexity (no parameters, no output schema, read-only annotation), the description fully covers what the tool returns and when it applies. It clearly differentiates from sibling tools by specifying the combined daily reminder, making the context complete for an agent to select and invoke it correctly.

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

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

The tool has zero parameters, so the baseline is 4. The description itself implies that no input is required ('Get today's...'), and the empty schema confirms this. Since there are no parameters to document, the description does not need to add further semantic detail beyond what the schema already provides.

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

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

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('today's daily Islamic reminder'), and enumerates its contents (verse, hadith, name of Allah). This distinguishes it from sibling tools like 'hadith' and 'quran', which focus on individual components, making the combined daily package unique.

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

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

Usage is implied rather than explicit: the description says what the tool does, so the agent can infer when to use it (when a combined daily reminder is needed). However, it does not provide explicit guidance on when not to use it or mention alternatives such as 'hadith' for a standalone hadith or 'quran' for verses. No exclusions are stated.

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

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

Annotations already declare readOnlyHint and idempotentHint, indicating a safe, repeatable operation. The description adds behavioral detail about the address format (you+tag@) and directs the agent to mail_inbox(tag) for reading mail, which goes beyond the structured fields. It does not contradict the annotations and provides additional context about tagging behavior.

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

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

The description is two sentences with the main action front-loaded. The second sentence efficiently explains the tag behavior and links to a sibling tool, with no redundant language.

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

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

For a simple tool with one optional parameter and no output schema, the description covers the purpose, tag usage, and interaction with a related tool (mail_inbox). It is sufficient for an agent to select and invoke the tool correctly, especially given the informative schema.

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

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

The input schema already provides a thorough description of the 'tag' parameter (a label, can be omitted, with examples). The description adds the exact address format (you+tag@) and the connection to mail_inbox(tag), enriching the parameter's meaning. Since schema coverage is 100%, this extra context pushes the score above baseline.

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

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

The description clearly states the tool's function: obtaining an email address that reaches the user. It distinguishes itself from siblings like mail_inbox and mail_send by explaining the tag-based addressing and reading workflow. The phrase 'Get an email address' is a specific verb-result pairing.

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

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

The description instructs when to use the tag parameter and how to pair the address with mail_inbox(tag) for reading mail. It implies a workflow (generate tagged address, share it, then use mail_inbox to read responses) but does not explicitly contrast with mail_send or state when not to use it. This gives clear context without explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds behavioral context about the plus-address filtering and its use case for agents, which goes beyond the annotations.

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

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

The description is two sentences, front-loaded with the core purpose, and every word earns its place. It is efficient and well-structured.

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

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

For a simple read tool with one optional parameter, the description covers the essential behavior and the tag nuance. There is no output schema, but the description is sufficient for an agent to understand what the tool does and how to invoke it.

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

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

Schema description coverage is 100% for the tag parameter, so baseline is 3. The description reinforces the parameter's meaning and adds the agent-specific rationale, providing extra value beyond the schema.

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

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

The description states a specific action 'Read your mail inbox' with a clear resource and scope. It also distinguishes from siblings like mail_send by focusing on reading, and explains the tag mechanism for agent-specific mail.

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

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

The description gives clear context on when to use the tool (to read mail) and how to use the tag parameter for agent-specific mail. It does not explicitly mention alternatives but the purpose is unambiguous and the tag usage guidance is useful.

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

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

With no annotations beyond the title, the description carries the full burden of behavioral disclosure. It only states 'Send a mail message' without revealing side effects (e.g., that it actually dispatches an email), authentication requirements, or error behavior. This is a minimal statement with no 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.

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

The description is a single short sentence with no wasted words. It is appropriately concise for a simple tool, though it adds little beyond the title and could be seen as slightly redundant.

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

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

Given the low complexity of the tool and the well-documented schema, the description might seem sufficient, but it omits any information about the return value or success/failure behavior. Since there is no output schema, adding such context would improve completeness.

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

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

The input schema covers all three parameters (to, subject, body) with descriptions, so schema coverage is 100%. The description adds no additional parameter semantics, so the baseline score of 3 applies.

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

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

The description 'Send a mail message' clearly identifies the action (send) and resource (mail message), which is specific enough to distinguish from sibling read tools like mail_inbox and mail_address. However, it is very close to the title and does not explicitly differentiate itself from other tools.

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

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

No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or comparison to mail_inbox or mail_address, leaving the agent 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.

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

Annotations already declare readOnlyHint and idempotentHint, so the read-only nature is covered. The description adds the 'live' aspect and category scope, but no further behavioral traits (e.g., rate limits, response format) are disclosed, which is acceptable given 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.

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

The description is a single sentence that is concise and front-loaded, providing the essential purpose and scope without extraneous information.

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

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

For a simple read-only list tool with one optional parameter and no output schema, the description is reasonably complete. It conveys the core functionality, though it does not specify the response structure, which is acceptable given the tool's simplicity.

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

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

The schema fully documents the single parameter with enum-like values and a default. The description repeats the categories, adding no new semantic meaning beyond the schema. Since schema coverage is 100%, a baseline of 3 is appropriate.

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

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

The description clearly states it retrieves live market prices for specific asset categories (crypto, futures, commodities, currencies). It uses a specific verb ('Get') and resource ('live market prices'), distinguishing it from other tools like news or social tools.

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

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

The description implies usage for obtaining market prices but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. It offers context on categories but lacks explicit guidance on when not to use it.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the bar is lower. The description adds a meaningful behavioral trait: the list is curated to be balanced across topics, not dominated by any single topic like crypto. This goes beyond the annotations.

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

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

Two sentences, front-loaded with the core purpose and a clear usage note. No filler or repetition. Every word earns its place.

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

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

For a simple list tool with two optional parameters and a read-only annotation, the description is complete. It states what is returned (headlines with short summaries) and gives a follow-up path. No output schema needed here.

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

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

Schema covers both parameters (limit, topic) with clear descriptions, and the tool description adds no extra parameter-level meaning. Baseline of 3 applies due to high schema coverage.

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

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

The description clearly states the verb ('Get'), resource ('news headlines'), and scope ('balanced across all topics, not dominated by one topic like crypto'). It distinguishes from sibling news_read by pointing to it for expanding articles, and from news_search by emphasizing general/briefing use.

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

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

Provides explicit context: 'Use for general news and briefing requests' and directs to news_read for follow-up. It gives a clear alternative but does not explicitly mention when not to use it (e.g., versus news_search), so it stops short of a full 5.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the read-only nature is known. The description adds useful behavioral context by specifying the return contents (title, source, summary, body) and the two accepted input forms (id or URL), going beyond the schema.

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

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

One clear, front-loaded sentence that states the verb, resource, output scope, and input source. No filler or redundant information.

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

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

For a simple single-parameter read tool with readOnly and idempotent annotations, the description is complete: it states the input (id or URL), the output fields, and the fact that it reads 'in full'. No output schema exists, so describing the return fields is sufficient.

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

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

Schema coverage is 100% — the only parameter id is described as 'Article id (from news_headlines) or article URL'. The description repeats this constraint without adding new parameter-level meaning, so the baseline of 3 applies.

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

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

The description clearly states the action ('Read') and the target ('one news article in full'), specifying included fields (title, source, summary, body). It also distinguishes from siblings like news_list and news_search by focusing on single-article retrieval by id or URL.

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

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

The description implies when to use this tool: when you have a specific article id (from news_headlines) or a URL and want the full article. It provides clear context, but does not explicitly name alternative tools like news_search or news_list or state when not to use it.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safe-read behavior is covered. The description adds no extra behavioral context like result ordering, pagination, or scope limitations, providing no value beyond the annotations.

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

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

The description is a single, tightly worded sentence with no filler. It is front-loaded with the action and resource, making it highly concise and efficient.

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

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

Given the simplicity of the tool (one parameter, annotations, no output schema), the description is minimally sufficient. However, it lacks any explanation of the return format or usage context, leaving some gaps for an agent that might want to know what a successful search returns or how to handle edge cases.

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

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

The input schema covers 100% of the parameters, with a clear description for 'query'. The description adds no additional meaning or context about how the query is interpreted (e.g., full-text, filters), but schema coverage suffices for a baseline 3.

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

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

The description states the action ('Search') and the resource ('news articles'), clearly communicating the tool's purpose. It is distinguishable from siblings like news_list or news_read through the explicit 'search' verb, though it doesn't explicitly differentiate itself from web_search or index_search.

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

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

The description offers no guidance on when to use this tool versus alternatives such as news_list, news_read, or web_search. There are no usage conditions, prerequisites, or exclusions mentioned.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description wisely adds context beyond them: that travel is by road (not straight-line), which is a key behavioral trait. It doesn't over-explain output or traffic, but the existing annotation coverage lowers the bar.

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

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

Two sentences, front-loaded with the core purpose and immediately useful examples. No filler or redundant information.

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

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

Given the simple nature of the tool and rich annotations, the description is sufficient. It covers the main function and typical use cases. Some details like travel modes or coordinate inputs are left to the schema, which is acceptable.

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

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

Schema coverage is 100%, with each parameter having a clear description. The tool description adds no extra parameter-level detail, but the schema already handles semantics. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: computing travel time between two places by road. It distinguishes from sibling tools like places_search and places_nearby by specifying 'by road rather than as the crow flies' and providing concrete use cases.

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

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

The description provides clear context on when to use it ('answer whether somewhere is worth going to, or when to leave') but does not explicitly mention alternative tools or exclusions. It effectively implies usage scenarios without naming sibling tools.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds no extra behavioral context (e.g., response format, limits), but it does not contradict the annotations.

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

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

The description is a single sentence with no filler, making it concise and well-structured. Every word contributes to the meaning.

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

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

With 4 optional parameters and no output schema, the description does not clarify that a location parameter is needed or whether lat/lon and address are mutually exclusive. This is a significant gap for an agent deciding how to invoke the tool.

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

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

Schema description coverage is 100%, so each parameter already has a description. The tool description does not add any additional parameter semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description 'Find all places of interest near a given location' clearly states the verb (Find), resource (places of interest), and scope (near a location). It is specific, though it does not explicitly distinguish from sibling tools like places_search or places_eta.

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

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

No guidance is provided about when to use this tool versus alternatives such as places_search or places_eta. It also does not clarify whether lat/lon and address are mutually exclusive or that at least one location parameter is required.

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

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

Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds search scope but no behavioral traits like result limits, pagination, or matching behavior. It does not contradict annotations.

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

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

Single sentence with no fluff, front-loaded with verb and resource. Every word earns its place.

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

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

For a simple read-only search with fully documented parameters and safety annotations, the description is adequate. It conveys core functionality, though it omits result format, which is minor given no output schema.

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

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

Schema coverage is 100%, so all parameters are documented. The description adds no parameter semantics beyond what the schema provides (e.g., it essentially restates the query and near params). Baseline 3 applies.

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

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

The description uses the specific verb 'search' with resource 'places' and clarifies scope: 'by name or category, optionally near a location'. This clearly distinguishes it from siblings like places_nearby and places_eta, which are location- or time-oriented.

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

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

Provides clear context: this is for query-based search (name/category) with optional location filtering. It does not explicitly name alternative tools or exclusions, but the context is enough to differentiate from nearby/eta siblings.

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

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

Annotations provide only a title with no read-only or destructive hints, so the description carries full responsibility for behavioral disclosure. 'Look up' implies a read operation, but the description doesn't state whether it returns the Arabic text, translation, or full chapter when verse is omitted (the schema mentions this, but the description doesn't add context).

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

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

One concise sentence that is front-loaded with the core action and includes essential parameter guidance. Every word earns its place; no fluff or redundancy.

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

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

For a simple two-parameter tool with no output schema, the description is adequate but incomplete. It doesn't mention the return format, language, or that omitting the verse returns the full chapter (though the schema does). It lacks usage context and alternative guidance, leaving room for improvement.

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

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

Schema description coverage is 100%, with both parameters already documented. The description repeats chapter range and verse optionality without adding new meaning or clarifying formats, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Look up') and identifies the resource ('Quran chapter or verse') with clear parameter scope (chapter 1-114). It is unambiguous, though it doesn't explicitly differentiate from the sibling quran_search tool, which could cause some confusion.

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

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

It provides instructions on how to call the tool ('Pass chapter number... optionally a verse number') but gives no guidance on when to use this tool versus alternatives like quran_search. No exclusions or prerequisites are mentioned, leaving context unclear.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds context that it uses semantic search and accepts natural language questions, but does not disclose return format, result structure, or limitations. This is adequate given annotations but not rich.

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

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

The description is two concise sentences, front-loaded with the action and scope, and contains no repetitive or extraneous content. Every word earns its place.

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

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

For a simple one-parameter search tool with read-only annotations and no output schema, the description adequately explains what to search and how. It could mention result format, but given the tool's simplicity and annotation support, it is sufficiently complete.

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

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

The schema fully describes the single 'query' parameter as 'Question or search query' (100% coverage). The description's phrase 'Ask a question in natural language' reinforces the parameter meaning but adds no new syntax or format details, matching the baseline for high schema coverage.

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

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

The description clearly states the tool searches the Quran, Hadith, and names of Allah using semantic search, which is specific and resource-focused. However, it does not explicitly distinguish from sibling tools like 'quran' or 'hadith', though the semantic search aspect provides some differentiation.

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

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

The description implies usage by instructing users to ask a question in natural language, but it does not provide explicit when-to-use guidance or mention alternatives such as the 'quran' or 'hadith' tools. The context is clear but lacks exclusions or comparisons.

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

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

Annotations carry only a title and no readOnly/destructive hints, so the description bears full responsibility for disclosing behavioral traits. 'Bookmark content for later' does not mention side effects (e.g., duplicate saves, overwrite behavior), authentication requirements, or failure modes, leaving significant gaps 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.

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

The description is a single, short sentence, with no redundant words or structural clutter. However, it is under-specified given the tool's mutation nature and lack of annotation support, so while concise, it sacrifices necessary detail.

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

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

For a simple two-parameter tool, the purpose and schema collectively provide enough to invoke it. However, missing behavioral details (e.g., what happens on duplicate save, whether unsave is the way to remove) and no usage guidance keep it from being fully complete in context.

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

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

Schema description coverage is 100%, with id and type each described. The description adds only the context 'bookmark content for later', which reinforces that parameters refer to content but does not enrich parameter semantics beyond the schema.

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

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

The description 'Bookmark content for later' clearly identifies the action (bookmark) and the resource (content), providing a specific purpose. It does not explicitly distinguish from sibling tools like unsave or saved_list, but the verb 'bookmark' plus 'for later' conveys the core function unambiguously.

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

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

The description provides no guidance on when to use this tool versus alternatives such as unsave or saved_list. It implies usage for saving content for later, but there are no explicit exclusions, prerequisites, or alternative tool references.

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

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

The annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds the 'bookmarks' synonym and notes that links are returned, but does not explain behavior such as ordering, pagination, or whether the list is limited in size. Given the annotations cover the main behavioral concern, a mid-range score is appropriate.

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

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

The description is a single, front-loaded sentence that immediately states the verb and object. It contains no filler or repetition of the tool name/title, earning every word.

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

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

The tool is simple, has no parameters, and its annotations cover safety. The description explains what is returned (saved items with links), which is sufficient for an agent to select and invoke it. A dedicated output schema or more detail on return structure would be helpful but is not essential for such a basic list operation.

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

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

The tool has zero parameters, so the description bears no burden for explaining parameter usage. The baseline for no parameters is 4, and there is no schema information that would require additional clarification.

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

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

The description clearly states the action ('List') and the resource ('items you've saved for later'), with the additional detail that it includes links. It distinguishes this from sibling tools like save and unsave by indicating it is the retrieval counterpart.

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

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

The description clearly implies the tool is for viewing saved/bookmarked items, which is a distinct use case from saving or unsaving. It doesn't explicitly mention alternatives or exclusions, but the context is unambiguous for a simple list tool.

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

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

Annotations already declare the tool as read-only and idempotent, so the description does not need to restate safety. It adds minor behavioral context ('latest', 'network') but omits details like pagination or output structure.

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

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

The description is a single sentence with no wasted words, placing the core action and object upfront.

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

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

Given the zero-parameter design and safety annotations, the description is largely sufficient for an agent to select this tool. It could have mentioned output format or result count, but those are not critical for a simple list operation.

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

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

The tool has zero parameters, giving a baseline of 4. The description does not need to explain parameters, and the schema is already comprehensive (empty).

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

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

The description specifies a clear retrieval action ('get') and resource ('latest social posts'), with scope ('from the network'). It is distinguishable from the sibling social_search based on the name, but the description itself does not explicitly contrast them.

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

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

There is no explicit statement of when to use this tool versus alternatives like social_search or stream_list. The intended use case is implied by 'latest social posts' but no exclusions 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.

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

The annotations already declare readOnlyHint and idempotentHint, so the safety profile is established. However, the description adds no further behavioral context, such as result limits, ordering, date ranges, or whether only certain platforms are searched. It provides no value beyond what annotations already convey, and there is 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.

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

The description is a single, clear sentence with no redundant words. It is front-loaded with the core purpose and is appropriately sized for a straightforward search tool, earning the highest score for conciseness.

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

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

Given the tool's simplicity (one parameter, read-only, no output schema), the description gives a basic understanding of the tool, but it omits details about what the result set contains, how results are ordered, or any platform-specific scope. There is no output schema to fill these gaps, so the description is adequate but incomplete for agent decision-making.

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

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

The input schema fully documents the single 'query' parameter with a description ('Search query for social posts'), so schema coverage is 100%. The tool description's 'Search social media posts' adds no extra meaning about query syntax, supported filters, or output formatting, leaving the agent with only the schema information. Baseline 3 is appropriate.

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

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

The description states the tool's function with a specific verb ('Search') and resource ('social media posts'), clearly indicating what it does. It is distinct enough from list-oriented siblings like social_list, but it does not explicitly differentiate from other search tools or note any scope constraints, so it earns a 4 rather than a 5.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives such as social_list, stream_list, or other search tools. It also lacks any mention of prerequisites, exclusions, or typical use cases, leaving the agent to infer based solely on the name and one-line description.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description reinforces the read-only nature. It adds useful behavioral context about the content of the stream (messages, agent responses, system events), but does not disclose ordering, pagination, or retention limits, leaving some behavioral uncertainty.

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

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

A single, front-loaded sentence with a dash-delimited list of examples conveys the core purpose and scope without wasted words. Every element earns its place.

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

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

For a zero-parameter, read-only tool with no output schema, the description adequately explains what the tool exposes. It could mention return format or limits, but the simplicity of the tool keeps the gap small.

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

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

There are no parameters and schema description coverage is 100%, so there is nothing for the description to clarify. The baseline for zero-parameter tools is 4, and the description does not attempt to invent parameter constraints.

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

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

The description uses a specific verb ('Read') with a clear resource ('the platform event stream'), and enumerates concrete content types (user messages, agent responses, system events). This distinguishes it from siblings like stream_post (which writes) and news_list/markets_list (which address narrower event categories).

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

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

The description clearly implies use for browsing the overall platform feed, contrasting with write-oriented siblings such as stream_post. It does not explicitly name alternatives or exclusions, but for a zero-parameter read tool, the context is sufficient to guide selection.

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

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

Annotations provide no behavioral hints (only title), so the description carries full burden. It discloses one behavioral trait: mentioning @micro triggers an AI response. However, it does not mention whether posts are public, auth requirements, or success/error behavior, which are relevant for a write operation.

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

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

Two concise sentences, front-loaded with the core purpose, and the second sentence adds a behavioral nuance without unnecessary detail. No redundancy or fluff.

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

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

For a simple one-parameter tool with no output schema, the description adequately covers the main action and a key behavioral trigger. It could mention what happens on success (e.g., where the post appears) but is otherwise complete for its complexity.

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

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

Schema coverage is 100% with a full description of the `content` parameter (max length and @micro usage). The description essentially repeats that information and adds no new parameter-level meaning, so it does not exceed the schema baseline.

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

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

The description clearly states the action ('Post a message') and the resource ('to the stream'), making it distinct from sibling tools like `stream_list`. It also adds a specific usage nuance with @micro, which helps distinguish from generic messaging tools.

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

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

The description implies when to use the tool (to post to the stream) and gives a usage tip (mention @micro), but it does not explicitly exclude alternatives or mention when not to use it. There is no comparison with sibling tools like `chat` or `mail_send`, leaving the usage context somewhat implicit.

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

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

Annotations provide only a title with no readOnlyHint or destructiveHint, so the description carries the burden of behavioral disclosure. It only says 'Unblock a previously blocked user' without explaining side effects, idempotency, what happens if the user is not blocked, or any response details. This is insufficient 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.

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

The description is a single concise sentence that conveys the essential purpose without any filler. It is appropriately sized and front-loaded.

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

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

The tool is simple with one parameter and no output schema, so a brief description might suffice. However, the lack of behavioral transparency (side effects, error cases) and minimal annotations leave some contextual gaps, making it only minimally complete.

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

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

The single parameter 'user' is fully documented in the schema as 'User ID to unblock'. The description adds no extra semantic value beyond the schema, so with 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the action ('Unblock') and the resource ('a previously blocked user'), which precisely distinguishes it from the sibling tool 'block_user'. The scope 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.

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

The phrase 'previously blocked' implicitly indicates this tool is used after a user has been blocked, but it does not explicitly mention alternatives, exclusions, or when not to use it. There is no direct guidance on choosing between this and block_user.

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

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

The destructiveHint annotation already declares the destructive nature, and the description consistently says 'Remove'. However, it adds no additional behavioral context beyond that, such as reversibility, side effects, or ownership requirements.

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

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

The description is a single, concise sentence that states the action and object without unnecessary words or repetition. It is front-loaded and efficient.

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

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

Given the tool's simplicity (2 parameters, no output schema), the description adequately covers the core purpose. It could mention edge cases like unsaving an item that was never saved, but overall it provides sufficient context.

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

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

Schema coverage is 100% with descriptions for both parameters ('Content ID' and 'Content type'), so the schema already provides the necessary semantics. The tool description adds no further parameter information, meeting the baseline for high schema coverage.

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

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

The description clearly uses the verb 'Remove' with the resource 'saved bookmark', making the tool's function unambiguous. It also distinguishes from sibling tools like 'save' and 'saved_list' by indicating this is the inverse operation.

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

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

The description implies when to use the tool (when you want to remove a previously saved item) but does not explicitly state usage context or mention alternatives. No exclusions or when-not-to-use guidance is provided.

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

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

Annotations already declare readOnlyHint and idempotentHint, aligning with a read operation. The description adds context about curated channels and recency, but doesn't disclose specifics like pagination, ordering, or what constitutes 'curated.' No contradiction 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.

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

The description is a single concise sentence that directly states the tool's function without extraneous detail.

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

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

For a parameterless read-only tool, the description provides adequate context to understand its purpose. However, the term 'curated channels' is unspecified, and without an output schema, some return-format details could be clearer. Overall, it's reasonably complete.

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

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

The tool has zero parameters, so the schema is fully covered. The description doesn't need to explain parameters; baseline 4 applies.

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

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

The description uses a specific verb ('Get') and resource ('latest videos') with a qualifier ('from curated channels'), clearly indicating a browse/list operation. It distinguishes from video_search implicitly by focusing on curated content rather than search, though it doesn't explicitly name alternatives.

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