Server Quality Checklist

Tool Scores

• send_viber_messageC
  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. It only states that it sends a message, without revealing any side effects, authentication requirements, delivery guarantees, or error behavior. The agent has no information about what happens on failure, whether the operation is asynchronous, or if any fees apply. This is a severe gap.

  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 a single short sentence, which is not verbose, but it is under-specified. It lacks structure and front-loaded details. Rather than being efficiently concise, it omits essential context, making it merely brief rather than well-crafted.

  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 tool that sends a message, the description is incomplete. It does not explain what happens on success (return value), how errors are conveyed, or any constraints on the recipient number or text length. The schema covers parameters, but the description fails to address the tool's overall behavior beyond the action itself.

  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 provides descriptions for both parameters ('to' and 'text') with 100% coverage, so the baseline is 3. The description itself adds no parameter-specific meaning beyond what the schema already states. It does not offer format hints, examples, or clarifications, but the schema is sufficient.

  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 'Отправить сообщение через Viber.' is a direct translation of the tool name 'send_viber_message'. It restates the name without adding any specificity about the message content, delivery, or scope. While it does distinguish the channel (Viber), it's essentially a tautology, providing no additional clarity beyond what the name already conveys.

  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 guidance on when to use this tool versus alternatives like send_sms or make_call. There is no mention of prerequisites, scenarios, or exclusions. An agent would have to infer that this is only for Viber messages, but no explicit usage context is provided.

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

• get_call_recordingC
  2.1/5.0
  Behavior1/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It only says 'get', which implies read-only, but does not state whether the call recording is returned as a URL, binary, or something else, nor does it mention authentication requirements or any side effects. The description is completely silent on behavior beyond the bare verb.

  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 short sentence, which is concise and front-loaded. However, it is under-specified to the point of being minimal, so while there is no wasted text, the brevity sacrifices useful detail. It is not overly verbose, but it also lacks structured elements like examples or clarifications.

  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 tool with one parameter and no output schema, the description should clarify what the agent can expect as a result (e.g., a file, a link, or binary data). It does not, so an agent cannot anticipate the return format or how to handle the response. The simplicity of the tool lowers the bar, but the lack of any output information is a significant 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% for the single parameter call_id, which is described as 'ID звонка для получения записи'. The description adds no additional meaning beyond the schema. Per the rubric, a baseline of 3 is appropriate when schema covers parameters fully, and the description does not contribute extra semantic value.

  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 a clear verb and resource ('get call recording by ID') and the parameter call_id is implied. However, it essentially restates the tool name without adding distinguishing detail, such as what the recording represents or how it is returned. It does not differentiate from siblings like get_call_status, though the difference is obvious from the name.

  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?

  No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or exclusions. An agent has no signal for when to choose get_call_recording over get_call_status or other siblings.

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

• send_smsC
  2.7/5.0
  Behavior1/5

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

  With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action without any side effects, failure modes, required permissions, rate limits, or response behavior. An agent cannot anticipate how the SMS send behaves if it fails or what constitutes success.

  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 extremely concise, a single sentence with no filler. It front-loads the primary action and channel. However, the brevity borders on under-specification, which slightly reduces the score from a perfect 5.

  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 simple send operation with no output schema or annotations, the description is too sparse. Missing details include what the response will be, how to interpret success/failure, any rate limits, and the exact role of 'destination' (sender number vs. name). This leaves significant gaps for an agent attempting to invoke it correctly.

  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%, and the parameter descriptions are present but terse. The tool description adds no additional meaning beyond the schema, such as clarifying the distinction between 'number' and 'destination' or the expected format for sender names. Since the schema already documents each parameter, a baseline 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 clearly states the action ('send SMS') and the resource ('via MTS Exolve'), distinguishing it from siblings like send_viber_message by specifying the channel. However, it does not elaborate on the specific service context or the exact meaning of 'destination', leaving some ambiguity.

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

  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 such as get_sms_status or send_viber_message. There is no mention of prerequisites like number availability, authentication, or fallback conditions, leaving the agent to 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.

• get_call_statusC
  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 carries the full burden of disclosing behavioral traits. It only states 'check call status' with no information about side effects, authentication needs, rate limits, or what the response looks like. While not misleading, it offers almost 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.

  Conciseness3/5

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

  The description is a single short sentence, which is concise, but it essentially restates the tool name without adding new information. It is appropriately brief, yet the content does not earn its place as it adds no value beyond the title.

  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 simple one-parameter tool with no output schema, the description should at least indicate what status information is returned or any error conditions. The bare description leaves the agent without expectations for the response payload, making it incomplete for a tool of even moderate 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 already describes call_id as 'ID звонка' with 100% coverage, so the baseline is 3. The description adds no additional semantic meaning about the parameter beyond what the schema provides, which is acceptable given the high schema coverage.

  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 states a specific verb ('Проверить' / check) and resource ('статус звонка' / call status), clearly indicating the tool retrieves call status. It does not explicitly differentiate from siblings like get_sms_status, but the resource is distinct enough that an agent can infer the purpose.

  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 get_call_recording or get_sms_status. There is no mention of prerequisites, context, or scenarios where this tool is preferred, leaving the agent to infer usage purely from the name.

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

