Vaneform

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

With no annotations, the description carries the full burden and does well: it discloses the cost model ('1 credit per compared domain with data'), tier limits (3 Free / 30 Pro), and a fallback behavior ('fetches traffic when monthly visits are missing'). It stops short of describing failure modes or full return structure.

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

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

Five short sentences, front-loaded with purpose, then output, then cost and limits. Efficient with no filler, though the trailing 'Use for 批量对比' is redundant with the tool name.

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 tool with no annotations and no output schema, the description supplies the essentials an agent needs: cost, tier caps, and a partial return description ('scale and registry'). Exact fields of the comparison result remain 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 100% for the single 'q' parameter, so the comma/newline delimiter syntax and de-duplication rule are already documented in the schema. The description adds no format detail beyond that, 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 and resource ('Compare domains side by side') and hints at output ('Returns scale and registry'). It does not explicitly distinguish itself from the sibling compare_tld, so an agent must infer the domain-vs-TLD split.

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?

'Use for 批量对比' merely restates the tool name (bulk compare) rather than giving when-to-use conditions. It never mentions compare_tld or any alternative, and gives no exclusions despite the Free/Pro domain caps creating a clear selection boundary.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses side effects (fetches traffic when monthly visits are missing) and cost (1 credit per compared domain with data). It doesn't mention auth requirements or failure modes, but the credit and traffic-fetch disclosures are meaningful 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 key constraints are front-loaded, but the text is fragmented into short clauses and the trailing 'Use for 后缀对比' adds no information and mixes languages, which is dead weight.

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 should fully explain the return. It explains the response ordering ('fixed suffix order') but not the item shape or fields, leaving the return format only partially specified for an agent that must interpret results.

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 both parameters are already documented. The description adds the default suffix set and the input normalization rule, but these largely duplicate what the schema already states, 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 and resource: 'Compare the same registrable name across suffixes.' Clear what it does. It does not, however, differentiate itself from the sibling compare_bulk, leaving the agent to infer the distinction (one name vs many).

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?

'Use for 后缀对比' is the only usage cue and merely restates the purpose in another language. There is no when-not guidance, no prerequisites, and no routing to compare_bulk or lookup_domain for 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?

With no annotations provided, the description carries the full burden. It does disclose two useful behavioral facts: the operation is a read, and it consumes zero credits/allowance. It does not mention authentication requirements, rate limits, or what happens on failure, so the behavioral picture is partial.

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

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

Two short sentences, no filler. The most decision-relevant facts (what is read, its cost) are front-loaded, with the usage cue last.

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?

This is a trivial zero-parameter read with no output schema and no annotations. The description names the returned fields and the cost, which is enough for an agent to call it correctly; only permission/auth behavior is left 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?

The tool takes zero parameters, so there is no parameter semantics to convey and the schema cannot be improved upon by prose. Per the zero-parameter baseline, a 4 is appropriate.

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?

It states a specific verb (Read) and enumerates exactly what is returned: caller plan, website lookup allowance, and credit balance. This is plainly distinct from sibling tools like lookup_domain or compare_tld, so an agent can select it without opening a schema.

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?

"Use before a batch" gives a concrete triggering context for invoking the tool, and "This call spends 0" tells the agent it is cost-free to call. It stops short of naming alternatives or stating an explicit when-not-to-use condition, but for an account-status read there are effectively no competing siblings of the same kind.

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, and it does disclose two genuinely useful traits beyond structured fields: the call is free (0 credits) and account scoping comes from the authenticated key (so no account parameter is needed). However, it says nothing about the shape of the returned data, pagination, or whether the read is cached/live, which matters since there is no 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?

Two tight sentences, front-loaded with the action and the returned resources, followed by cost and auth context. The resource list is long but every item is informative rather than 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 zero-parameter read tool with no annotations and no output schema, the description does the important work: it enumerates what data comes back (standing in for the missing return schema) and clarifies cost and auth scoping. Only the response structure/paging details are left open, which is a minor gap at this complexity.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter surface for the description to explain or for the schema to leave undocumented. The note that account ownership derives from the authenticated key correctly signals that no scope argument 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?

The description opens with a specific verb ('Read') and then enumerates the exact resources returned: saved research, folders, private notes, tool history, publisher/ad monitors, and in-app notifications. That is far more specific than a tautology, though it never names a sibling (e.g. manage_research or save_research) to distinguish itself from adjacent 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?

