Server Quality Checklist

Tool Scores

• like_articleC
  2/5.0
  Behavior1/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure but fails to do so. It doesn't reveal if this is a read-only or mutative operation, what permissions are required, potential side effects, or response format, leaving critical behavioral traits unspecified.

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

  Conciseness5/5

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

  The description is extremely concise with a single sentence, 'Like an article,' which is front-loaded and wastes no words. While it lacks substance, it earns full marks for brevity and structure, as every word serves the minimal purpose stated.

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

  Completeness1/5

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

  Given the complexity of a mutative tool with no annotations and no output schema, the description is completely inadequate. It fails to explain what 'liking' entails, the expected outcome, or how it integrates with sibling tools, leaving significant gaps in understanding the tool's role and behavior.

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

  Parameters3/5

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

  The input schema has 100% description coverage, documenting all three parameters clearly, so the description doesn't need to add parameter details. However, it also doesn't provide any additional context or meaning beyond the schema, such as explaining the relationship between parameters, resulting in a baseline score.

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

  Purpose2/5

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

  The description 'Like an article' is a tautology that merely restates the tool name and title without adding specificity. It doesn't distinguish this tool from sibling tools like 'add_comment' or 'update_article' in terms of action or resource, leaving the purpose vague beyond the basic verb-noun pairing.

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

  Usage Guidelines1/5

  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. It doesn't mention prerequisites, context, or exclusions, such as whether it's for authenticated users only or how it differs from related actions like commenting or updating articles, making it misleadingly simplistic.

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

