Skip to main content
Glama
axiomzero-qed

DAXQO Trajectory Collector MCP Server

by axiomzero-qed
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

DAXQO Trajectory Collector

Local GUI action recording, privacy filtering, replay and dataset export for any harness.

本地 GUI Agent 轨迹采集工具，可通过 Python API、命令行或 MCP 接入不同 harness。数据处理无需运行 DAXQO 或 Motor；Android 原生观察器另有明确的 bridge 依赖。

  • Python 3.10+, standard-library-only runtime, MIT license.

  • Durable JSONL + SQLite, conflict detection, idempotent ingestion and leakage-aware exports.

  • Sensitive UI/input values and hidden reasoning filtered before persistence.

  • No model provider, cloud upload or training service included.

Install

python -m pip install "git+https://github.com/axiomzero-qed/DAXQO-Trajectory-Collector.git@v0.1.0"

From a source checkout: python -m pip install .. No sibling checkout is needed. Motor is optional.

Related MCP server: wisp

Use from another harness

from pathlib import Path
from trajectory import Dataset, Recorder, snapshot

with Dataset(Path("./data")) as dataset:
    writer = Recorder(dataset,
        device_id="b683d45a-e298-40b3-90c2-3bcd8f59cb84",
        session_id="7468c2e4-dae4-4d3b-b959-b6e671f6f951",
        source="my_harness")
    receipt = writer.record_action(
        task_id="example-task", action_id="example-action",
        action={"type": "click", "target": {"resource_id": "details"}},
        before=snapshot("demo.app", [{"text": "Details"}]),
        after=snapshot("demo.app", [{"text": "Demo details"}]),
        status="succeeded",
        started_at="2026-10-24T10:00:00Z",
        finished_at="2026-10-24T10:00:01Z")

This records synthetic observations and performs no device action. In production, supply observations/outcomes from the existing executor and assign your own stable device UUID. Keep the device/session/action IDs, source, timestamps and contents unchanged when retrying; conflicting retries are rejected.

Reported success remains an unverified agent claim. Independent human/fixture verification is required for positive training examples by default.

CLI and MCP

daxqo-collect --data ./data stats
daxqo-collect --data ./data import ./actions.jsonl
daxqo-collect --data ./data replay --output ./dist/replay.html
daxqo-collect --data ./data export --output ./exports/scoring --split-by task
python -m trajectory.mcp_server --data ./data --device-id b683d45a-e298-40b3-90c2-3bcd8f59cb84

MCP tools: trajectory_record, trajectory_stats, trajectory_export. They record supplied actions; they never execute phone actions. See harness integration, host config and schema.

Optional Android observer

USB collection needs a compatible DAXQO Android bridge, an authorized ADB connection and the owner's existing phone-control permissions. No root is required. The core API/MCP path above needs no ADB, APK or DAXQO harness.

daxqo-collect --adb /path/to/adb --serial DEVICE_SERIAL devices
daxqo-collect --adb /path/to/adb --serial DEVICE_SERIAL --data ./data start --task "Browse the fixture" --allow-app io.daxqo.trajectoryfixture
daxqo-collect --adb /path/to/adb --serial DEVICE_SERIAL --data ./data watch

Coordinate one ACK receiver and one explicit Dataset root per device stream. Replay only inspects records; it never repeats historical actions. See Android build/integration. Native observer sources are canonical in this repository.

Development

python -m pip install ".[dev]"
python -m unittest discover -s tests
python -m build
python examples/mcp_smoke.py

The independent official MCP client smoke test uses synthetic inputs and an isolated working directory. Historical device results do not replace acceptance on a new device/harness.

Source releases exclude device data, credentials, generated reports, APKs and website sources. See dataset behavior.

Available Tools

3 tools
trajectory_exportC

Export a dataset under the operator-configured export directory.

