Manto — 馒头新闻

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

With no annotations, the description carries the full burden. It does disclose two useful traits — the account is passwordless and an API key is issued — but omits what happens on a duplicate email, whether the key is one-time-only or regenerable, and any rate limit or verification-email side effect.

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 front-loaded sentence with no padding; the action and its outcome come first. The trailing "once" is slightly ambiguous but costs little.

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 one-parameter creation tool with no annotations and no output schema, the description covers the action and the key outcome, which is enough to attempt a call. It still leaves duplicate-account behavior and confirmation/verification flow unstated.

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 the single required parameter, so the description must compensate. It says nothing about the email's semantics — format, uniqueness constraints, whether it must be a real deliverable address, or whether it is used as the account identifier.

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+resource ("Create a ... account") and adds two distinguishing traits: passwordless auth and that an API key is returned. This clearly separates it from read siblings like get_account and lookup_account, though it 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 guidance on when to use this versus get_account/lookup_account, nor any precondition (e.g., whether the email must be unused). Usage is only weakly implied by the verb "Create".

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 burden. It does not state whether this is a write operation (though 'Create' implies mutation), whether it requires authentication, whether it is idempotent, what happens on failure, or any rate limits. With zero annotation coverage, this is a significant 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?

The description is a single, efficient sentence with no wasted words. It is front-loaded with the action and resource. However, it is arguably too terse given the lack of other 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?

For a mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It should specify authentication needs, return value, or side effects. Nothing beyond the basic action is provided.

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 schema provides only parameter names and types. The description mentions 'account email' which maps to the email parameter, but it does not explain amount_cents (e.g., currency, minimum, maximum) or the format of email. It adds minimal meaning 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 states a clear verb+resource ('Create a recharge order') and adds a scope constraint ('for an existing account email'), which distinguishes it from create_account. It is somewhat clear but does not differentiate strongly from the sibling get_recharge.

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 guidance or mention of alternatives. The phrase 'for an existing account email' implies a prerequisite (account must exist), but it does not spell out when to choose this tool over get_recharge.

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. 'Get' implies a read, but it says nothing about authentication requirements, whether the account is resolved from the caller's credentials (no parameters exist, so this is the only possible mechanism), how far back 'recent content' reaches, or pagination/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?

A single short sentence with no filler, front-loaded on the verb and resource with the returned data enumerated compactly. Nothing is wasted or buried.

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 and no annotations, so the description must carry the full context for a tool that returns structured account data. It names the four returned categories, which is helpful, but leaves the scope of 'recent content' and the implicit credential-based account resolution unexplained.

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 there is nothing for the description to disambiguate at the parameter level; the baseline for a 0-param tool applies. The description does not need to add argument detail, and it instead names the returned fields.

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 (Get) and resource (account) and enumerates the returned fields: quota, balance, account score, recent content. It is clear what the tool does, but it gives no differentiation from the confusingly similar sibling lookup_account or from list_account_articles, which an agent could easily mistake for the content-returning 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?

There is no statement of when to use this tool versus lookup_account, list_account_articles, or the recharge getters in the sibling set. The description implies a general account-summary fetch but offers no context, prerequisites, or exclusions to guide selection.

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 provided, the description carries the full burden of behavioral disclosure, but it says nothing about effects, prerequisites, error behavior, or return format. The verb "get" only weakly implies read-only behavior, and no other behavioral traits are disclosed.

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 exceptionally short, but this is under-specification rather than appropriate conciseness. It lacks the substance expected of a tool description, and its brevity deprives the agent of needed information, so the minimalism is a deficit, not a virtue.

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 tool with one required parameter, no output schema, and no annotations, the description is severely incomplete. It does not explain what 'recharge status' means, what the response will contain, what constitutes a valid recharge, or any edge cases. An agent cannot reliably invoke or interpret results from this definition.

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%, and the description adds no meaning to the recharge_id parameter. It does not specify the format, how to obtain the ID, allowed values, or any relationship to other resources, leaving the agent without essential context for a required parameter.

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 "Get recharge status" uses a specific verb (get) and resource (recharge status), clearly identifying the operation. It distinguishes itself from siblings like create_recharge and get_account through the explicit focus on status retrieval, though it is somewhat terse.

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. No sibling tools are referenced, no conditions or exclusions are provided, and the agent is left to infer use cases entirely from the name and description.

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 present, the description carries the full behavioral burden. It adds a useful behavioral detail: no API key is required. However, it does not mention pagination, response shape, rate limits, or what happens with accounts that have no articles.

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 extremely concise, with no filler words. It front-loads the core purpose and adds one important auth detail in a single short sentence.

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 tool with no annotations, no output schema, and no parameter descriptions, this description is incomplete. It gives the basic purpose but leaves key invocation details, parameter meanings, and behavioral expectations unspecified.

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 the undocumented parameters. It does not explain limit or include_content, and only weakly implies account_id through the phrase 'an account's.' This is a significant gap for a 3-parameter tool.

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 a specific verb and resource: listing an account's published articles. It is more specific than sibling tools like get_account or publish, though it does not explicitly differentiate itself from the search or lookup 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 implies the tool is for retrieving published articles for a given account, but it provides no explicit guidance on when to prefer this tool over alternatives like search or lookup_account. There are no stated exclusions or alternative routing instructions.

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 burden of behavioral disclosure. It does disclose a key trait: 'no API key required', meaning authentication is not needed. However, it does not describe the return value, error handling, or confirm that the operation is read-only beyond the verb 'look up'.

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 entire description is one compact, front-loaded sentence with no filler: 'Look up a public account by email; no API key required'. Every word earns its place and the most important information appears first.

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 is simple, but with no output schema and no annotations, the description should state what the lookup returns and what happens if the account is not found. It covers purpose, parameter, and auth, but the absence of return/error semantics leaves a meaningful gap for an agent deciding how to use the result.

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?

