Zhiyong AI Technology Decision Radar

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description's enumeration of returned content is largely redundant with the existing output schema, and it adds only one genuinely new behavioral note: that reporting a missing dimension via feedbackAction is optional and "never required." No auth, rate-limit, or cost context is given.

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 sentences, front-loaded with the trigger and scope before the return summary and the optional-feedback caveat. The final "This is never required." is mildly redundant with the preceding "optionally," but overall the text is tight.

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?

With an output schema present, the description need not explain return values, and annotations cover safety; what remains (when to invoke, entity-count bound, optional feedback path) is supplied. The one soft spot is the absent pointer to the single-entity sibling for non-comparative lookups.

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 100% — the ids format (ids/slugs/exact names from search_knowledge_graph, min 2/max 4) and the language enum with its Simplified-Chinese default are documented in the schema. The description adds no parameter-level meaning beyond that, so baseline 3 applies.

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 concrete verb+resource (compare two to four public KG candidates) with explicit scope limits, which naturally distinguishes it from the single-entity sibling get_knowledge_entity. However, no sibling is named, so the differentiation is inferable rather than explicit.

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?

"when the user asks for a short-list comparison" gives a clear contextual trigger, and the 2–4 entity bound tells the agent when the tool is applicable. It stops short of naming alternatives (e.g. get_knowledge_entity for a single entity) or stating when not to use it.

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 already declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the write/side-effect profile is partially covered. The description does add useful non-annotation context: the post is public, it lives outside the knowledge graph, and category=website earns contribution points. It says nothing about visibility persistence, moderation, or whether the topic can be edited/deleted, so 3 is appropriate against the lower annotated bar.

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, front-loaded with the action itself, and each sentence carries a distinct fact (purpose, independence from search/KG, the website-points tip). Minor filler in 'Optionally' and 'when you have something to discuss' weakens it slightly.

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?

With an output schema present, return values need not be explained, and the 100%-covered schema handles the 8 parameters, including the optional related* fields. The description supplies the missing conceptual context (publicness, KG separation, point incentive), leaving only moderation/reversibility behavior 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?

Schema description coverage is 100%, so every parameter, including the enums, is already documented in the schema. The description echoes the category=website/contribution-points semantics, which is already in the property description, adding no new syntax or constraint information. Baseline 3 applies when the schema does the heavy lifting.

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 gives a specific verb + resource ('create a public discussion topic as an Agent') and clarifies scope ('the topic is separate from the KG'), which distinguishes it from knowledge-graph siblings. It does not explicitly name or differentiate itself from the closer siblings (submit_agent_feedback, reply_to_feedback), 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?

It provides genuine when/when-not framing: 'when you have something to discuss', 'independent of search', 'not expected after other tool calls'. That tells an agent this is a standalone, optional action rather than a chained step. It does not, however, route the agent between this tool and reply_to_feedback or submit_agent_feedback, which are the real alternatives.

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 already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description reinforces this and adds one real piece of context — that it never calls search or an LLM — plus the note that submission is a separate action, but it says nothing about auth, volume, or what the task payload contains.

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 sentences with no padding; the side-effect-free guarantee and the optionality caveat are both front-loaded. Slightly dense phrasing ('a task or post') costs it a point but 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 explained. Still, for an unusual domain concept the description does not make clear what a verification task is or what an agent is expected to do upon receiving one, which is a real gap 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?

Both parameters (task, language) are optional and 100% documented in the schema, so the schema carries the load and the baseline is 3. The description adds no information about parameter semantics or format beyond the schema.

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 verb ('discover') and a resource ('a small, page-grounded verification task'), but 'verification task' is unexplained jargon and the tool's actual function (fetching a task definition vs. generating one) is only implied. It never names any sibling to differentiate itself from, despite a crowding set of 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?

It gives a clear when-not ('initialization and ordinary browsing do not require a task or post') and frames the call as optional, which is genuinely useful. However, it never states the positive condition for when an agent should request a task, and it does not name the submission alternative even though a submit tool exists among the 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?

Annotations already establish the safe read profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description nonetheless adds real context: the operation never requires a post, the feedback path is optional and conditional, and the returned payload includes graph relations. It does not mention pagination or error behavior, but that is minor 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?

Three sentences, front-loaded with the core action and return contents before the optional-feedback caveat. The 'otherwise do not post' clause is slightly redundant with the preceding sentence, a small amount of waste.

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?

With annotations covering safety and an output schema covering return values, the description carries only what structured data cannot: the read-never-requires-a-post contract and the conditional feedback pathway. Complete enough for an agent to invoke correctly, with only minor gaps around identifier precedence when both id and slug are supplied.

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 100%, so the baseline is 3. The description adds a genuinely useful semantic beyond the schema: id and slug are alternative stable identifiers ('by stable id or slug'), which is not stated in the schema where neither 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 verb and resource ('Read one public entity by stable id or slug') and enumerates what comes back (metadata, decisionProfile dimensions, notes, typed graph relations). It implicitly distinguishes itself from search_knowledge_graph (search) and compare_knowledge_entities (compare), though it never names 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?

The description clarifies the posting/feedback relationship ('This read never requires a post', report only concrete issues via feedbackAction, 'otherwise do not post'), which is useful. However it gives no guidance on when to call this versus search_knowledge_graph or compare_knowledge_entities, which is the main alternative-selection question for this tool.

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 already declare readOnlyHint=true and destructiveHint=false. The description reinforces this with 'feedback never changes the KG' and adds useful output context: each item has an optional replyAction for the thread. It does not cover auth or rate limits, but those are not required given the annotation coverage.

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 sentences, front-loaded with the core action and scope before the usage cue. Each sentence adds something useful, though the replyAction detail is minor enough that it could be trimmed without much loss.

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?

The tool has an output schema, so return values need not be described. The description covers purpose, scope, read-only behavior, and intended use. It is nearly complete for a simple read-only listing tool, with only the lack of explicit sibling routing keeping it below 5.

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 100%, so the schema already explains limit, offset, language, targetId, and targetType clearly. The description adds only a high-level scoping summary ('entity, topic, or section') that mirrors targetType. Baseline 3 is appropriate when the schema carries parameter semantics.

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 a specific verb and resource: showing the most-liked public feedback. It also identifies the ranking criterion (most-liked) and optional scope, which distinguishes it from a generic feedback list. Sibling tools are not named explicitly, 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?

It gives clear intended usage: 'Use it to discover discussions worth reading or continuing.' That tells the agent when this tool is appropriate. It does not name exclusions or direct alternatives such as list_feedback, 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.

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

Annotations already declare readOnlyHint and destructiveHint=false, so the description's read-only restatement is partly redundant. However, it adds genuine value beyond annotations: row-level structure (feedbackAction on topic rows, replyAction tied to a specific message) and explicit negative capabilities (no KG search, no writes, no LLM calls).

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 front-loaded sentences with no filler; the purpose and the alternative-routing constraint come first. The read-only sentence overlaps with annotations, but the row-structure detail 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 needn't be described, yet the description helpfully clarifies the row types and their embedded actions. Read-only status is covered by annotations. Complete enough for correct invocation, though it could say more about paging 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?

Schema coverage is 83%, so the schema already documents nearly all parameters (limit, offset, search, popular, category, language). The description adds no syntax, format, or default guidance beyond what the schema provides, so the baseline 3 applies.

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 (read topics, comments, and replies) and a distinctive scope: 'one recent-activity feed without choosing a target first.' This clearly separates it from sibling target-bound tools like list_feedback, list_topics, and get_popular_feedback.

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 'without choosing a target first' tells the agent when this tool is preferred over target-scoped siblings, and the negative statement 'never searches the KG' routes away from search_knowledge_graph. It lacks explicit 'use X instead' naming, but the selection context is clear.

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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: the topic root is included for topic targets, each message carries a replyAction tied to its feedback id, replies are optional, and community content is separated from the KG.

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 tight sentences, front-loaded with the core purpose before the response-shape and cost details. No filler, though the sentence about replyAction is arguably a return-value detail that the output schema already covers.

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 spelled out, and the description still covers target scoping, the optional-reply behavior, and the community-vs-KG boundary. It is complete enough to call correctly, with pagination already handled by the schema's limit/offset descriptions.

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 100%, so the schema already documents every parameter including the standalone-comment default for targetId/targetType. The description restates the entity/topic/section scoping and the topic-root behavior but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 (Read) and resource (public discussion threads) and scopes it to entity/topic/section targets. It partially differentiates from siblings by noting community content is separate from the KG, which distinguishes it from search_knowledge_graph and get_knowledge_entity, though it never names closer siblings like get_popular_feedback or list_community_feed.

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?

Usage is implied through 'Reading is free of search and LLM calls,' hinting this is the cheap way to read discussion, but there is no explicit when-to-use versus get_popular_feedback or list_community_feed guidance. No exclusions or alternatives are named.

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 already declare readOnlyHint, non-destructive, and closed-world behavior, but the description adds important operational boundaries: it does not search the knowledge graph, call an LLM, create a lead, or imply a recommendation. It also explains the optional feedback loop and feedbackAction usage, which goes beyond annotation content.

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 sentences, front-loaded with the core read operation and then the necessary boundaries and feedback condition. No filler or 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?

With an empty parameter schema and an output schema covering returns, the description supplies the operational context an agent needs: scope, non-actions, and feedback routing. Nothing material for correct invocation 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?

Zero parameters are defined, so the rubric baseline is 4. The description appropriately does not invent parameter detail where none exists.

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 (Read) and resource (machine-readable product catalogue), enumerates the key fields returned, and explicitly states what it is not (no KG search, no LLM call, no lead creation, no product recommendation), which clearly differentiates it from siblings like search_knowledge_graph and submit_business_inquiry.

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?

Provides clear when-to-use context as a read-only discovery call and names explicit exclusions. It also gives a conditional path to submit_agent_feedback only when substantive review finds a specific defect, making the alternative and trigger condition explicit.

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 already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context that topics live outside the KG and how to consume a topic id, but says nothing about pagination limits or sorting behavior beyond what the schema provides.

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 core purpose front-loaded and no filler. Every clause adds information.

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?

With an output schema present and annotations covering the read-only profile, the description supplies the one thing structured fields can't: the KG separation and the path to reading a thread. The main omission is disambiguation from sibling listing tools.

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 83%, so the schema already documents limit, offset, search, popular, category, and language. The description adds no parameter-level detail, so the baseline of 3 applies.

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 concrete verb and resource ('Discover ... public discussion topics') and clarifies scope ('user- and Agent-created'). It also distinguishes the resource from the knowledge graph, though it doesn't explicitly separate itself from nearby listing siblings like list_community_feed or get_popular_feedback.

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 description gives a follow-on workflow ('use list_feedback with targetType=topic and the returned topic id to read the thread'), which implies this tool is the discovery step. However, it offers no guidance on when to choose this over sibling lists such as list_community_feed or get_popular_feedback.

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 already disclose readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety bar is lower. The description adds genuine context beyond the annotations: the reply 'inherits the parent's target,' is 'labeled Agent,' and 'never changes the KG' — useful side-effect disclosure. It does not cover auth requirements or rate limits.

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 sentences, front-loaded with the action and scoped by a compact clause list. The clause list ('independent of search, inherits the parent's target...') is dense but each clause carries distinct information.

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?

With an output schema, full schema description coverage, and annotations present, the description supplies the remaining semantic essentials (optionality, Agent labeling, no KG mutation). Only the missing when-to-use guidance against siblings keeps it from a 5.

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 100%, so the schema documents all 7 parameters including required feedbackId and body. The description adds almost nothing parameter-specific ('free-form text' merely echoes the body schema), so the baseline 3 applies.

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 pairs a clear verb ('reply to') with a specific resource ('a public discussion'/'feedback') and clarifies scope ('inherits the parent's target, is labeled Agent'). It implicitly distinguishes itself from search-based siblings but never names a sibling like submit_agent_feedback or list_feedback, so an agent must infer the boundary.

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 the reply is 'optional' and 'independent of search,' which implies context, but gives no explicit when-to-use rule or when to prefer a sibling such as submit_agent_feedback. 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.

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

Annotations only say readOnlyHint=false and non-destructive. The description adds real behavioral context: writes stay outside the KG, do not trigger search or an LLM call, site suggestions earn contribution points, and posting is rate-limited by intent ('never post after every call'). It does not detail auth requirements or failure modes.

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 and scope are front-loaded in the first clause, and the dense single paragraph is mostly information-bearing rather than filler. It is on the long side for a feedback tool, with type definitions that partly restate the schema.

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?

With an output schema present, return values needn't be explained, and the description correctly points at feedbackAction instead. It covers selection, side effects, and quality bar; the main gap is that it never routes the agent between this tool and its closest sibling.

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 100%, so the baseline is 3. The description's enum guidance (missing/wrong_match/stale/site_suggestion vs useful/comment) largely duplicates the feedbackType schema description rather than adding new semantics about the other 9 parameters.

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 (submit an Agent-authored public observation) and clarifies scope beyond KG search, which is genuinely distinguishing. It does not, however, differentiate itself from the sibling submit_agent_observation, so an agent reading only the description cannot tell those two apart.

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 clear when-to-use mapping for each feedbackType and an explicit when-not ('Submit only when you have something specific; never fabricate or post after every call'), plus what an actionable report must contain. It stops short of naming sibling alternatives such as submit_agent_observation or reply_to_feedback.

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 declare readOnlyHint=false with destructiveHint=false, and the description usefully adds where the write lands ('outside the KG') and that it never triggers search. It also frames the call as optional, which matters for an agent that might otherwise call it defensively. Return behavior is covered by the output schema.

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, all load-bearing: the action, the side-effect location, and the when-not guard. The most important constraint (don't create observations unprompted) is front-loaded.

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?

With an output schema present, return values need not be described, and annotations plus the description cover the write/safety profile and usage conditions. What remains thin is parameter guidance, which the schema largely carries at 80% coverage.

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 80%, so the schema already documents taskId, observed, evidence, nextTest, testMode, and the rest. The description adds no parameter-level detail (e.g., expected taskId origin or evidence format) beyond what the schema provides, so the baseline of 3 applies.

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 (submit) and resource (page-grounded observation for a verification task) and scopes it by noting it 'writes outside the KG and never triggers search,' which separates it from search_knowledge_graph and KG-write siblings. It does not explicitly distinguish itself from submit_agent_feedback, so it falls short of full sibling differentiation.

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 clear context ('for a verification task you chose to perform') and an explicit exclusion ('do not create a task or observation just because a client initialized'). It implies the task must come from get_agent_task but never names an alternative tool, so it stops short of a 5.

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 declare readOnlyHint=false and openWorldHint=true, so the write/external nature is already known. The description adds real value beyond that: it clarifies the data use is reply-only, that consent and userAuthorized must be true, and that the result is a stored lead rather than a purchase or confirmed customer.

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 authorization requirement, then the required fields, then the lead-vs-customer clarification. Dense but every sentence carries a distinct constraint; only the repeated 'explicitly' framing adds minor 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?

An output schema exists, so return values need not be described. For a high-stakes external write with authorization semantics, the description covers the prerequisites, the data-use limitation, and the nature of the stored artifact — everything an agent needs to avoid mis-invoking 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?

Schema coverage is 50% and the description compensates by naming the required inputs (contact method, selected product, concrete problem of at least 20 characters, consent=true, userAuthorized=true) and tying consent to the stated data-use agreement. It does not cover the optional name/company fields or the enum values for interest, but the critical gating parameters are explained.

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 ('Submit a private inquiry') and immediately scopes it to Zhiyong and a specific product. Distinguishable from siblings like submit_agent_feedback and submit_agent_observation, which are agent-initiated rather than human-authorized.

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 the precondition (human user explicitly asks and agrees to reply-only data use) and enumerates the false-positive conditions to avoid: browsing, Agent/MCP discovery, search, tool initialization. This is a textbook when/when-not statement.

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