Server Quality Checklist

Tool Scores

• dooray_calendar_calendarsC
  2.4/5.0
  Behavior1/5

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

  No annotations are provided, and the description only states 'find dooray calendars'. It does not disclose whether this is a read-only operation, what the response contains, or any side effects. The description carries the full burden and fails to deliver.

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

  Conciseness2/5

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

  The description is extremely brief, consisting of only three words. While concise, it is under-specified and lacks sufficient detail to be actionable. It is not appropriately sized because it omits critical 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 absence of an output schema and annotations, the description should explain return values and behavior, but it does not. Even for a simple tool, the description is incomplete and leaves the agent with unanswered questions.

  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 has 100% coverage for the single 'operation' parameter, which includes an enum value 'find_calendars'. The description adds no additional meaning; it simply restates the operation. The schema's own parameter description is generic, so the tool description does not enhance understanding.

  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 uses the verb 'find' and the resource 'dooray calendars', clearly indicating a retrieval operation. However, it does not specify whether it lists all calendars or searches by criteria, and it doesn't explicitly distinguish from sibling calendar tools, though the sibling tool names suggest different actions.

  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?

  There is no mention of when to use this tool versus alternative calendar tools like dooray_calendar_events or dooray_calendar_post_event. The description provides no context for selecting this tool.

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

• osC
  2.7/5.0
  Behavior2/5

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

  With no annotations, the description carries full behavioral disclosure burden. It only states the action 'get' which implies a read-only operation, but it doesn't disclose return format, timezone behavior, error conditions, or whether any side effects occur. Minimal extra context is provided.

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

  Conciseness2/5

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

  The description is extremely short, but it's under-specified rather than efficiently concise. It lacks sentence structure and leaves ambiguity about what 'os' refers to. This is more like a fragment than a well-formed tool description.

  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 one parameter, an enum, and no output schema, the description should at least hint at the return value or any OS-specific behavior. It doesn't. The agent is left to infer what 'get_date_time' actually returns or how it behaves, making the tool insufficiently documented.

  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 coverage is 100% with a single parameter 'operation' that has an enum description. The description itself adds no parameter-level detail, but the schema already fully documents the parameter. Thus the baseline 3 applies.

  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 'get os time date' clearly indicates the tool retrieves the operating system's time and date. While the phrasing is awkward and doesn't explicitly distinguish from siblings, the tool name 'os' and the description make the purpose unambiguous enough for an agent.

  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, nor does it mention any prerequisites or exclusions. Sibling tools are all Dooray-related, so this OS tool is distinct, but the description fails to state any usage context.

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

• dooray_calendar_post_eventC
  2.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It only states the action 'register' without mentioning side effects, return values, error conditions, permissions, or reentrancy. This is minimal and leaves the agent guessing about the tool's actual behavior.

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

  Conciseness3/5

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

  The description is a single, concise sentence with no fluff. However, it is undersized for a tool with 14 parameters and complex recurrence options. While it is not verbose, it does not earn its place by providing sufficient information, so it is only marginally acceptable.

  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?

  The tool has 14 parameters, including recurrence rules, timezones, and calendar IDs, but no output schema or annotations. The description covers only the basic action, leaving out any explanation of required fields, optional behaviors, or how recurrence is handled. This is inadequate for the complexity of the tool.

  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 already has descriptions for all 14 parameters (100% coverage), so the description does not need to repeat them. However, the tool description adds no additional meaning beyond the schema, and the schema descriptions themselves are terse. Given the high schema coverage, a baseline score of 3 is appropriate.

  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 uses the verb 'register' with a clear resource ('dooray events') and location ('on a calendar'), conveying that this tool creates calendar events. It is distinct enough from siblings like dooray_calendar_events, which likely list events, but it does not explicitly differentiate itself.

  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 such as dooray_calendar_events or dooray_calendar_calendars. There is no mention of prerequisites, context, or conditions that would help an agent choose this tool appropriately.

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

• dooray_post_log_updateC
  2.8/5.0
  Behavior1/5

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

  No annotations are provided, so the description carries the full burden. It only says 'update' with no disclosure of side effects, reversibility, permissions, or what happens to the existing log. For a mutation tool, this is a significant transparency gap.

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

  Conciseness3/5

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

  The description is a single concise sentence, which is appropriately brief for a simple tool. However, it is under-specified and omits important context, making it more under-specified than concise.

  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?

  With no annotations, no output schema, and a sparse description, the tool lacks essential context. It doesn't explain return values, side effects, or how to use it correctly. The nested body schema and multiple required parameters demand more explanation than is 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?

  Schema description coverage is 80%, and each parameter has a clear description (e.g., logId described as 'log id, or comment id'). The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

  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 the resource ('a comment or activity log of a Dooray post'). It is specific enough to distinguish from sibling tools like create or list, though it does not 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.

  Usage Guidelines3/5

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

  The verb 'update' implies this tool is for modifying existing logs, but there is no explicit mention of when to use it versus alternatives like dooray_post_log_create or dooray_post_logs. No usage context or exclusions are provided.

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