NameRequiredDescriptionDefault
nameNo
split_byNo

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 must carry the full behavioral burden. It discloses that the operation exports data to an operator-configured directory, but it omits overwrite behavior, permissions or auth requirements, output format, and whether the action is destructive or reversible.

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 front-loaded sentence with no wasted words. Its brevity is efficient, though it contributes to the broader under-specification of the tool.

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 two parameters, no annotations, no output schema, and 0% schema description coverage. The description adds only the export-directory context and leaves parameter behavior, return values, and side effects unexplained. That is too thin for an agent to invoke the tool confidently.

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 either parameter. It does not explain what the name parameter identifies or how split_by changes the export. The agent must infer both from bare schema fields and an enum alone.

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 and resource: export a dataset. It also adds a scope detail, the operator-configured export directory. It does not explicitly distinguish this tool from trajectory_record or trajectory_stats, so it falls short of 5.

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 trajectory_record or trajectory_stats. It also omits prerequisites, alternatives, and any when-not-to-use conditions. The only contextual cue is that exports go under the operator-configured directory.

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

trajectory_recordC

Record one externally executed action; never performs device actions.

NameRequiredDescriptionDefault
afterYes
modelNo
stageNo
actionYes
beforeYes
statusNo
subgoalNo
task_idYes
action_idYes
user_taskNo
confidenceNo
error_codeNo
started_atYes
finished_atYes
tool_call_idNo
candidate_actionsNo

TDQS

C2.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 behavioral burden. It usefully discloses that the tool never performs device actions, but it omits persistence behavior, auth requirements, idempotency/duplicate handling for action_id, and what the call returns.

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 tight two-clause sentence with the core purpose and non-execution guarantee front-loaded. It contains no fluff, though it is arguably too terse for a tool with this many parameters.

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 16 parameters, no annotations, no output schema, and 0% schema description coverage, a single-sentence description is substantially incomplete. It communicates purpose and non-execution but leaves usage context, parameter semantics, and behavioral details unaddressed.

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% across 16 parameters, including 7 required fields and nested before/after/action objects. The description mentions only 'one externally executed action' and provides no meaning for task_id, action_id, timestamps, status enum, or other parameters.

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 and resource: 'Record one externally executed action.' The clause 'never performs device actions' further distinguishes it from an execution tool. It does not explicitly differentiate from its siblings, but those siblings are unrelated stats/export tools.

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 'externally executed action' implies the tool is used after an action has already been performed elsewhere, and 'never performs device actions' clarifies what it should not be used for. However, there is no explicit when-to-use guidance, prerequisites, or comparison to alternatives.

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

trajectory_statsB

Read local trajectory counts and quality statistics.

NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description bears the full disclosure burden. 'Read' implies a read-only operation and 'local' scopes the data source, but there is no mention of permissions, whether data is cached/refreshed, cost, or what the statistics contain.

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?

A single short sentence with the resource front-loaded and no filler. Nothing is wasted, though it is arguably too terse rather than too long.

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?

For a zero-param, read-only tool with no output schema and no annotations, the description is the only source of information about results. 'Counts and quality statistics' is left vague — no shape, units, or freshness — so the definition is adequate but leaves real gaps.

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 takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. No parameter-level detail is needed.

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?

Specific verb 'Read' paired with a concrete resource: trajectory counts and quality statistics. This distinguishes it from siblings trajectory_record (write) and trajectory_export (export), though it doesn't explicitly name them.

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 never states when to use this versus trajectory_record or trajectory_export, nor any prerequisites. Only the word 'local' hints at scope, leaving callers to infer the routing decision themselves.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedtrajectory_export
    • First observedtrajectory_record
    • First observedtrajectory_stats
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.3/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct action: recording, reading stats, and exporting. There is no meaningful overlap or ambiguity between them.

Naming Consistency5/5

All tools follow the same trajectory_<action> convention with consistent snake_case and a shared domain prefix. The pattern is predictable and readable.

Tool Count5/5

Three tools is well-scoped for a focused trajectory collector. Each tool earns its place and supports a core workflow stage.

Completeness4/5

The surface covers recording, observing statistics, and exporting data, which are the main lifecycle operations. Minor gaps exist around listing or inspecting individual trajectories, but agents can work around this through export.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers