Server Quality Checklist

Tool Scores

• get_client_trafficA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds that it returns upload/download traffic totals and limits, but it does not disclose pagination, error handling, or response format. It provides minimal additional behavioral context beyond what annotations already imply.

  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?

  One sentence of 14 words, front-loaded with the key resource (traffic totals and limits) and scope (single client, exact email). No fluff, every word earns its place.

  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?

  This is a simple one-parameter read tool with no output schema. The description explains the purpose and scope adequately for an agent to invoke it correctly. It doesn't describe the return structure, but given the simplicity and the annotations covering the safety profile, this gap is minor and acceptable.

  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%, and the schema's parameter description ('Exact client email/identifier') already conveys the meaning. The tool description reinforces 'exact email' but adds no new semantic details like format, validation rules, or examples. Baseline of 3 is correct when 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 action (get), the resource (client traffic), and the scope (a single client by exact email). It distinctly separates this from sibling tools like list_clients or get_client by focusing specifically on traffic totals and limits, making its purpose unambiguous.

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

  Usage Guidelines4/5

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

  The phrase 'for a single client by exact email' provides a clear condition: this tool is for retrieving traffic data for one specific client when the exact email is known. It implicitly suggests that without an email you'd need to find it first (via list_clients), but it does not explicitly name alternatives. This is adequate, though explicit sibling routing would earn a 5.

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

• list_clientsA
  4/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds the scope (all inbounds) and the fields returned, but does not disclose any additional behavioral traits such as response size, pagination, or performance implications. With annotations in place, this is adequate but not rich in extra context.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that immediately front-loads the core purpose—'List every client across all inbounds'—and then efficiently lists the returned fields. No unnecessary words or repetition; it earns its place with every word.

  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 zero-parameter read-only tool with annotations covering safety and no output schema, the description is almost complete. It specifies the scope (all inbounds) and the fields returned, which is sufficient for an agent to understand what it does. It lacks details on pagination or sorting, but such details are not critical for a simple list operation and are not expected given the minimal complexity.

  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 description need not explain any parameters. Schema description coverage is trivially 100% (no properties), and the baseline for 0 params is 4. The description correctly focuses on the output scope and fields, adding no irrelevant parameter noise.

  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 ('List') and the resource ('every client across all inbounds'), which is specific and unambiguous. It also enumerates the fields returned (email, protocol, enabled state, traffic limits) and distinguishes from siblings like list_online_clients and get_client by emphasizing 'every client across all inbounds.'

  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 stating it lists every client across all inbounds, which suggests it is the go-to for a complete unfiltered list. However, it does not explicitly mention when NOT to use it (e.g., for online-only clients use list_online_clients, or for a single client use get_client). No clear alternative is named, so guidance is only implied, not explicit.

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

• list_online_clientsA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds that it returns emails and filters by online status, which is useful but not extensive. No mention of edge cases like empty lists, ordering, or pagination, but given annotations the description carries a reasonable load.

  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, clear sentence that front-loads the action ('List') and immediately specifies the scope ('emails of clients that are currently connected/online'). No wasted words or redundant phrasing.

  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, parameter-less read-only list tool, the description adequately specifies the return type (emails) and the filter (online status). While it lacks details like ordering or pagination, the simplicity of the tool reduces the need for more, and the annotations already cover safety. The presence of sibling 'list_clients' is implicitly understood.

  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, and the description correctly avoids mentioning any. Per the rubric, a parameter count of 0 sets a baseline of 4, and the description adds nothing more because there is nothing to add.

  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 'List' and the resource 'clients' with the qualifier 'currently connected/online.' This unambiguously distinguishes it from the sibling tool 'list_clients' (which presumably lists all clients) without needing to name the sibling explicitly.

  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 implication that this tool is for online clients is clear, but there is no explicit guidance on when to choose this over 'list_clients' or any alternatives. It relies on the user/agent to infer usage context from the description alone.

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