• dooray_calendar_eventsC
  2.9/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden. It only says 'find', which implies a read-only operation, but it does not disclose details like whether all calendars are included by default, how time boundaries are treated, or what the response structure looks like. This is minimal disclosure.

  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 a single, concise sentence that states the core purpose. It is front-loaded and not padded, though it is under-specified and lacks any additional useful structure or detail.

  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 has 4 parameters, 3 required, no output schema, and no annotations, the description is too sparse. It fails to explain that timeMin/timeMax are required, that the operation must be 'find_events', or how the optional calendars parameter filters results. This leaves the agent under-informed for correct invocation.

  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 descriptions for timeMin, timeMax, calendars, and operation. The tool description adds no parameter-specific meaning, but because the schema fully documents parameters, the baseline of 3 applies.

  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 uses the specific verb 'find' and resource 'dooray events of calendars', clearly indicating a read operation on calendar events. It distinguishes from siblings like dooray_calendar_calendars and dooray_calendar_post_event, though it could be more explicit about searching by time range and optional calendar filtering.

  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 such as dooray_calendar_calendars or dooray_calendar_post_event. It does not mention prerequisites, typical scenarios, or that it searches within a time range and optionally filters by calendars.

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

• dooray_postsC
  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 must communicate behavioral context. 'Find' implies a read operation, but nothing about pagination, filtering behavior, rate limits, or return format is disclosed. The tool has 20 parameters, yet the description offers no operational detail beyond the verb.

  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 a single, concise sentence with no wasted words. It is appropriately sized for a tool where the schema carries heavy detail, though it might be too terse for a complex tool with 20 parameters.

  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 complexity (20 parameters, no output schema, no annotations), the description is far from complete. It does not explain what dooray posts are, how to combine filters, or what the response structure looks like. The schema provides parameter-level detail but not high-level usage 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 input schema provides descriptions for all 20 parameters, covering 100% of parameter semantics. The description adds no extra meaning beyond the schema, so the baseline of 3 applies.

  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 finds dooray posts within projects, using a specific verb and resource. It does not explicitly differentiate from sibling tools like dooray_post_logs, but the 'posts in projects' phrasing distinguishes it reasonably from calendar and account tools.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives such as dooray_post_logs or dooray_post_files. There is no mention of when to prefer this over others, 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.

• dooray_projectB
  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 must carry the full burden of behavioral disclosure. It implies read-only operations through 'find' and 'get', but does not explicitly state side-effect-free behavior, permissions, pagination, or output format. The description is too sparse to provide meaningful 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 a single concise sentence, front-loaded with the core action. Every word is purposeful, and there is no fluff. It is appropriately concise for a tool of this simplicity.

  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?

  The tool is relatively simple, and the schema covers parameters well, but there is no output schema and no explicit mention of return values (list vs single object). The description also does not clarify the difference between 'find_projects' and 'find_project' beyond the schema's operation enum. It is adequate but has clear gaps in behavior and return expectations.

  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 baseline is 3. The description adds no extra parameter information beyond what the schema already provides (e.g., projectId for find_project, type/scope/state enums). It does not compensate for any gaps, but none exist, so the score remains at baseline.

  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 dual purpose: finding projects and retrieving a single project by ID. It uses specific verbs ('find', 'get') and names the resource (Dooray projects), distinguishing it from sibling tools focused on members, messengers, calendars, and posts. However, it is slightly vague about the search/list aspects, so it doesn't quite earn a 5.

  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?

  There is no guidance on when to use this tool versus alternatives, nor when to choose 'find_projects' vs 'find_project'. The schema provides some indication via the operation enum and projectId description, but the description itself offers no context, prerequisites, or exclusions.

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

