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

With no annotations, the description carries the full behavioral burden. It does disclose the data source (adapters/*.manifest.json) and the returned attributes, but never states that this is a side-effect-free read or anything about auth/scope. Adequate but incomplete for a zero-annotation tool.

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

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

Two tight sentences with the verb and resource front-loaded; the field list is compact and every clause earns its place.

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

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

An output schema exists, so return values need no prose explanation, and the description adds the manifest-as-plugin-contract framing. It is nearly complete, only missing an explicit read-only cue.

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

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

The tool takes no parameters, so the baseline is 4. There is nothing for the description to clarify beyond confirming the call needs no arguments.

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

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

States a specific verb (列出/list) and resource (data source adapters), and enumerates the returned fields (名称/模态/模式/幂等机制). This clearly separates it from sibling tools that query, export, or ingest data.

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

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

Implies usage (discovering available adapters) but never states when to reach for this versus siblings like lifedb_ingest_jsonl or lifedb_stats, nor any prerequisites. The docs/PRODUCT.md §3 pointer is a reference, not usage guidance.

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

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 query performs a three-branch UNION with full index seek, which conveys cross-modal scope and performance characteristics, but it does not state whether the operation is read-only, what permissions are needed, how results are ordered, or any pagination behavior.

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

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

The description is two tight sentences that front-load the core behavior and then add implementation/use context. Every part earns its place, and there is no redundant restatement of the schema or title.

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

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

An output schema exists, so return values need not be described. However, with no annotations and 0% schema description coverage, important gaps remain: the ts format, the limit parameter's effect, and any routing guidance versus sibling tools are missing. The description is adequate but not complete 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.

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

Schema description coverage is 0% for three parameters. The description adds useful meaning for window by giving example formats and clarifying that it spans before and after ts, and it implicitly explains ts as the center point, but it completely omits the limit parameter and does not specify the expected timestamp format.

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

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

The description clearly states the tool returns all cross-modal events within a window before and after a timestamp, with examples like '30m'/'2h'/'1d'. It is specific about the resource and temporal scope, but does not differentiate itself from sibling tools or begin with a clear action verb such as 'list' or 'retrieve'.

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

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

The phrase '用于那一刻发生了什么' gives an implied use case for exploring a specific moment, but there is no explicit guidance on when to prefer this tool over siblings such as lifedb_query_month or lifedb_geo_track, nor any when-not-to-use condition.

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

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

无 annotations，描述需承担全部行为披露义务。仅说明打包内容，未提权限要求、数据量上限行为、返回结构或是否只读等行为特征。

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

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

单句结构，先点明操作再以括号列出组成部分，信息密度高且无冗余。

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

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

虽有 output schema，返回内容无需描述，但参数语义覆盖 0%、无 annotations，加上 4 个参数的行为细节缺失，整体对正确调用而言仍不充分。

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

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

schema 描述覆盖率 0%，4 个参数 (start/end/max_points/modalities) 在 schema 中仅有无描述的字符串/整数字段。描述补充了 events 模态名可过滤及 track 抽稀，暗含 modalities 与 max_points 语义，但仍未说明 start/end 格式、max_points 含义与默认值等，补偿不足。

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

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

使用清晰具体的动词+资源，说明是打包某时间窗的 atlas 数据，并逐项列出所含内容 (track/events/photos)。未与其他兄弟工具 (如 lifedb_geo_track、lifedb_query_month) 做区分。

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

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

说明适用于地图类应用 (Life Atlas/vlog)，暗示使用场景，但未给出何时应选用此前工具而非 lifedb_geo_track 等替代项，也无排除条件。

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

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

With no annotations, the description carries the full burden, and it delivers a genuinely non-obvious behavioral trait: when `limit` truncates, points are uniformly downsampled (keeping first and last) rather than head-only truncated. It does not disclose permissions, rate limits, or cost, but the truncation disclosure is a meaningful addition beyond structure.

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

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

Four short, front-loaded clauses with no filler; the output tuple format leads, followed by time formats, use case, and truncation behavior. Every clause carries information, though the phrasing is terse and could be marginally more readable.

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

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

An output schema exists, so return values need not be documented, and the description still adds output shape, param formats, and truncation semantics. For a 3-parameter read tool this is largely complete; only access/permission context is absent.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it explains that start/end accept ISO time or epoch seconds and that limit truncates via uniform downsampling. This covers all three parameters with format and behavior detail the schema lacks.

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

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

The description names the specific resource (raw GPS point sequence with ts/lat/lon/alt/speed) and the intended consumer (trajectory rendering), so the agent understands it fetches a geospatial track rather than aggregate stats. It is clear, though it does not explicitly differentiate itself from siblings like lifedb_around or lifedb_query_month.

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

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

It gives a concrete usage context — feed the output to deck.gl TripsLayer / Manim for trajectory rendering — which tells the agent when this tool is the right fit. It stops short of naming alternatives or exclusion cases, so it is clear context without routing guidance.

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

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

With no annotations, the description carries the full burden and does well: it discloses idempotency via payload_hash=sha256(source|payload_ref|ts_start)[:16], that repeated runs have zero side effects, and that the default mode is a non-mutating preview. It omits auth/permission requirements and error/partial-failure behavior, so not a 5.

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

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

Three tight sentences, each load-bearing: format requirements, idempotency guarantee, and dry-run workflow. The safety-relevant dry_run default is front-loaded in a scannable way.

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

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

An output schema exists, so return values need not be explained, and the description covers the essential behaviors for a mutation tool (idempotency, default preview, input format). Only permission/error-handling context is absent, which keeps it just short of complete.

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

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: it explains dry_run's default-and-override semantics precisely and constrains the path input to a JSONL file with required per-line fields. It adds substantial meaning beyond the bare schema types, though it does not describe path format/paths conventions.

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

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

States a specific verb (导入/ingest) and resource (统一 JSONL 事件文件), and even specifies the record schema (每行一个 JSON, ts_start/modality/source 必填). It is clearly distinguished from the read-oriented siblings (stats/query/export) as the single write/ingest path.

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

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

Gives a clear operational workflow: default dry_run=True produces a preview, and writing only happens when dry_run=false is passed explicitly. This tells the agent how to use the tool safely, though it names no alternative tool or explicit when-not-to-use condition.

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

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 discloses the sort order (ts_start ascending) and schema uniformity, but says nothing about pagination behavior, permissions, rate limits, or handling of empty/out-of-range months despite exposing limit/offset parameters.

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

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

Three short sentences with the purpose front-loaded and no filler. It is terse to the point of under-specification, but every sentence carries information and nothing is wasted.

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

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

An output schema exists, so return values need not be re-explained, but for a three-parameter tool with no annotations the description omits pagination semantics, sibling differentiation, and the meaning of limit/offset. It is not complete enough for an agent to call it confidently beyond the happy path.

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

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 for all three parameters. It usefully gives the month format ('2026-10'), but limit and offset are left entirely unexplained in both schema and description, leaving two of three parameters undocumented.

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

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

States the resource (a month's timeline) and clarifies the return (unified-schema event rows), so an agent knows it retrieves one month's events. It does not differentiate itself from siblings like lifedb_around or lifedb_stats, which likely also read timeline data, so the boundary remains implicit.

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

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

There is no explicit when-to-use, no when-not-to-use, and no mention of alternatives. The agent must infer from the noun phrase that this is the monthly-window query, with no guidance on how it differs from the range/around/geo tools among its siblings.

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

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

With no annotations, the description carries the full behavioral burden. "Self-check" returning counts and coverage strongly implies a read-only diagnostic, which is useful, but it never states read-only-ness, permission needs, cost, or whether it touches/locks the store.

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

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

Two short clauses: the first front-loads what is returned, the second gives the call timing. No filler, every clause earns its place.

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

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

An output schema exists, so return values need no further explanation, and zero params means no argument gaps. The only shortfall is that a no-annotation tool could still say more about safety/read-only behavior.

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

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; schema description coverage is 100% and there is nothing for the description to compensate for.

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

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

The description names a concrete operation (library self-check) and enumerates exactly what it reports: schema version, per-modality/source counts, and time coverage. This makes it clearly a diagnostic/stats tool and distinguishable from the query/export/ingest siblings, though it does not explicitly name those siblings.

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

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

"应用接入后先调这个" gives an explicit trigger: call this first after the application is integrated. That is clear when-to-use guidance, but there are no exclusions or comparisons against alternatives such as lifedb_query_month.

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