• update_inboundA
  4/5.0
  Behavior4/5

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

  The description discloses the replace-instead-of-patch behavior ('This replaces the inbound configuration'), which adds nuance beyond what annotations convey. Annotations already declare destructiveHint=true and idempotentHint=true, and the description's merge requirement is a behavioral consequence worth surfacing. No contradiction with annotations.

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

  Conciseness5/5

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

  Two sentences, zero waste. The core purpose is front-loaded in the first sentence, and the critical usage caution (fetch first, merge, no partials) lands immediately after. Every word earns its place.

  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 10-parameter mutation tool with no output schema, the description addresses the single biggest risk (destructive replace) and prescribes the mitigation (fetch-first-merge). It doesn't cover return values or auth requirements, but those are covered by annotations' safety profile and the absence of an output schema. The most decision-relevant context is present.

  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 70%, so most parameters (id, port, remark, protocol, settings, sniffing, streamSettings) are already documented. The description adds no parameter-specific detail, but the 'merge into full object' note implicitly warns against sending partial parameter sets. The 3 undocumented fields (enable, listen, expiryTime) are reasonably self-explanatory by name, so the gap is acceptable.

  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?

  States a specific verb (update) + resource (existing inbound by ID), clearly distinguishing it from create_inbound and get_inbound within the sibling set. The purpose is unambiguous, though it relies on the verb+resource pairing rather than an explicit sibling contrast.

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

  Usage Guidelines4/5

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

  Gives explicit, actionable guidance: fetch with get_inbound first, then merge changes into the full object rather than sending partial ones. This is strong when-to-use guidance addressing the most common misuse. It doesn't explicitly say when not to use it versus create_inbound, but the merge instruction is highly specific and valuable.

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

• create_clientA
  4.2/5.0
  Behavior5/5

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

  The description discloses a critical behavioral trait not covered by annotations: generated credentials are returned once and 'are not retrievable again in plaintext.' It also instructs the agent to surface the output to the user, which is actionable guidance. This adds significant value beyond the annotations, which only mark readOnlyHint as false (confirming mutation) but provide no detail about credential handling.

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

  Conciseness5/5

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

  Two sentences with no redundancy. The first sentence states the core action and credential generation, the second highlights the critical output handling. All information is front-loaded and each sentence earns its place, making it efficient and easy for an agent to parse.

  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?

  Given there is no output schema, the description must explain the return value. It states that credentials and connection info are returned and must be surfaced, which covers the essential requirement. However, it does not detail the exact structure of the returned credentials (e.g., fields like uuid, password, port), which could be important for the agent to correctly communicate to the user. Still, for a tool with 6 parameters and a protocol enum, the description is largely complete.

  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 each parameter already has a clear description (e.g., inboundId says 'see list_inbounds', totalGB says 'Converted to bytes automatically'). The tool description does not add extra parameter-level detail, so it stays at the baseline for fully covered schemas. It would need to compensate for ambiguous parameters to score higher, which is not the case here.

  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 ('Create a new client') and specifies the resource ('on an existing inbound') along with the key distinctive behavior: auto-generated credentials (UUID/password/keys based on protocol). It differentiates from sibling tools like update_client or delete_client, making the tool's role 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 prerequisite of an existing inbound ('on an existing inbound') and the schema references list_inbounds for the inboundId, but it does not explicitly contrast with alternatives or state when not to use this tool. There is no mention of when to prefer this over update_client or list_clients, leaving the agent to infer the conditions.

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

• create_inboundA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=false and idempotentHint=false, so the write nature is clear. The description adds valuable context by warning that the expected shape for settings/streamSettings/sniffing may vary by panel version, which suggests the tool validates against a version-specific schema. This goes beyond the annotations and helps the agent anticipate potential errors. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is two sentences: the first states the purpose, the second gives a concrete, actionable recommendation. It is front-loaded and contains zero filler, making it easy to read and process.

  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?

  The tool has 9 parameters, none required, and no output schema. The description does not describe return values or side effects, but the explicit recommendation to call get_inbound first effectively compensates for the missing schema details. Combined with the schema's parameter descriptions, this is sufficient for most agents to use the tool correctly, though it could mention what the response contains or any implicit effects.

  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 67%, and the schema already provides descriptions for port, remark, protocol, settings, sniffing, and streamSettings, including examples. The description itself does not elaborate on individual parameters beyond recommending to inspect an existing inbound, which indirectly helps with parameter values but does not add direct semantics. Since the coverage is moderate and the description only generically references the shape, this is an adequate but not exceptional contribution.

  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 ('Create a new inbound') and the resource ('on the panel'), distinguishing it from sibling tools like update_inbound or delete_inbound by the verb. It also adds context about the panel version, making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description provides a clear usage recommendation: 'call get_inbound on a similar existing inbound first to see the exact shape expected.' This gives practical guidance for preparing the correct payload, which is especially useful given the version-specific schema concerns. It does not explicitly mention when not to use this tool or name alternatives, but the recommendation implies a best practice that improves usability.

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