There is no explicit when-to-use guidance and no routing to alternatives; an agent must infer from 'Read the caller saved research' that this is the workspace-overview tool rather than one of the many lookup_/compare_/manage_research siblings. No prerequisites or exclusions are stated.

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

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

With no annotations, the description carries the full burden and does so richly: it discloses the cache-only nature, the crucial semantic that status=missing means 'not cached' rather than zero traffic, the Pro-only gating of include=search, and precise credit costs (1, 10, or 0) tied to saved-ranking status. These are exactly the behavioral traits an agent needs and none are recoverable from structured fields.

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 core purpose, then options, cache semantics, triggers, and cost in a logical order. It is dense and the final credit sentence is somewhat convoluted, but nearly every clause carries information an agent needs.

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 no output schema and no annotations, the description must compensate, and it largely does: it enumerates the returned data families, explains cache/status semantics, and covers cost and access tier. Only the exact per-status response shape is left implicit, a minor gap for a cached-lookup tool.

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 already 100%, so the baseline is 3. The description still adds value by expanding what include=baidu and include=search actually return (ranked keywords, landing pages, competitors) and by tying include=search to credit spend, going beyond the schema's terse 'Pro-only' note.

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?

Opens with a specific verb and resource ('Read a cached Vaneform domain snapshot') and enumerates exactly what comes back (scale visits, registry, site profile, link-rank popularity). The 'cached' qualifier implicitly separates it from live-research siblings like research_site, so an agent can place it without opening a schema.

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 a concrete trigger list ('Use for 查网站, 访问量, how big a site is, domain visits, registry age, backlink rank, 百度权重, 关键词排名'), which maps task intent to this tool well. It does not, however, name an alternative or state when NOT to use it (e.g., versus research_site or compare_bulk), leaving the routing decision partly 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?

With no annotations, the description carries the full burden and does so well: it discloses the Pro-only plan requirement, the 30-result cap, the caching economics (free cache hit vs. 60 credits on a successful miss), and the matching/validation rules. These are exactly the operational facts an agent needs before invoking a metered lookup.

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 and the behavioral facts follow in dense, information-bearing sentences. It loses a point for the redundant trailing 'Use for 关键词查询' and for restating the 200-character trimming rule that already appears in 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?

For a one-parameter read tool with no output schema or annotations, the description covers cost, limits, scope, and input validation adequately. Minor gaps remain around error behavior and whether the brief structure differs from the listed fields, but nothing critical to 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?

Schema coverage is 100% for the single parameter, and the description's trimming and 80-character matching notes duplicate what the schema already states. Baseline 3 is appropriate since the schema does the heavy lifting and the description adds no new parameter meaning.

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 verb and resource ('Read a US/EN keyword brief') and enumerates the returned fields (monthly searches, difficulty, CPC, Google occupancy), which clearly separates it from lookup_domain and the compare_* tools. There is no explicit sibling routing statement, but the resource identity makes the distinction obvious.

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 context is implied through scope constraints: US/EN only and Pro-only, which tell the agent when the tool is applicable. However, 'Use for 关键词查询' is a tautological restatement of the tool name rather than guidance, and no alternatives or when-not conditions 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?

With no annotations, the description carries the full burden. It usefully discloses cost ('Free; 0 credits') and that the caller's private research is the scope, and the action names imply mutating operations. It does not state whether removals are irreversible, what permissions are required, or what side effects result, leaving meaningful behavioral gaps.

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: the operation list is front-loaded and the practical details (ID source, cost) follow. No filler or 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 five-action, four-parameter tool with 0% schema coverage, no annotations, and no output schema, the description covers purpose, ID source, and cost but omits the per-action parameter requirements and any return or error behavior. Adequate to attempt a call, but not complete enough to call confidently for every action.

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 four parameters, so the description must compensate. It partially does: 'pause/resume' hints at the 'active' boolean and 'daily/weekly' hints at interval_days values 1/7, and it explains the 'id' source. It never states which optional parameter pairs with which action, leaving the action-to-parameter mapping ambiguous.

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 ('Manage') plus the resource ('the caller private research') and enumerates the five concrete operations, which map onto the action enum values. It is distinguishable from siblings like save_research and monitor_research, though it does not explicitly state how it differs from monitor_research.

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 a prerequisite ('Use IDs from get_research_workspace'), which is real usage guidance, and the action list implies when each operation applies. However, it never states when to pick this tool over monitor_research or save_research, nor any exclusions, so guidance remains implied rather than 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?