• dooray_messengerB
  3.2/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 disclosing behavioral traits. It only states 'send message' implying a side effect, but does not mention authentication requirements, whether the operation is idempotent, what happens on failure, or any return behavior. This is insufficient 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.

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no fluff or redundancy. It is appropriately sized for such a simple tool, though it adds no extra explanatory detail that could make it more helpful.

  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?

  The tool is simple with three well-documented parameters and no output schema. The description covers the basic purpose, but lacks details about what the operation returns, how recipients are identified, and any usage context. Given the simplicity, this is adequate but leaves room for improvement.

  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 'to' (recipient organizationMemberId) and 'message' (message to send). The description adds no additional parameter context, but the schema alone adequately documents the parameters, warranting the baseline score.

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

  Purpose5/5

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

  The description 'send message to dooray messenger' uses a specific verb (send) and resource (dooray messenger), clearly stating the tool's function. It distinguishes itself from sibling tools which are focused on projects, calendars, and posts, not messaging.

  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, when not to use it, or any prerequisites. It simply states the action, leaving the agent to infer appropriate 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.

• dooray_post_log_createB
  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 must disclose behavioral traits. 'Add a comment' describes the side effect but does not reveal the need for the 'operation' parameter set to 'create_log', authentication expectations, error behavior, or response format. The description adds minimal transparency beyond the name itself.

  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, well-structured sentence with no filler. It front-loads the action and target, making it immediately scannable.

  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?

  With no output schema and no annotations, the description should compensate by explaining the full invocation context. It does not mention the required operation constant, how to obtain projectId/postId, or what the API returns on success/failure. The description alone is insufficient for an agent to confidently invoke this create 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 75%, and the schema already provides descriptions for projectId, postId, body.content, and body.mimeType. The description does not add parameter semantics, such as explaining that postId refers to the target post or how to construct the body object. Since the schema covers most parameters, a baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description 'add a comment to a Dooray post' uses a specific verb ('add') and identifies the resource ('comment' to a 'Dooray post'). It clearly distinguishes this create operation from sibling tools like dooray_post_log_update (update) and dooray_post_logs (list). The only minor ambiguity is the term 'comment' vs 'log' in the name, but the action is still unmistakable.

  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. The description only states the action without mentioning that listing or updating logs is handled by sibling tools, or any prerequisites like needing a existing post ID. Usage must be inferred entirely from the tool name and sibling list.

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

• dooray_post_logsB
  3.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. The verb 'find' implies a read-only operation, but the description does not explicitly state that it modifies nothing, nor does it mention pagination behavior or return format. It adds minimal context beyond the schema.

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

  Conciseness5/5

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

  The description is a single, focused sentence with no redundant words. It is appropriately front-loaded and concise.

  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?

  The description is too terse for a tool with six parameters and no output schema. It doesn't explain the 'operation' parameter, the meaning of 'comments and activity logs' in terms of return values, or how this relates to nearby log tools. The schema provides some structure, but the description should offer more 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?

  Schema description coverage is 100%, so the schema already documents all six parameters. The description adds no additional meaning about how parameters interact or what values are expected, so it stays at the baseline.

  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 uses the specific verb 'find' and clearly identifies the resource as 'comments and activity logs of a Dooray post.' It distinguishes from sibling tools that create or update logs, but it doesn't explicitly differentiate from the singular dooray_post_log tool, leaving some ambiguity about whether this returns a list or a single item.

  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 simply states what it does, without mentioning when it should be preferred over dooray_post_log or how it relates to other log-related tools.

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

• dooray_account_membersB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description must alone disclose behavioral traits. It only states the action without explaining return format, pagination, exact/partial matching behavior, or error handling. This is a minimal disclosure for a search operation.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no unnecessary words. Every part adds value, and it is appropriately concise.

  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?

  Given the tool's simplicity, the description is adequate but incomplete. It does not describe the return value, which is important since there is no output schema. The lack of annotations and output schema means the description should provide more context about call results.

  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 baseline is 3. The description adds slight context by linking 'member_name' and 'user_code' to 'by name or userCode', but it does not clarify that 'operation' must be 'find_member_id' or how optional parameters interact. The schema's own descriptions are largely tautological.

  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 uses a specific verb 'find' and clearly identifies the resource as 'dooray account members', with search criteria 'by name or userCode'. It is clear what the tool does, but it doesn't explicitly differentiate itself from the sibling tool 'dooray_account_member' (singular), which might have a related purpose.

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

  Usage Guidelines3/5

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

  The description implies usage for finding members by name or user code, but does not provide explicit guidance on when to use this tool versus alternatives like 'dooray_account_member'. No exclusions or alternative references are given.

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

