Server Quality Checklist

Tool Scores

• call_functionB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that the tool loads or reuses a module, invokes a single export, and returns either a result or an error with action-scoped evidence. However, it does not mention potential side effects of executing code, permissions required, or failure conditions beyond returning an error.

  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 with no filler, front-loads the main action, and packs the key semantics—connection scope, module loading, single export call, and result/error return—into a compact definition.

  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 description covers the core action and return behavior, and an output schema is presenthips. However, for a tool that executes exported functions, it lacks important context like safety warnings, side-effect expectations, or prerequisites for the probe module, and it does not guide selection among siblings.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema documents all five parameters. The description adds the notion of loading/reusing a probe ES Module and calling one export, which clarifies filePath and functionName, but it does not provide substantial additional meaning beyond the parameter descriptions.

  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 specific verbs ('load or reuse', 'call', 'return') and identifies the target resource: a probe ES Module on a connection instance identified by deviceId and appId. It clearly conveys what the tool does, though it does not explicitly contrast itself with sibling tools like eval_script.

  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 explains the action but gives no guidance on when this tool should be preferred over alternatives such as eval_script, connect, or disconnect. There are no use-case conditions, prerequisites, or exclusions, leaving the agent to infer selection criteria.

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

• eval_scriptA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description carries the full behavioral burden. It discloses that the tool returns a result or error with action-scoped evidence, but it does not warn that evaluating arbitrary code can have side effects on the device, nor does it state any prerequisites like needing an active connection or running app.

  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 concise sentences with no filler. The primary behavior is front-loaded, and the critical source-format constraint is stated immediately after, making the description easy to parse.

  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 description covers the core invocation details and the output schema exists, but it omits important selection context: when to use this tool instead of call_function, whether a prior connect is required, and potential side effects of executing arbitrary code. This leaves an agent with meaningful gaps for correct tool selection.

  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 minimal semantic value beyond the schema: it frames deviceId and appId as connection identifiers and repeats the source form that the schema already documents with an example.

  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 action: evaluating one inline async IIFE on a connection identified by deviceId and appId, and returning its result or error. The constraint on source form further differentiates it from siblings like call_function, which presumably call named functions.

  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 phrase 'On the connection instance' implies that a connection must exist and that the device/app must be identified, but it does not explicitly say when to prefer eval_script over call_function or when not to use it. Usage context is implied rather than stated.

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

• disconnectA
  4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full burden. It explicitly discloses destructive behavior by stating it will destroy the runtime and clear modules, which is critical for an agent to know before calling. It does not cover side effects like irreversibility or permission requirements, but the core destructive action is clearly stated.

  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 fronts the action (disconnect) and then packs in the two key behavioral details (destroy runtime, clear modules). No filler or redundancy; 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 two-parameter tool with an output schema, the description covers the essential behavior and resource identification. It lacks fallback or precondition guidance (e.g., calling on a non-existent instance), but given the tool's simplicity and the availability of structured schema, the description is largely sufficient. The absence of annotations means a bit more could be said about error handling, but the core is covered.

  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?

  Both parameters have complete schema descriptions (deviceId and appId with format details), so schema coverage is 100%. The description refers to them but adds no extra meaning beyond what the schema already provides. Per the rubric, 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 states a specific verb (disconnect) and a precise resource (MobileEasyUse instance) and names the effects (destroy runtime, clear modules). This goes beyond a vague 'disconnect' and clearly distinguishes it from siblings like connect and call_function.

  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: you disconnect an instance you previously connected. However, there is no explicit statement of when to use this tool over alternatives, no mention of prerequisites (e.g., must be connected first), and no exclusions. The sibling connect is an obvious counterpart but is not referenced.

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

• connectA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral disclosure burden. It reveals that the operation may create or reuse a connection, initializes an Android or iOS SDK runtime, and reports runtime and Release compatibility. It also explicitly frames compatibilityWarning and upgradeRecommendation as non-blocking advisories. It does not describe what happens if a connection already exists for the same deviceId/appId, but it is substantially more transparent than a minimal 'Connects to a device'.

  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 tight sentences that front-load the core create-or-reuse behavior and then add the compatibility-reporting detail. Every clause earns its place, and there is no filler or tautology.

  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?

  The schema documents all required parameters, an output schema exists to cover return fields, and the description supplies the lifecycle and compatibility context an agent needs. For a connection-establishment tool with this complexity, nothing essential is missing 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?

  All 6 parameters are fully described in the schema, so the baseline is 3. The description adds some contextual meaning by identifying deviceId and appId as the connection identity and platform as the runtime selector, but it does not meaningfully elaborate on ip, port, or runtimePort beyond 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 names a specific action ('Create or reuse the connection identified by deviceId and appId'), a concrete resource (the connection and SDK runtime), and the platform scope (Android/iOS). It clearly reads as the setup counterpart to disconnect and is unlikely to be confused with call_function, eval_script, or get_sdk_declarations.

  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 that this tool establishes or reuses a connection and initializes a runtime, which suggests it should be used before call_function or eval_script and paired with disconnect. However, it never explicitly states when to use it versus alternatives or mentions exclusions, so the usage guidance is left to inference.

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

• get_sdk_declarationsA
  4.2/5.0
  Behavior4/5

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

  With readOnlyHint=true and openWorldHint=false already supplied, the bar is lowered, and the description adds genuine context beyond them: the operation is filesystem-local rather than device-mediated, and it requires a shared filesystem precondition. It does not describe failure behavior when files are absent, but for a read-only locator with an output schema this is acceptable. No contradiction with the annotations.

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

  Conciseness5/5

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

  The description is two sentences of minimal, information-dense text with no fluff or restating of the schema. The core purpose leads, and the environmental prerequisite is delivered in the second sentence. Every clause 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 one-parameter tool that ships both annotations and an output schema, the description supplies the essentials: what is being located, for what purpose (to-script), and the environment constraint. It does not mention what happens when declarations are not found or how results are expressed, but the output schema presumably carries the return shape, so the remaining gap is small.

  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 0%, so the description must compensate, but it only hints at the platform's role via the noun phrase 'platform bridge'. It never explicitly says the platform enum (android/ios) selects which platform's SDK and declaration files to locate. The enum values are fairly self-evident and the parameter is single and required, so the deficit is minor, giving partial compensation rather than none.

  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 and resource: 'Locate local SDK, platform bridge, and Frida Gum declaration files for to-script.' It clearly differentiates from the siblings (connect, call_function, disconnect, eval_script), which act over a device connection or execute scripts, while this tool only locates declaration files locally. The intended output artifact is concrete and the scope 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 Guidelines4/5

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

  The sentence 'Requires a shared filesystem, not a device connection' gives an explicit applicability condition and an exclusion: use this when the declarations live on a shared filesystem, do not use it as part of a device-connection flow, which implicitly steers the agent away from the connect/disconnect siblings. It does not name an alternative tool explicitly or state a 'when not to use' beyond the connection caveat, so it stops just short of full guidance.

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