With no annotations, the description carries the full burden. It usefully discloses that the first observation sets a baseline and that results arrive as private in-app notifications, plus the zero-cost fact. However it says nothing about auth requirements, rate limits, failure behavior, or what happens to the baseline on later runs.

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

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

Four short sentences, front-loaded with purpose and cadence, then behavior, then cost. Nothing is padded, though the baseline and notification points could be slightly tighter.

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 behavioral arc (baseline then notifications) is adequately conveyed and no output schema exists to explain. But with a nested 'query' object lacking any description and no annotations, an agent still lacks the structural detail needed to construct a valid call.

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 three required parameters, including a nested object 'query' with no structure defined anywhere. 'daily or weekly' loosely maps to the interval_days enum, but 'query' and 'label' are left entirely unexplained, so the description does not compensate for the coverage gap.

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 (monitor) and resource (Google Ads or AdSense query) with a clear cadence, and describes the concrete outcome (recording newly observed ads/sites as notifications). It is distinguishable from lookup/search siblings by its recurring nature, though it never names an alternative directly.

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 recurring 'daily or weekly' framing implies when the tool is appropriate versus a one-off lookup, but there is no explicit when-to-use/when-not statement and no sibling is named as the alternative. Usage must be inferred from the cadence wording.

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 must carry the behavioral load, and it does disclose several traits: zero credit cost, 'explicit and bounded' source acquisition, and that estimates retain dates/scope/confidence. It does not disclose pagination (cursor) behavior, permission/auth needs, or that the operation is read-only.

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?

It is reasonably front-loaded and dense, but the middle sentences ('Source acquisition is explicit and bounded', 'Ad text and Publisher ID reverse lookups cover the recorded collection') are jargon-heavy and add little actionable clarity for the space they consume.

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?

This is a high-complexity tool (11 params, two enums, required tool+q, no output schema, no annotations), and the description covers only the tool/data-source dimension. Pagination via cursor, the region enum, and the DR/visit/age range filters go entirely unexplained, leaving an agent under-equipped to invoke 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 coverage is 0% across 11 params, so the description must compensate. It does map the cryptic `tool` enum values to semantics (google-ads by domain/advertiser, meta-ads by keyword, adsense by publisher, outbound-links by page, ad-keywords, dr-growth/discovery), which is real added value, but the numeric filters (minDr/maxDr, minVisits/maxVisits, maxAgeMonths, limit, region, cursor) remain entirely undocumented.

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

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

The description names the resource (standalone site research) and enumerates the concrete data sources it queries — Google ads, Meta ads, AdSense, outbound links, DR changes — so an agent knows what the tool produces. It is clearly differentiated from lookup-style siblings by the 'standalone research' framing, though it never names a sibling directly.

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 repeated 'free / 0 credits / early-access' framing gives implied routing guidance (use this when you don't want to spend credits), and 'standalone' hints at it not requiring a workspace. But there is no explicit when-to-use-vs-alternatives statement against lookup_domain, compare_bulk, or get_research_workspace.

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 but does disclose two real behavioral facts: the save is free (0 credits) and the notes are private. It is silent on overwrite/duplicate behavior, auth requirements, and what a failed save does, which matters for a 4-required-param write tool.

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

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

Two short sentences, front-loaded with the action and scope, ending with the non-obvious cost fact. No filler or repetition of the field names.

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?

A mutation tool with no annotations, no output schema, and four parameters at 0% schema coverage needs more than one sentence of behavior. The agent still cannot tell what goes in the nested query object or how a saved item behaves afterward.

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 only implicitly touches 'folder' and 'notes' (privacy) plus 'query' as a site-tool query. The required 'label' is never mentioned, and the nested 'query' object's expected shape 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?

Specific verb+resource+scope: 'Save a standalone site-tool query in the caller workspace'. It also names the payload (folder, private notes), so an agent knows exactly what is stored. It does not explicitly contrast itself with manage_research or monitor_research, but the word 'standalone' gestures at the distinction.

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 statement or named alternative. The qualifier 'standalone' implicitly separates this from the managed-research siblings (manage_research, monitor_research), which is a usable but indirect signal.

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