• delete_inboundA
  4.2/5.0
  Behavior4/5

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

  The description adds value beyond the annotations: it explicitly states the irreversible nature ('cannot be undone') and the cascade effect ('and all of its clients'). Annotations already indicate destructiveHint=true, but the description provides specific behavioral context about the side effect on clients. It does not contradict the annotations, and the additional detail about the cascade is important for an agent to understand the full impact before calling.

  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 two short sentences with zero filler. The primary action and scope are front-loaded ('Permanently delete an inbound'), followed by the essential warning about irreversibility. Every word serves a purpose, and it is easy to scan quickly.

  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?

  Given the tool's simplicity (one integer parameter, no output schema, destructive action), the description is nearly complete. It covers the action, the side effect (clients deletion), and irreversibility. It doesn't mention error handling (e.g., behavior if ID doesn't exist), but that information is often not necessary for a deletion tool, and the annotations (idempotentHint) hint at behavior for repeats. Overall, the essential context is present.

  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 covers the parameter fully: 'Numeric inbound ID to delete' and the required field 'id'. The description only repeats 'by ID' without adding new meaning—no format, validation rules, or additional constraints are introduced. Since schema coverage is 100%, the baseline of 3 is appropriate; the description does not enhance parameter understanding beyond what the schema 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 exactly what it does: 'Permanently delete an inbound and all of its clients by ID.' The verb 'delete' is specific, the resource 'inbound' is clear, and the scope ('all of its clients') distinguishes it from sibling delete_client. This is unambiguous and helps an agent select it without confusion.

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

  Usage Guidelines4/5

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

  The description implies when to use the tool: whenever an inbound needs to be permanently removed, given its straightforward action. It doesn't explicitly name alternatives or exclusions (e.g., 'use update_inbound to modify instead'), but because it's the only delete-inbound tool and the action is clear, an agent can infer the correct usage context. A more explicit 'when not to use' would be beneficial, but it's not misleading.

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

• update_clientA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate this is a non-read-only, destructive, idempotent operation. The description adds valuable context beyond annotations by clarifying the partial-update behavior (only passed fields change, others preserved). This is important for agents to understand they don't need to pass all fields and that calling it multiple times with the same params is safe. No contradictions with annotations.

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

  Conciseness5/5

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

  The description is extremely concise—two short sentences—with the main action front-loaded. The first sentence states the purpose, and the second explains the partial-update behavior that is critical for correct usage. No unnecessary words or repetitions. It earns a 5 for efficiency and clarity.

  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?

  Given the tool has 7 parameters, some of which are alternatives (expiryDays vs expiryTime), and no output schema, the description provides sufficient context: it states the general scope of updates and the preservation of unspecified fields. The schema's parameter descriptions cover the specifics. The description doesn't mention edge cases like conflicting fields, but it's not essential because the schema documents them. Overall it's complete enough for an agent to call 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%, so each parameter is already documented with descriptions. The tool description adds minimal parameter-specific insight beyond grouping them into high-level categories (traffic limit, expiry, enabled state). It does clarify that only passed fields change, which is a general property rather than parameter-specific detail. Thus it does not exceed the baseline of 3.

  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 identifies the action ('Update') and the resource ('existing client'), and specifies the updateable aspects: traffic limit, expiry, and enabled state. It distinguishes itself from create/delete/get tools by explicitly stating 'existing client' and 'preserved', which prevents confusion with sibling tools like create_client or delete_client.

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

  Usage Guidelines4/5

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

  The description implies this tool is for modifying an existing client, as opposed to creating or deleting. It states that only passed fields change and everything else is preserved, which gives a clear usage context. However, it does not explicitly name alternative tools or provide explicit when-not-to-use conditions, so it falls short of a 5.

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

• delete_clientA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds 'Permanently' and 'cannot be undone,' emphasizing irreversibility beyond the generic destructiveness hint. It also specifies exact matching behavior. No contradiction with annotations; it complements them.

  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?

  Two short sentences with zero redundancy. The key action and irreversibility are front-loaded, and every word earns its place. Perfectly concise for a single-parameter delete operation.

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

  Completeness5/5

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

  For a simple delete tool with one parameter, no output schema, and annotations covering destructive/idempotent behavior, the description is complete. It states the exact input requirement and the permanence, which are the only operational details an agent needs. Nothing critical is missing.

  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 descriptions cover 100% of parameters, documenting 'email' as 'Exact client email/identifier to delete.' The description repeats the 'exact' requirement but adds no new semantic detail beyond the schema. Baseline 3 is appropriate given the high schema coverage.

  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 ('delete'), a resource ('client'), and the exact matching criterion ('by exact email'). It clearly distinguishes from delete_inbound and other siblings by focusing on the client resource. The permanence note adds clarity without ambiguity.

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

  Usage Guidelines4/5

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

  The description makes the intended use obvious: deleting a client permanently. It does not explicitly mention alternatives or when not to use it, but the purpose is self-evident and no exclusions are needed for a destructive action. The exact email requirement provides practical guidance.

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

• list_inboundsA
  4.4/5.0
  Behavior4/5

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

  Annotations (readOnlyHint, openWorldHint, idempotentHint) already cover the safety profile, so the description adds value by disclosing the return contents (clients, protocol, port, traffic stats). This goes beyond annotation coverage and clarifies what the agent can expect from the result, without contradicting annotations.

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

  Conciseness5/5

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

  A single, well-structured sentence that front-loads the primary action ('List every inbound') then appends the specific return contents. No waste, no filler, every word contributes value.

  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 zero-parameter list tool with strong annotations, the description provides sufficient context: it names the resource and the returned details. It doesn't mention pagination or ordering, but for a simple enumeration that is not a significant gap, given no output schema and no complexity.

  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 and description are trivially complete. No parameter documentation is needed; the baseline of 4 for no-param tools applies.

  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 ('List'), the resource ('every inbound configured on the 3x-ui panel'), and the included content (clients, protocol, port, traffic stats). It clearly distinguishes from siblings like get_inbound (single resource) and list_clients (clients only) by its scope and content.

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

  Usage Guidelines4/5

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

  Clear context is provided: use this to list all inbounds with their associated data. However, it does not explicitly state when not to use it or name alternative tools, so it falls short of explicitly routing the agent. The scope is unambiguous enough for most cases.

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

• get_clientA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and side-effect profile. The description adds behavioral value by specifying the exact return content ('settings, inbound, traffic limits'), which helps the agent gauge whether this tool meets its information needs. It does not contradict annotations and provides useful 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 two sentences, front-loaded with the primary action and returns, then the usage guidance. No redundant phrases or filler. Every word contributes to understanding what the tool does and when to use it.

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

  Completeness5/5

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

  For a single-parameter read-only getter with annotations covering safety, the description provides all necessary context: what it returns, the input requirement, and the fallback alternative. It does not mention error handling or pagination, but these are not expected for this simple tool. The description is fully adequate for an agent to call 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?

  The schema already describes the email parameter as 'Exact client email/identifier,' and the description reiterates the 'exact email' requirement without adding new constraints (e.g., case sensitivity, format). With 100% schema coverage, the description adds little beyond reinforcing the parameter's meaning, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb ('Get') and resource ('full details for a single client'), enumerates the exact fields returned (settings, inbound, traffic limits), and emphasizes the 'exact email' criterion. This clearly distinguishes it from the sibling list_clients (returns a list) and get_client_traffic (traffic only), making the tool's purpose unambiguous.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use guidance: 'Use list_clients first if you do not know the exact email.' This tells the agent the condition under which it should select an alternative, thereby clarifying the precise context for this tool. No other exclusions are needed given the simple, single-purpose nature of the tool.

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

• get_inboundA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and idempotentHint, so the description's job is to add context. It specifies exactly what data is returned (protocol settings, stream settings, clients, traffic), which helps the agent set expectations. No contradictions with annotations.

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

  Conciseness5/5

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

  Two sentences with no redundancy. The core purpose is stated first, followed by a necessary usage hint. Every word adds value, and the structure front-loads the essential information.

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

  Completeness5/5

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

  For a simple read-only getter with one parameter and no output schema, the description covers what the tool does, what it returns (the enumerated contents), and how to obtain the required ID. Nothing critical is missing for an agent 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?

  The schema already fully documents the 'id' parameter as 'Numeric inbound ID' with 100% coverage. The description only repeats 'numeric ID', adding no additional meaning beyond what the schema already provides. Baseline 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 clearly states the verb 'Get' and the resource 'a single inbound', and specifies what the full details include (protocol settings, stream settings, clients, traffic). It distinguishes itself from 'list_inbounds' and other sibling tools.

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

  Usage Guidelines5/5

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

  Explicitly instructs the agent to 'Use list_inbounds first to find the ID', providing a clear workflow and condition for using this tool. This also implicitly signals when not to use it—when no ID is known—and points to the relevant sibling for the lookup step.

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