Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

apk_teardown_compare_ownership

Compare two different completed APK teardown jobs to detect common ownership signals such as shared signing certificates and SDK or analytics identifiers.

Instructions

Compare two apk-teardown jobs for evidence of common ownership. Compares two DIFFERENT completed jobs (not versions of the same app) for signals of common ownership -- shared signing certificate, SDK/analytics identifiers, and more.

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": {
      "job_id_a": "<job_id_a>",
      "job_id_b": "<job_id_b>"
    },
    "name": "apk_teardown_compare_ownership"
  }
}

Input Schema

NameRequiredDescriptionDefault
job_id_aYesFirst completed job ID; copy data.job_id returned by POST /apk-teardown/jobs
job_id_bYesSecond completed job ID; copy data.job_id returned by another POST /apk-teardown/jobs

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.17.16
    • changedInput schema / properties / job_id_a / description
      Previous value: -"First job ID"New value: +"First completed job ID; copy data.job_id returned by POST /apk-teardown/jobs"
    • changedInput schema / properties / job_id_b / description
      Previous value: -"Second job ID"New value: +"Second completed job ID; copy data.job_id returned by another POST /apk-teardown/jobs"
  2. Addedv1.16.2

TDQS

A4.1/5.0
Behavior3/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 burden. It discloses the signals compared (shared signing certificate, SDK/analytics identifiers) and the prerequisite that both jobs be completed, but gives no sense of the result shape, confidence framing, or whether the operation is purely read-only.

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?

Two short sentences, front-loaded with the action and goal. The second sentence partially restates the first ('Compare two apk-teardown jobs' / 'Compares two DIFFERENT completed jobs'), a small redundancy, but the exclusion 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?

With only two fully documented parameters, no annotations, and no output schema, the description covers purpose, input prerequisites, and comparison signals adequately. The main gap is that nothing tells the agent what the comparison returns or how to interpret a positive/negative ownership signal.

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?

Schema description coverage is 100%, so both job_id_a and job_id_b are already documented. The description adds a meaningful constraint beyond the schema: the two IDs must reference DIFFERENT apps' jobs and both must be completed, which prevents a common misuse as a version diff.

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?

States a specific verb (compare), a specific resource (two apk-teardown jobs), and the analytical goal (evidence of common ownership). It also explicitly separates itself from the sibling diff tool by clarifying these are two DIFFERENT jobs, not versions of the same app.

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?

Clearly frames the condition for use: two distinct completed jobs, explicitly excluding the same-app-version case. It does not name apk_teardown_diff as the tool to use for that excluded case, so the routing is implied rather than spelled out.

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