• upload_fileC
  2.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('upload') but doesn't describe traits like required permissions, file size limits, supported formats beyond vague examples, error handling, or what happens after upload (e.g., returns a URL or ID). This leaves significant gaps for a mutation tool.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to scan. Every word contributes to conveying the basic purpose without unnecessary elaboration.

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

  Completeness2/5

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

  Given the complexity of a file upload tool (a mutation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits, usage context, and output expectations, leaving the agent with insufficient information to invoke it correctly beyond the basic schema.

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

  Parameters3/5

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

  The schema description coverage is 100%, with clear descriptions for both parameters ('file_path' and 'sid'). The description adds no meaning beyond this, as it doesn't explain parameter interactions, the purpose of 'sid', or file path constraints. With high schema coverage, 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.

  Purpose3/5

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

  The description states the verb ('upload') and resource ('a file'), but it's vague about what types of files are supported ('image, document, etc.') and doesn't distinguish this tool from potential siblings like 'create_article' or 'create_note', which might also involve file uploads. It provides a basic purpose but lacks specificity.

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

  Usage Guidelines2/5

  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. For example, it doesn't clarify if this is for standalone file uploads versus attachments in other tools like 'create_article', or mention prerequisites like authentication. The description offers no context for usage decisions.

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

• add_commentC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool adds a comment but doesn't describe what happens after submission (e.g., comment appears publicly, requires moderation, triggers notifications). For a mutation tool with zero annotation coverage, this lack of behavioral details is a significant gap.

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

  Conciseness5/5

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

  The description is a single, direct sentence with zero wasted words. It front-loads the core action ('Add a comment') and target ('to an article'), making it immediately scannable and efficient for an agent.

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

  Completeness2/5

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

  Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, error conditions, or return values. While the schema covers parameters well, the overall context for safe and effective use is lacking.

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

  Parameters3/5

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

  Schema description coverage is 100%, with each parameter clearly documented in the schema (e.g., 'gid' as article ID, 'pid' for replies). The description adds no parameter-specific information beyond implying 'gid' is needed to target an article. This meets the baseline of 3 since the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Add') and target ('comment to an article'), making the purpose immediately understandable. It distinguishes from siblings like 'create_article' or 'update_article' by focusing specifically on commenting functionality. However, it doesn't explicitly differentiate from potential comment-related tools like 'reply_to_comment' (though none exist in siblings), keeping it from a perfect score.

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

  Usage Guidelines2/5

  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. It doesn't mention prerequisites (e.g., article must exist), exclusions (e.g., cannot comment on drafts), or related tools like 'get_comments' for viewing comments. Without such context, the agent must infer usage from the tool name alone.

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

• create_articleC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a new blog article' implies a write/mutation operation but provides no information about permissions required, whether creation is reversible, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral transparency.

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

  Conciseness5/5

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

  The description is maximally concise with a single sentence that gets straight to the point. There's zero wasted language or unnecessary elaboration - it's front-loaded with the essential information about what the tool does.

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

  Completeness2/5

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

  For a mutation tool with 9 parameters, no annotations, and no output schema, the description is inadequate. It doesn't address behavioral aspects, error conditions, return values, or how this tool relates to siblings. The combination of being a write operation with complex inputs requires more contextual information than provided.

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

  Parameters3/5

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

  The description adds no parameter information beyond what's already in the schema (which has 100% coverage). All 9 parameters are documented in the schema with descriptions, so the baseline score of 3 is appropriate. The description doesn't provide additional context about parameter relationships, default behaviors, or usage patterns.

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

  Purpose4/5

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

  The description clearly states the verb ('Create') and resource ('blog article'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_note' or 'update_article' - it just states the basic function without clarifying what distinguishes this specific article creation tool.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'create_note' or 'update_article'. There's no mention of prerequisites, appropriate contexts, or when this specific article creation tool should be chosen over other creation/mutation tools in the sibling list.

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

• create_noteC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Create a new micro-note', implying a write/mutation operation, but doesn't disclose any behavioral traits such as permissions required, whether notes are ephemeral or persistent, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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

  Conciseness5/5

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

  The description is extremely concise with a single sentence ('Create a new micro-note') that directly states the purpose without any fluff. It is front-loaded and wastes no words, making it efficient for quick understanding. Every word earns its place by conveying essential action and resource information.

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

  Completeness2/5

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

  Given the tool's mutation nature (creating a note), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, error handling, or return values, which are critical for an agent to use the tool correctly. The high schema coverage helps with parameters, but overall context for safe and effective usage is lacking.

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

  Parameters3/5

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

  Schema description coverage is 100%, with clear descriptions for both parameters ('t' as content, 'private' with enum values). The description adds no parameter semantics beyond what the schema provides, as it doesn't mention parameters at all. Given high schema coverage, the baseline score of 3 is appropriate, as the schema adequately documents parameters without needing description supplementation.

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

  Purpose4/5

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

  The description clearly states the action ('Create') and resource ('new micro-note'), making the purpose immediately understandable. It distinguishes from siblings like 'add_comment' or 'create_article' by specifying 'micro-note' as the resource type. However, it doesn't explicitly differentiate from 'create_article' beyond the resource name, missing a clear distinction in scope or format.

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

  Usage Guidelines2/5

  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. It doesn't mention when to choose 'create_note' over 'create_article' or 'add_comment', nor does it specify prerequisites, contexts, or exclusions for usage. This leaves the agent without explicit direction for tool selection among siblings.

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

• get_articleC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool retrieves an article but doesn't describe what happens if the ID is invalid, whether it returns full or partial content, if authentication is needed, or error handling. This leaves significant gaps in understanding the tool's behavior beyond basic retrieval.

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

  Conciseness5/5

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

  The description is extremely concise with a single sentence that directly states the tool's purpose. It's front-loaded with the core action and contains no unnecessary words or redundant information, making it highly efficient for quick understanding.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description is incomplete for a retrieval tool. It doesn't explain what is returned (e.g., article content, metadata), error conditions, or authentication needs. For a tool with 2 parameters and no structured behavioral hints, more context is needed to fully understand its operation.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents both parameters ('id' and 'password'). The description adds no additional meaning beyond what's in the schema, such as explaining ID formats or when the password is required. This meets the baseline score of 3 since the schema handles parameter documentation adequately.

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

  Purpose4/5

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

  The description clearly states the action ('Get') and resource ('a specific article by ID'), making the purpose immediately understandable. It distinguishes from siblings like 'search_articles' by focusing on retrieval of a single item rather than searching multiple. However, it doesn't explicitly contrast with other read operations like 'get_draft_detail' or 'get_comments', which slightly limits differentiation.

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

  Usage Guidelines2/5

  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. It doesn't mention when to choose 'get_article' over 'search_articles' for finding articles, or when to use it versus 'get_draft_detail' for draft content. There are also no prerequisites or exclusions stated, such as requiring authentication or article visibility.

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

• get_commentsC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'pagination support', which adds some context about handling large datasets, but fails to cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or what the return format looks like (e.g., structure of comments).

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

  Conciseness5/5

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

  The description is extremely concise and front-loaded, consisting of a single sentence that directly states the tool's function and key feature (pagination). There is no wasted text, making it efficient for an agent to parse.

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

  Completeness2/5

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

  Given the complexity of a tool that retrieves data with pagination, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., safety, performance), output structure, and usage context, leaving significant gaps for an agent to operate effectively.

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

  Parameters3/5

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

  The input schema has 100% description coverage, clearly documenting both parameters ('id' and 'page'). The description adds minimal value by implying the tool fetches comments for an article and supports pagination, but doesn't provide additional semantics beyond what the schema already states, such as pagination behavior details or format constraints.

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

  Purpose4/5

  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 ('comments for an article'), distinguishing it from siblings like 'get_article' or 'add_comment'. However, it doesn't explicitly differentiate from potential similar tools beyond the sibling list provided, such as if there were a 'get_all_comments' tool.

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

  Usage Guidelines2/5

  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. It mentions pagination support but doesn't specify when pagination is needed or how it relates to other tools like 'get_article' or 'search_articles', leaving the agent to infer usage context.

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

• get_draft_detailC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states it retrieves details without mentioning whether this is a read-only operation, if it requires authentication, what happens if the draft doesn't exist, or the format of the returned details. This leaves significant gaps for a tool that fetches data.

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

  Conciseness5/5

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

  The description is a single, straightforward sentence with no wasted words. It's front-loaded and efficiently conveys the core action, making it easy to parse quickly.

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

  Completeness2/5

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

  Given the complexity of fetching specific data, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral aspects like error handling, return format, or authentication needs, which are crucial for proper tool invocation in this context.

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

  Parameters3/5

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

  The description doesn't add meaning beyond the input schema, which has 100% coverage and clearly documents the 'id' parameter as 'The ID of the draft to retrieve'. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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

  Purpose4/5

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

  The description clearly states the verb ('Get') and resource ('details of a specific draft'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_draft_list' or 'get_article', which would require more specificity about what 'details' entail.

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

  Usage Guidelines2/5

  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. For example, it doesn't explain when to use 'get_draft_detail' versus 'get_draft_list' or 'get_article', nor does it mention prerequisites like needing a draft ID.

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

• get_draft_listC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose permissions, rate limits, pagination, sorting, or return format (e.g., list structure). This is inadequate for a tool with potential complexity in list retrieval.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste. It is front-loaded and appropriately sized for a simple tool, earning full marks for conciseness.

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

  Completeness2/5

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

  Given no annotations and no output schema, the description is incomplete. It lacks details on behavior, return values, and usage context, which are essential for an agent to effectively use this tool in a system with multiple article-related siblings.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents the 'count' parameter. The description adds no parameter semantics beyond what the schema provides, meeting the baseline of 3 for high coverage without extra value.

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

  Purpose4/5

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

  The description clearly states the verb 'Get' and the resource 'list of draft articles', making the purpose understandable. It distinguishes from siblings like 'get_draft_detail' (specific draft) and 'get_article' (published articles), but could be more specific about scope (e.g., all drafts vs filtered).

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

  Usage Guidelines2/5

  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 like 'search_articles' (which might filter drafts) or 'get_draft_detail' (for a single draft). The description implies usage for retrieving drafts but lacks explicit context or exclusions.

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

• search_articlesC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the search functionality but doesn't describe pagination behavior (implied by 'page' parameter), rate limits, authentication requirements, or what the response format looks like (no output schema exists). This leaves significant gaps for a search tool.

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

  Conciseness5/5

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

  The description is extremely concise - a single sentence that efficiently communicates the core functionality. There's no wasted language, and it's appropriately front-loaded with the essential information about what the tool does.

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

  Completeness2/5

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

  For a search tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the search behavior (AND/OR logic), result format, pagination details, or error conditions. The agent would need to infer too much from just the parameter descriptions.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description mentions keyword, tag, and category filtering but doesn't add meaningful semantic context beyond what the schema provides about these parameters. Baseline 3 is appropriate when schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the tool's purpose as searching articles using specific criteria (keyword, tag, or category). It uses a specific verb ('Search') and identifies the resource ('articles'), but doesn't explicitly differentiate from sibling tools like 'get_article' which retrieves a single article rather than searching multiple.

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

  Usage Guidelines2/5

  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. It doesn't mention sibling tools like 'get_article' for retrieving specific articles or 'get_draft_list' for draft articles, nor does it specify prerequisites or contextual constraints for searching.

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

• get_user_infoB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get current user information' but doesn't clarify what 'current' means (e.g., logged-in user, default user), whether it's a read-only operation, what permissions are required, or the format of returned data. This leaves significant gaps in understanding the tool's behavior beyond basic purpose.

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

  Conciseness5/5

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

  The description is extremely concise with a single sentence ('Get current user information'), which is front-loaded and wastes no words. For a simple tool with no parameters, this brevity is effective and appropriate, making it easy to parse quickly.

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

  Completeness2/5

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

  Given the tool's simplicity (0 params, no output schema, no annotations), the description is minimal but incomplete. It lacks details on behavioral aspects like authentication needs, data format, or error handling. While the schema handles inputs, the description should provide more context for a tool that retrieves user information, especially without annotations to fill in gaps.

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

  Parameters4/5

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

  The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate here. Baseline is 4 for 0 params, as the schema fully covers the absence of inputs, and the description doesn't need to compensate for any gaps.

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

  Purpose4/5

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

  The description clearly states the action ('Get') and resource ('current user information'), making the tool's purpose understandable. However, it doesn't differentiate from potential sibling tools that might also retrieve user information (though none are listed in siblings), so it's not fully specific. The verb+resource combination is straightforward but lacks nuance about what 'information' entails.

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

  Usage Guidelines2/5

  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. It doesn't mention prerequisites, context for 'current user' (e.g., authentication needed), or compare it to other tools like 'get_article' or 'get_comments'. Without such guidance, an agent might struggle to select this tool appropriately in scenarios involving user data retrieval.

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

• update_articleB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the draft behavior, which is valuable context about how the tool handles state transitions. However, it doesn't disclose other important behavioral traits like whether this requires authentication, what permissions are needed, whether updates are reversible, rate limits, or what happens to unspecified fields (partial vs. full updates). For a mutation tool with zero annotation coverage, this leaves significant gaps.

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

  Conciseness4/5

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

  The description is appropriately sized with two clear sentences. The first sentence states the core purpose, and the second adds important behavioral context about draft handling. There's no wasted language, and the information is front-loaded with the essential action first.

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

  Completeness3/5

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

  For a mutation tool with no annotations and no output schema, the description provides basic purpose and some behavioral context (draft handling), but it's incomplete. It doesn't cover authentication needs, error conditions, response format, or how partial updates work. Given the complexity of updating an article with 8 parameters, more contextual information would be helpful for the agent to use this tool effectively.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly with descriptions, types, and constraints. The description doesn't add any parameter-specific information beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

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

  Purpose4/5

  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 article'), making the purpose immediately understandable. It distinguishes from siblings like 'create_article' by specifying it updates existing articles rather than creating new ones. However, it doesn't explicitly differentiate from other update-related tools that might exist in the broader context.

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

  Usage Guidelines3/5

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

  The description provides implied guidance about draft behavior ('If the article is currently a draft and no draft parameter is specified, it will remain as a draft'), which helps understand when to use this tool versus alternatives for publishing. However, it doesn't explicitly state when to use this tool versus other siblings like 'create_article' or provide clear exclusions or prerequisites for usage.

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