With schema description coverage at 0%, the description compensates by specifying that the lookup is 'by email', giving clear functional meaning to the sole email parameter. For a single-parameter tool, this is sufficient semantic context.

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 ('Look up'), a specific resource ('public account'), and the lookup key ('by email'). It also includes a distinguishing qualifier ('public') that separates it from sibling get_account, and the auth note ('no API key required') further differentiates it from likely authenticated alternatives.

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 implies when to use the tool: to look up a public account by email without needing an API key. However, it does not explicitly state when not to use it or name alternatives such as get_account, leaving the routing decision somewhat implicit.

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 provided, the description carries the full burden. It does disclose one important behavioral trait—'idempotently update'—which signals that repeated calls with the same identity are safe. However, it omits other behavioral details such as whether external_id is the idempotency key, how expiration works, or what auth or content constraints apply.

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 concise sentence with no filler. It front-loads the core action and the idempotency property. However, it is so terse that it sacrifices valuable operational detail.

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 tool with five parameters, no output schema, and no annotations, this description is far too thin. It does not clarify parameter semantics, idempotency key usage, URL behavior, expiration format, or return expectations, so an agent lacks enough context 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?

Schema description coverage is 0%, so the description must compensate, but it does not explain any of the five parameters. The terms title, content, url, expires_at, and external_id are left entirely to name inference, which is insufficient for correct invocation.

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 clear verb and resource: it creates or updates content. The word 'idempotently' adds a meaningful behavioral distinction, but 'content' is somewhat generic and doesn't explicitly distinguish this from sibling tools like list_account_articles or set_promotion.

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 no guidance on when to use this tool versus alternatives such as remove_content or search. There are no prerequisites, no typical scenarios, and no exclusions, leaving the agent to infer usage context entirely.

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 ownership scope, but does not state irreversibility, required permissions, side effects, or whether confirmation is needed for this destructive operation.

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, front-loaded sentence with no wasted words. It is efficient, though slightly terse given the lack of supporting detail.

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 destructive single-parameter tool with no annotations, no output schema, and 0% schema coverage, the description is too thin. It omits parameter semantics and key deletion behavior such as reversibility or permissions.

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% and the description does not explain the sole parameter content_id beyond its self-evident name. It adds no format, constraints, or meaning beyond what the bare schema provides.

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 ('Remove') and resource ('content') with ownership scope ('owned by the authenticated account'). It does not explicitly distinguish itself from siblings, but no sibling performs deletion, so the purpose is clear enough.

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 no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. Deletion is implied by 'Remove', but context for choosing it is absent.

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. It discloses one useful trait – sponsored and organic results are returned separately – but says nothing about pagination, rate limits, auth requirements, or result ordering.

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 front-loaded sentence with no filler; the result-shape detail is appended efficiently. It is terse but not padded.

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 four-parameter tool with no annotations, no output schema, and 0% parameter documentation, the description leaves too much unspecified. The agent cannot tell how to shape query filters or interpret the two result streams.

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% across four parameters (query, limit, since, include_content), and the description adds no meaning for any of them. There is no hint of format for 'since', units for 'limit', or what 'include_content' toggles.

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 (Search) and resource scope (published news and messages), and adds a distinguishing detail that sponsored and organic results come back separately. No sibling tool is a competing search, so sibling differentiation is moot; the purpose itself is unambiguous.

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 statement of when to use this tool versus alternatives such as lookup_account or list_account_articles, and no prerequisites or context. Usage is only implied by the verb 'Search'.

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. It does disclose one genuinely useful non-obvious behavior — a zero budget pauses the promotion — but says nothing about whether this creates or overwrites an existing budget, what permissions are required, or whether the change is reversible.

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 tight sentence with the core action front-loaded and no filler. The semicolon clause packs in the zero-budget behavior efficiently, though the density means the content_id parameter never gets addressed.

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 two-parameter mutation tool with no annotations and no output schema, the description is thin: no success/return behavior, no permission requirements, no statement of what happens to the prior budget. The zero-pauses detail is the only behavioral context offered.

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 usefully clarifies that daily_budget_cents is in cents and that zero has a special pausing meaning, but content_id is left entirely unexplained in both schema and description.

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 ('Set') and resource ('daily promotion budget'), plus the unit (cents). It is unambiguous what the tool does, though it offers no explicit differentiation from siblings — acceptable here since the sibling list contains no other promotion tool.

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 when-to-use guidance, no prerequisite or permission context, and no named alternative. The agent can infer the tool sets a budget, but nothing tells it when this is the right call versus, say, a content publish flow.

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