• list_numbersB
  3/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 says 'list of numbers' and does not state whether the operation is read-only, whether authentication is required, what the response format looks like, or whether pagination exists. For a tool with zero annotations and no output schema, this is insufficient. The description does not contradict any annotation, but it adds minimal insight beyond the action itself.

  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 phrase, which is appropriately sized for a no-parameter tool. It is front-loaded with the core purpose. However, it could benefit from a brief mention of the output or usage context, but for its simplicity, it is well-structured and free of fluff.

  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 an output schema and annotations, the description should at least indicate what the tool returns (e.g., an array of phone number strings) and whether it has any side effects. The current description only states the subject matter. For an agent to correctly invoke and interpret the tool, more detail is needed, such as whether the list includes all numbers or only active ones. The minimal description makes the tool usable but not fully contextual.

  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 tool has zero parameters, so the schema fully covers parameter semantics (vacuously). The baseline for 0 parameters is 4, and the description does not need to explain parameters. No additional semantic information is required because there is nothing to configure.

  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 'Список номеров телефонов на аккаунте' (List of phone numbers on the account) clearly indicates a read-only listing operation targeting phone numbers. It uses a specific resource (phone numbers) and implies a list action. It is distinct from sibling tools like buy_number and send_sms, which have different purposes. It lacks an explicit verb like 'returns', but the intent is unambiguous.

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

  Usage 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. The description does not mention prerequisites, such as requiring an existing account, nor does it contrast with siblings like buy_number or get_call_recording. No exclusions or conditions are provided, leaving the agent to infer that this is the default way to fetch numbers. This is a notable gap given the presence of sibling tools.

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

• make_callB
  3.3/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 only states that it 'initiates a phone call' but does not disclose what happens after initiation (e.g., whether the call is synchronous, whether it returns a call ID for later status checks, whether it triggers charges, or any side effects). Since siblings include get_call_status and get_call_recording, an agent would likely need to know that make_call returns a call identifier, but this is not mentioned. The description offers no behavior beyond the primary action, 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.

  Conciseness4/5

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

  The description is a single, concise sentence that immediately states the action and platform. It is front-loaded and contains no redundancy or fluff. It earns a 4 because it is efficient and to the point, though it lacks any structural enhancements like bullet points or clarifications, which might be helpful but are not required for this simplicity.

  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?

  This tool has no output schema, no annotations, and only two simple string parameters, so the description must explain the return behavior. It does not state what the tool returns (e.g., a call ID) or any side effects (e.g., charging, scheduling). Given that siblings like get_call_status and get_call_recording likely rely on a call ID from this tool, the absence of such information makes the description incomplete for an agent that needs to chain calls. The description is too sparse to fully support correct usage.

  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%: both 'from' and 'to' have descriptive names ('Номер вызываемого абонента' and 'Номер звонящего') that fully explain their meaning. The description adds no extra commentary about the parameters, so it relies on the schema. Since the baseline for high coverage is 3, this is appropriate; the description does not need to repeat what the schema already provides.

  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 states a specific verb ('initiate'), a clear resource ('a phone call'), and the platform ('MTS Exolve'). This unambiguously distinguishes it from siblings like send_sms or send_viber_message, which target different communication channels. The agent can tell exactly what this tool does without opening its schema.

  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 usage context is implied by the name and the sibling set: it is the only tool that makes calls, so an agent would infer to use it for placing a voice call. However, there is no explicit guidance on when to prefer it over alternatives (e.g., for SMS or Viber), no mention of prerequisites like account permissions, and no exclusions. The lack of any explicit 'use when...' statement keeps this at an implied level rather than a clear directive.

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

• buy_numberB
  3.4/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 behavioral burden. It only says 'buy' but does not disclose side effects (cost, billing, irreversibility), post-purchase actions (how the number is delivered), or any limitations (e.g., region availability, phone type restrictions). This is a significant gap for a transactional 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?

  A single, grammatically complete sentence that front-loads the core action and the key parameter (region). There is no wordiness or redundancy; it is as concise as possible while still being informative.

  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 purchase operation with no output schema and no annotations, the description is insufficient. It does not explain what happens after purchase (e.g., does it return a number ID?), whether there are costs or confirmation steps, or how region/type constraints are validated. An agent would lack critical information to correctly invoke and interpret the result.

  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% — both parameters have descriptions ('Тип номера' and 'Регион'). The tool description adds no additional parameter-specific context, so it meets the baseline but does not enhance understanding beyond the schema.

  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 states a clear verb ('buy'), a specific resource ('new phone number'), and the target region, making it unambiguous. It is distinct from all sibling tools (send_sms, get_sms_status, etc.) which deal with communication, not number acquisition.

  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 when to use it (when buying a number), but it does not explicitly contrast it with alternatives or mention any prerequisites (e.g., account balance, availability checks). No mention of when NOT to use it, so it leaves some inference to the agent.

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

• get_sms_statusB
  3.4/5.0
  Behavior2/5

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

  With no annotations provided, the description must carry full behavioral transparency. It only states 'check status', implying a read operation, but does not disclose authentication needs, side effects, error conditions, or response format. This is a significant gap for a tool that could have side effects or require permissions.

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

  Conciseness5/5

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

  A single sentence that is concise, front-loaded, and contains no wasted words. The purpose is stated immediately without filler.

  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 only one parameter and no output schema, but the description fails to describe what the status check returns (e.g., delivery status, error codes, possible status values). This is a critical omission for an agent to interpret the response correctly, making the definition incomplete.

  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 the only parameter 'message_id' documented in the schema. The description adds no additional meaning for the parameter, so it does not go beyond the schema. Per rubric, baseline is 3 when schema covers parameters.

  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 tool checks the status of a sent SMS, using a specific verb ('check') and resource ('status of sent SMS'). This distinguishes it from siblings like send_sms (sending) and get_call_status (call status).

  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 after sending an SMS, but provides no explicit when-to-use guidance or exclusions relative to sibling tools like get_call_status. It relies on implicit context rather than stating conditions for use.

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