人生增值 ZengZhi — 个人数字资产审计/撮合平台 (digital-asset audit/matchmaking): 公开 tools 免 Key, 个人数据需 Bearer zzk_.
Scored across 10 tools
Most tools have clearly distinct purposes, with standard list/get pairs (directory vs public_page, report_orders vs report_detail). However, report_detail accepts a page_id and thus overlaps with public_page, and account_overview somewhat overlaps with my_market (summary vs raw JSON snapshot) and ping.
Every tool uses the same zengzhi_ prefix followed by a descriptive snake_case noun phrase, so the set is highly predictable and readable. No mixed conventions or inconsistent verb styles across the 10 tools.
Ten tools is well within the sweet spot and each one maps to a distinct capability area: onboarding docs, platform meta, public discovery, self/quota checks, account and market snapshots, orders, and price references. Nothing feels padded or missing at the count level.
The surface covers discovery (directory, public_page, price_refs), self-service (ping, account_overview, my_market), orders (report_orders, report_detail), and onboarding (meta, code_of_conduct), which is strong for a read-oriented bridge server. Minor gaps remain, such as no keyword search on the directory and no asset/order submission tools, though writes are intentionally left to REST.
主人账号总览（key 即持有人本人）：订单/页面/委托/意向等全貌摘要。需 API Key。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions '需 API Key' (requires API Key), which is a minor auth hint, but does not disclose whether this is a read-only operation, what data is returned, rate limits, or any side effects. For a zero-parameter overview tool, this is a significant gap in behavioral context.
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 a single, compact sentence that front-loads the core purpose and includes the key requirement. It is efficient with no waste, though slightly cryptic in wording.
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?
Given no annotations, no output schema, and zero parameters, the description is thin. It does not explain what the overview contains in detail, how it is structured, or what an agent should expect. It mentions an API Key requirement but leaves many aspects incomplete for correct invocation.
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?
Parameter count is 0, so the baseline is 4. The description correctly indicates no parameters are needed and adds no confusing parameter information.
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 states it is a master account overview covering orders/pages/entrustments/intentions, giving a general sense of the resource. However, it does not clearly distinguish itself from siblings like zengzhi_my_market or zengzhi_report_orders, which also appear to deal with user-specific data. The purpose is implied but not sharply defined.
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 guidance on when to use this tool versus alternatives. It does not mention scenarios, prerequisites beyond an API Key, or exclusions. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
人生增值平台行为规范（markdown 原文）：接入前必读，写明 Agent 的边界与义务。免 key。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden and discloses that no key is required ('免 key') and that the content is markdown original text. It does not explicitly state read-only or non-destructive behavior, but these are strongly implied for a document retrieval 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?
The description is one compact sentence plus a short fragment, front-loaded with the resource name and format. Every element — purpose, usage condition, content summary, and auth note — earns its place without repetition.
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?
For a simple, zero-parameter document retrieval tool with no output schema, the description supplies the return format (markdown original text) and access requirement (no key). It is complete enough for correct invocation, though it could state read-only behavior more explicitly.
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 has zero parameters, so there is nothing for the description to document. The baseline score of 4 applies, and the description appropriately avoids inventing parameter details.
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 identifies the resource as the platform's code of conduct and specifies its format (markdown original text). It does not explicitly differentiate from sibling tools, but the content is specific enough for an agent to know what it retrieves.
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 states '接入前必读' (required reading before access), giving a clear condition for use. It does not name alternatives or describe when not to use it, so it falls short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
公开资产展示页目录（游客可看，笔名出镜、素材保密）。免 key。
Args:
cat: 资产类别过滤（T1 经验诀窍 / T2 模板清单 / T3 数据语料 / T4 软件工具 /
T5 内容作品 / T6 视觉设计 / T7 垂直影响 / T8 AI 资产）；留空=全部
page: 页码，从 1 起
size: 每页条数，默认 24，最大 100
| Name | Required | Description | Default |
|---|---|---|---|
| cat | No | ||
| page | No | ||
| size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does disclose meaningful traits: no API key required, publicly viewable by guests, pen names displayed but underlying materials kept confidential. It does not describe response/pagination behavior in detail, but the auth and privacy disclosures are the important context here.
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?
Front-loaded with the tool's scope and the no-key note, followed by a compact Args block. The category enumeration is long but is load-bearing since the schema does not encode the enum values.
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?
For a 3-parameter public read listing with no annotations and no output schema, the definition covers purpose, auth/privacy scope, and every parameter's semantics and bounds. Return-format details are not needed since no output schema exists, though some result-size/pagination context could still be added.
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 and largely does: it enumerates all eight category codes for `cat`, notes empty = all, defines `page` as 1-based, and gives `size` default 24 / max 100. Only minor edge details (e.g., behavior when page exceeds range) are absent.
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+resource: a directory/listing of publicly visible assets, with the guest-visibility and confidentiality scope made explicit. It does not explicitly differentiate itself from near-siblings such as zengzhi_public_page, so it stops short of a 5.
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?
"游客可看…免 key" implies the usage context (no authentication needed, guest-accessible browsing) but gives no explicit when-to-use vs when-not, and does not name an alternative sibling to route to. Usage 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.
人生增值平台元信息（端点矩阵唯一事实源）：业务结构、八类资产、认证方式、 route_flags 全量端点清单（哪些 key 可调、哪些 HUMAN_ONLY）、每日配额口径、反馈入口。
接入后建议第一条调用。免 key。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the key behavioral facts: no API key is required, it is the recommended first call, and it is the authority on which endpoint keys are callable versus HUMAN_ONLY. It does not describe the response format or size, but for a zero-parameter read-only meta endpoint the disclosure need is modest.
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 content list is front-loaded and dense with no filler, and the operational hints ('建议第一条调用', '免 key') are placed last where they matter. The single run-on enumeration is slightly heavy but every clause names a distinct payload section.
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?
There is no output schema, so the description must convey what comes back, and it does list the returned sections (structure, assets, auth, route_flags, quotas, feedback). What is missing is any sense of response shape or size, which would help an agent decide how to consume it.
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 schema has zero parameters, so the baseline is 4. The description correctly implies a parameterless fetch and adds no misleading argument expectations.
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 specific resource (the platform meta-information endpoint) and enumerates exactly what it exposes: business structure, the eight asset classes, auth method, the full route_flags endpoint list with callable/HUMAN_ONLY marking, daily quota definitions, and the feedback entry point. Calling it the '唯一事实源' (single source of truth) for the endpoint matrix clearly separates it from all ten sibling tools.
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, actionable when-to-use instruction — call this first after onboarding. It also notes '免 key', removing a common blocker. It stops short of naming what to do instead of this tool or when it is unnecessary, so it is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
主人的市面四合一快照：deals/mine（成交申报）、deeds/mine（委托书）、 intents/mine（我方购买意向）、intents/received（收到的购买意向），各自原样 JSON。需 API Key。
只读快照；撤回意向、申报成交等写操作走 REST（intents/{id}/cancel、deals/declare），由主人拍板。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does disclose the key traits: API Key required (auth), read-only nature, that each component returns raw JSON, and that writes live elsewhere. It omits pagination, rate limits, or freshness semantics, but covers the essentials for a no-argument snapshot.
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 lines: the first front-loads what is returned and the auth requirement, the second handles scope boundary (read-only vs writes). Every clause carries information; no filler.
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?
For a parameterless, read-only snapshot with no output schema, the description is complete: it names the returned datasets, notes they are raw JSON, states the auth requirement, and clarifies the read/write boundary. Nothing an agent needs to invoke it correctly is missing.
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 and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies since no parameter meaning is required.
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 resource (the owner's market data) and enumerates exactly the four sub-resources it snapshots (deals/mine, deeds/mine, intents/mine, intents/received) with parenthetical glosses. An agent can immediately tell this is a read-only aggregate view, distinct from write-oriented 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?
Explicitly frames the tool as a read-only snapshot and routes write operations (withdrawing intents, declaring deals) to REST endpoints, naming the concrete routes. This gives clear when-not guidance for mutations, though it offers no differentiation against read-oriented siblings like zengzhi_account_overview.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
身份自检 + 当日配额快照：确认 key 有效、是谁的 key，回各配额 limit/used/remaining。需 API Key。
被限流/超额时先调它自查，别盲目重试。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it does meaningful work: it discloses the auth requirement ('需 API Key'), the diagnostic/read-only nature of the call, and the returned quota fields (limit/used/remaining). It does not state side-effect profile explicitly or pagination, keeping it short of 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?
Two tight sentences, front-loading the core purpose before the usage trigger; every clause earns its place with no 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?
For a zero-parameter diagnostic tool with no output schema, the description adequately covers auth needs, returned quota fields, and the trigger condition. It could have been slightly more explicit about the read-only/side-effect profile, but an agent has enough to call it correctly.
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?
Zero parameters, so the baseline of 4 applies and the schema is trivially complete; there is no parameter syntax the description needs to add.
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 compound purpose: identity self-check (key validity and owner) plus a daily quota snapshot returning limit/used/remaining. Clear verb+resource, though it does not explicitly differentiate itself from the sibling zengzhi_account_overview, so it stops short of a 5.
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 explicit situational guidance: '被限流/超额时先调它自查，别盲目重试' tells the agent exactly when to call it (rate-limited/over quota) and what not to do (blind retries). It does not name an alternative sibling, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
价格参考库：同类资产的真实成交/挂牌区间汇总（含来源与时间；非平台估价，平台不作价值鉴定）。需 API Key。
Args:
cat: 类别（T1–T8 或其名称）；want_range=true 时必填，返回该类别的合计区间
kw: 标题关键词过滤（仅列表模式）
page/size: 分页（仅列表模式）
want_range: true=改查该 cat 的价格区间汇总（/price-refs/range）
| Name | Required | Description | Default |
|---|---|---|---|
| kw | No | ||
| cat | No | ||
| page | No | ||
| size | No | ||
| want_range | No |
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 the API key requirement, that this is a reference library rather than platform appraisal, and that records include source/time. However, it does not explicitly state read-only vs. write behavior, rate limits, error cases, or result shape.
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?
Front-loads the resource definition, then documents parameters compactly in a structured Args block. Every sentence and line contributes meaning without redundant restatement.
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?
Given 5 parameters, no output schema, and no annotations, the description covers purpose, authentication, mode behavior, and all parameters. It stops short of describing list-mode result contents or pagination behavior, so it is not fully 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, and it does. The Args section defines every parameter's role and mode dependency, including cat's conditional requirement under want_range=true and want_range's function as a mode switch.
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 resource (price reference library) and content (real transaction/listing ranges for similar assets, with source/time), and explicitly distinguishes itself from platform valuation. An agent can tell what the tool returns and how it differs from appraisal functionality.
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?
Explains the two modes through want_range and which parameters apply in each: cat is required for range mode, while kw/page/size are list-only. It also notes the API key requirement. It does not name alternative sibling tools or give when-not-to-use guidance, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按 page_id 取单个公开展示页（笔名、简介、SKU 概览；不含私密素材）。免 key。
page_id 来自 zengzhi_directory 返回的条目。原文：https://zengzhi.life/directory/{page_id}
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the read-only nature (取), the absence of auth requirements (免 key), and what is deliberately omitted from the response (不含私密素材). It does not address error behavior, rate limits, or what happens for invalid/private page_ids, so it is strong but not exhaustive.
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?
Purpose is front-loaded in the first clause, followed by scope, auth note, parameter provenance, and a URL example — every sentence adds distinct information with no padding.
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?
For a single-parameter read tool with no output schema and no annotations, the description covers purpose, returned fields, private-material exclusion, auth requirements, and parameter provenance. Only return-shape/error details are missing, which is a minor gap given the endpoint's simplicity.
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, and it does: it identifies where page_id originates (zengzhi_directory entries) and shows the canonical URL pattern it maps to (https://zengzhi.life/directory/{page_id}). It still does not state the expected integer format or validity constraints beyond that.
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 and resource ('按 page_id 取单个公开展示页') and immediately scopes the content returned (笔名、简介、SKU 概览) versus what is excluded (不含私密素材). This clearly distinguishes it from the listing sibling zengzhi_directory, which it names as the source of page_id.
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 explicit upstream context: page_id must come from a zengzhi_directory entry, and the tool is free of key requirements (免 key). It does not state when NOT to use this tool or contrast it with other detail tools like zengzhi_report_detail, so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
盘点订单或展示页详情，二选一传参。需 API Key。
Args:
order_id: 盘点订单 id（来自 zengzhi_report_orders）；
include_step0=true 时附带返回该单的 Step0 素材引导问答
page_id: 展示页 id（二选一，传了 page_id 就忽略 order_id）
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | No | ||
| order_id | No | ||
| include_step0 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose two useful traits: an API Key is required, and include_step0=true changes the payload by attaching Step0 素材引导问答 for the order. It does not state that the operation is read-only, what happens if neither id is supplied, or any rate/error 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?
Front-loaded one-liner stating the resource, the either/or constraint, and the auth requirement, followed by a compact Args block. Every sentence carries information; only the loose formatting (trailing newline/indentation) is mildly untidy.
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?
Covers auth, the two mutually exclusive identifiers, and the include_step0 side effect, which is most of what a 3-param tool needs. However, with no output schema and no annotations, it leaves undefined what the detail payload contains and what happens if both parameters are omitted (both default to 0).
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, and it documents all three parameters: order_id (with its origin tool), page_id (with explicit mutual exclusivity and override rule), and include_step0 (with the conditional extra return). Types and defaults are still only in the schema, but the semantics are well covered.
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/resource pair — retrieve details for either a 盘点订单 or a 展示页 — and names zengzhi_report_orders as the source of order_id, which anchors it in the sibling set. It does not explicitly contrast with other siblings like zengzhi_public_page, so it falls short of a 5.
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?
Explicitly states '二选一传参' and clarifies precedence: '传了 page_id 就忽略 order_id', so the agent knows which parameter wins when both are supplied. It also points to zengzhi_report_orders as the upstream call to obtain order_id, giving clear context without stating when-not-to-use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出主人的深度盘点订单（最近 50 条：单号、类别、状态、关联展示页、自报价）。需 API Key。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose two behaviorally important facts: the result is capped at the latest 50 records, and an API Key is required for access. It does not explain pagination or how to obtain older records, which is the remaining gap.
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?
A single compact sentence with the action front-loaded and no filler. The parenthetical field list earns its place by telling the agent what to expect.
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?
For a zero-parameter list tool with no output schema and no annotations, the description covers the essentials: what is listed, how many, which fields, and the auth requirement. Only pagination/older-record access is unaddressed.
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 schema has nothing to document. The description instead enumerates the returned fields (单号、类别、状态、关联展示页、自报价), which is useful context even though it is not strictly parameter documentation.
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 (列出) and resource (深度盘点订单), and qualifies the scope as the most recent 50 records with the fields returned. It implies a list-vs-detail distinction against the sibling zengzhi_report_detail, but never names an alternative explicitly.
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 / when-not-to-use guidance or named alternative. However, the scoping detail (主人's own orders, most recent 50) implicitly tells the agent what scenario this fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
zengzhi_account_overviewzengzhi_code_of_conductzengzhi_directoryzengzhi_metazengzhi_my_marketzengzhi_pingzengzhi_price_refszengzhi_public_pagezengzhi_report_detailzengzhi_report_orders一人行 SoloTeam — 一人公司联盟 (solo-company alliance): 名录/互补推荐/政采线索 read-only; 身份类 tools 需 Bearer yrx_.
17 Base data tools for agents over Streamable HTTP MCP. Pay per call in USDC via x402; no API key.
Independent directory of agentic AI tools — search, compare & recommend via MCP. Read-only.
X-Z-CS AI validation with auditable reasoning. 8 active tools; 5 in maintenance. v0.5.64
Add one secure layer between your agents and this server.