• dooray_account_memberB
  3.4/5.0
  Behavior2/5

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

  There are no annotations, and the description does not disclose any behavioral details such as return format, error behavior, permissions, or whether the member details are partial or full. The description 'find dooray account members by id' is too sparse to inform the agent about side effects or edge cases.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the core purpose without unnecessary detail.

  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?

  With no output schema and no annotations, the description should explain what the tool returns (e.g., member details, full object, success/failure). It does not, leaving the agent without enough context to fully understand the tool's behavior. The simplicity of the tool does not compensate for this gap.

  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 both parameters are already documented in the schema. The description adds little beyond the schema, only reiterating 'by id' which maps to member_id. Baseline 3 is appropriate as the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the verb 'find' and the resource 'dooray account members' with the qualifier 'by id', which specifies a single-member lookup. This distinguishes it from the sibling tool dooray_account_members (plural), which likely lists all members.

  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 implies usage by specifying 'by id' but does not explicitly mention when to use this tool over alternatives or any exclusions. No sibling differentiation is stated, though the purpose itself provides some context.

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

• dooray_post_filesA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the behavioral transparency burden. It only states 'find attachments' and does not disclose return format, authentication needs, or that it lists metadata rather than downloading file contents. This is insufficient for a no-annotation 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, focused sentence with no unnecessary words. It is front-loaded and easily parsable; every word contributes meaning.

  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?

  The tool is simple, but the absence of annotations and output schema places greater responsibility on the description. It does not clarify whether the result is a list of metadata or something else, nor does it mention the relationship to the sibling download tool. Adequate for a minimal tool but with clear gaps.

  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 fully documents all parameters with 100% coverage, including the operation enum and required IDs. The description adds no parameter-specific meaning, but the schema already provides complete semantic detail, 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.

  Purpose5/5

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

  Clearly identifies the action ('find') and resource ('attachments of a Dooray post'), which distinguishes it from sibling tools like dooray_post_logs and dooray_post_file_download. The verb and object are specific and unambiguous.

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

  Usage Guidelines3/5

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

  The description implies the tool is used to list attachments of a specific post, but it does not explicitly explain when to use this over dooray_post_file_download or mention any exclusions. The usage context is clear enough but lacks alternative guidance.

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

• dooray_post_logA
  3.6/5.0
  Behavior3/5

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

  Without annotations, the description carries the burden of disclosing behavior. The verb 'find' unambiguously indicates a read-only operation, giving the agent confidence there are no side effects. However, it does not mention permissions, error conditions, or return format, which are left 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 a single sentence of only 9 words, fully front-loaded with the action and resource. Every word contributes meaning, making it highly concise and well-structured.

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

  Completeness4/5

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

  For a simple, well-parameterized get-by-id tool, the description is mostly complete. The schema covers all parameter meanings. The lack of an output schema is offset by the natural expectation that a 'find' returns the log. No critical context is missing given the low complexity.

  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%, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides (e.g., logId can be a comment id).

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

  Purpose5/5

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

  The description clearly states the action ('find') and the resource ('a specific comment or activity log of a Dooray post'). It explicitly scopes to a single log, distinguishing it from the sibling tool 'dooray_post_logs' which presumably lists logs.

  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 gives no explicit guidance on when to use this tool versus alternatives. It implies use for retrieving a specific log, but does not state when to prefer it over listing tools or create/update variants.

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

• dooray_post_file_downloadA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses two meaningful behaviors: authenticated redirects and writing to a local temporary directory. However, it does not mention side effects (e.g., whether the temp file persists), return value shape, error handling, or auth prerequisites beyond 'authenticated', leaving significant gaps.

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

  Conciseness5/5

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

  The description is a single sentence, front-loaded with the action ('download'), and every word contributes meaning. It is concise and free of redundancy.

  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?

  No output schema and no annotations, so the description is the sole source for context. It explains the core functionality and local destination, but fails to describe the return value (e.g., does it return a file path?), post-download behavior, or cleanup. For a 4-required-param download tool, this is a noticeable completeness gap.

  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 coverage is 100%, so the baseline is 3. The description adds context about 'post attachment' and 'raw content', which helps understand fileId's role, but it does not explain parameter relationships, validation, or usage details beyond the schema. It adds marginal value but does not compensate beyond baseline.

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

  Purpose5/5

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

  The description clearly states a specific verb ('download') and resource ('raw content of a Dooray post attachment'), and adds a distinctive mechanism ('through authenticated redirects to a local temporary directory'). This distinguishes it from sibling tools like dooray_post_files which likely list files rather than download content.

  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 implies usage for downloading a specific attachment's raw content, but provides no explicit when-to-use vs alternative tools (e.g., dooray_post_files) or exclusions. It is clear enough for basic selection, but lacks explicit guidance on alternatives or prerequisites.

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