Skip to main content
Glama
Sign In
android-apk-orchestrator

android-apk-orchestrator

by HaizhuAI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

apk_report

Retrieve the synthesized APK analysis report path and agent index from a given case directory, providing direct access to consolidated results.

Instructions

Return the synthesized report path and agent index if present.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "case_dir": "<case_dir>"
    },
    "name": "apk_report"
  }
}

Input Schema

NameRequiredDescriptionDefault
case_dirYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.6/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 indicates a read-like 'Return' behavior, but it does not explain whether any report is generated on the fly, whether case_dir must exist, or what 'if present' means operationally.

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 sentence with no filler or repetition, and it front-loads the main action. It is concise and structurally easy to parse, though it could be more informative without sacrificing brevity.

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 required parameter and an output schema, so the description does not need to explain return structure. However, it omits when this tool should be invoked relative to siblings, what case_dir must contain, and whether the report is already synthesized or synthesized by this call.

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

Parameters1/5

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

Schema description coverage is 0% and the description never mentions case_dir. The agent must infer the parameter's meaning entirely from its name, with no help from the tool description. This is a significant gap for a required parameter.

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 action ('Return') and a clear resource (the synthesized report path), with an additional optional element (agent index). It is reasonably clear, but it does not explicitly differentiate from sibling tools like apk_status or apk_list_agents.

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. It does not mention prerequisites, such as a completed case or prior orchestration, nor does it reference any sibling tool or condition for selection.

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

Deploy Server

Other Tools