mcp-buy123-vendor

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation2/5
Many tools have overlapping names and concepts, such as list_product_bundles vs list_bundles, list_items vs list_products, and multiple similar list_* endpoints for different resource types. An agent can easily confuse which list to call for a given purpose.
Naming Consistency4/5
The naming convention is mostly consistent with snake_case and verb_noun pattern (list_*, get_*, check_*). Minor exceptions like auth_status and vendor_login deviate slightly but remain readable and predictable.
Tool Count2/5
With 61 tools, the server is heavily over-scoped for most use cases. Many tools simply list enum values or static configurations, which bloats the tool surface and increases selection complexity.
Completeness2/5
The toolset is almost entirely read-only (list/get/check), lacking create, update, or delete operations for core entities like products, bundles, and vendors. This creates dead ends for management workflows and limits the server's practical utility.
Average 3.3/5 across 61 of 61 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only mentions the HTTP method GET, which implies read-only, but does not disclose pagination, filtering behavior, response format, or any potential limitations/side effects. The description is far too sparse to provide meaningful behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief ('退貨大表 (GET /v1/returns)'), but this is under-specification rather than effective conciseness. It omits essential information about the tool's behavior, usage context, and response characteristics. Every word should earn its place, but here the phrase is too minimal to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 optional filter parameters and no output schema, the description is entirely inadequate. It does not explain what the return table contains, how results are paginated, what types of return records are included, or any other contextual information. The description makes no effort to compensate for the lack of an output schema or elaborate on the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema itself documents all 7 parameters adequately. The description adds no additional parameter meaning beyond what the schema already provides. Therefore, the baseline score of 3 is appropriate; the description neither enhances nor detracts from parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '退貨大表 (GET /v1/returns)' is essentially a noun phrase that restates the tool name ('returns big table') and provides the endpoint. It lacks a clear verb indicating the operation (e.g., 'list', 'retrieve'), making it more of a label than a purpose statement. It does not distinguish the tool from sibling list_* tools beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no context, and no exclusions. It simply names the endpoint. There is no mention of use cases, prerequisites, or alternative tools for different return types or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits such as return value format, side effects, or required permissions. It merely states the HTTP method and resource, offering zero insight into what the tool returns or any side effects. For a GET endpoint, it doesn't even confirm it is read-only or what the response structure looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence. However, it under-specifies the tool's behavior. While conciseness is achieved, the sentence doesn't earn its place because it merely repeats the tool name. It is short but not informative enough, making it borderline between appropriate brevity and under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, no output schema), but the description still fails to explain what the returned vendor return address looks like or any other relevant context. Since there is no output schema, the description should at least indicate the response content, but it does not. Contextual completeness is lacking, leaving the agent without essential information for interpreting the tool's result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered. Per the rubric baseline, a tool with no parameters receives a 4. The description does not need to elaborate on parameters since there are none, though it also doesn't add any context about the response.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '取得廠商退貨地址' directly restates the tool name 'get_vendor_return_address' without adding meaningful clarification. It includes the endpoint path, but that merely translates the name into an HTTP route. There is no differentiation from sibling tools like get_vendor or get_vendor_profile, and the purpose is essentially the same as the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of context, exclusions, or related tools. The description is purely a restatement of the action and does not help the agent decide between this and sibling list/get tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior, but it only states that the tool lists details. It does not mention whether it is read-only, requires specific permissions, or how results are returned. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase with the endpoint, which is concise but provides minimal added value beyond the tool name. It is not overly verbose, but it lacks structure and additional context that would make it more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the simplicity of the tool, the description should at least mention that it returns a list of shipment details and any relevant usage context. It does neither, leaving the agent with insufficient information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as all five parameters have descriptions in the input schema. The tool description adds no parameter information, but per baseline, the schema already documents these adequately, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '宅配出貨明細列表' translates to 'home delivery shipment details list', which restates the tool name without adding distinctive meaning. It does include the API endpoint, which provides some specificity, but it does not differentiate this tool from siblings like list_shipments or list_cvs_shipment_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as list_shipments or list_cvs_shipment_details. The description provides no context for selection, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It only states the endpoint and operation (GET list), implying read-only behavior but not explicitly stating safety, authentication requirements, pagination behavior, or any side effects. This leaves major gaps for an agent assessing safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (a title and endpoint), but it is under-specified rather than appropriately concise. It lacks any explanatory content that would help an agent understand scope, behavior, or usage. Minimal length without useful content does not earn high marks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description must provide substantial context but offers only the tool name and endpoint. It fails to explain what a channel product is, what filtering or sorting options exist, or what the response contains, making it inadequate for safe/effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter has a description. The tool description itself adds no extra parameter meaning, but per the baseline rule for high coverage, a score of 3 is appropriate. No contradictions or ambiguities in parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists channel products ('渠道商品列表') with a specific endpoint (GET /v1/channel-products). It distinguishes itself from sibling tools like list_products by focusing on channel-specific products, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information about when to use this tool versus alternatives. Sibling tools include other list operations (e.g., list_products, list_bundle_items) but no guidance or exclusions are provided. The description only names the resource, leaving usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only discloses that it is a GET request, implying read-only, but does not mention pagination, filtering behavior, access requirements, or any other side effects. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, essentially restating the tool name in Chinese and adding the endpoint. It is under-specified rather than effectively concise, omitting essential usage and behavioral context. Every word should earn its place, and here they do not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, no annotations, and no output schema, the description is far too minimal. It does not explain the return value, pagination, required parameters, or how this list relates to other shipment tools. The single sentence is insufficient for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 9 parameters have meaningful descriptions in the schema. The tool description adds no parameter information, but the schema already documents each parameter, including a note that delivery_type values reference list_delivery_types. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '廠商出貨列表 (GET /v1/shipments)' clearly states the tool lists vendor shipments. It provides a specific verb and resource, but does not explicitly differentiate it from sibling tools like list_cvs_shipment_details or list_home_delivery_shipment_details, which could be more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It only states the endpoint without any context on appropriate use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior, but it only provides a label and endpoint. It does not describe the return format, pagination behavior, filtering semantics, or any side effects, leaving the agent without critical 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded with the key resource. While it is terse and doesn't waste words, its brevity limits clarity, but for conciseness it earns a solid score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 optional parameters, no output schema, and no annotations, the one-sentence description is insufficient. It fails to explain the return format, typical usage patterns, pagination defaults, or relationships to sibling tools, leaving significant contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete descriptions for all 8 parameters (coverage 100%), so the description does not repeat parameter details. The description itself adds no additional parameter semantics beyond what the schema already provides, aligning with the baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '超商未取退回大表' clearly identifies the resource as uncollected CVS returns and includes the endpoint, making the tool's purpose reasonably clear. However, it lacks an explicit verb and does not differentiate from siblings like list_returns, so it doesn't achieve full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_returns or list_cvs_shipment_details. There's no mention of typical use cases, exclusions, or context that would help an agent choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only names the endpoint and 'get' operation but does not mention authentication requirements, return structure, side effects, or error behavior. This is insufficient for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the function and endpoint. No wasted words or fluff; it earns its place by providing the essential identity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description should explain what the tool returns or any prerequisites. It does not mention the response format (e.g., menu items structure) or whether authentication is required. The description is too thin to be considered complete for a tool with no supplementary structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'mock' parameter is described as '是否為測試 (1 = 測試資料)'). The tool description itself adds no parameter information, but the schema is self-sufficient, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '取得供應商使用者選單' (Get supplier user menu) and includes the exact endpoint 'GET /v1/auth/me/menu'. The verb+resource pattern distinguishes it from sibling tools, and the endpoint adds useful precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description only states the function and endpoint; it does not mention prerequisites, typical scenarios, or exclusions. Usage context is only implied by the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'list', offering no details about pagination, filtering behavior, return format, or side effects. The description carries the full burden but fails to disclose any behavioral traits beyond the obvious read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, which is efficient. It could arguably be too minimal, but it earns its place by stating the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 optional parameters, no output schema, and no annotations, a one-line description is insufficient. It doesn't explain what constitutes an 'abnormal order', return conventions, or default filter behavior, so the agent lacks context to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 7 parameters, so the baseline is 3. The description adds no parameter information, but the schema already handles it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists abnormal orders and provides the HTTP endpoint, making the purpose specific. However, it does not add any additional scope or differentiate from sibling list_* tools beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_returns or list_shipments, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral disclosure burden. It only reveals that this is a GET (read) operation, but does not discuss response format, pagination, required permissions, or the effect of the optional bundle_version parameter. This is insufficient for a tool with no other behavioral metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently communicates the verb, resource, and endpoint, making it maximally concise while still being informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description is too sparse. It does not explain what the returned list contains, how to handle pagination, or how the bundle_version parameter affects results. The agent is left with significant ambiguity about the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for both parameters (bundle_id: '方案 ID', bundle_version: '方案版本'), so the schema already explains their meanings. The description adds no extra parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation using the verb '取得' (get) and the resource '方案商品選項列表' (bundle item options list), and includes the exact endpoint. This distinguishes it as a list operation, but it does not explicitly differentiate from sibling tools like get_bundle_item or list_item_options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is present. The description only defines what the tool does, without mentioning when to use it versus alternatives, prerequisites, or scenarios where it should be avoided. The agent must infer usage from the endpoint and parameter names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It does disclose that this is a GET request, implying a read-only operation, but it does not mention pagination behavior, return format, error conditions, authentication requirements, or any side effects. The description is too sparse to provide meaningful transparency beyond the basic HTTP method.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and the endpoint. It wastes no words and is immediately understandable. The brevity is appropriate for a simple list operation, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a clear purpose, the description lacks important contextual details. There is no output schema, so the description should explain the return structure (e.g., paginated list, fields returned), but it does not. It also does not mention pagination or sorting capabilities, even though the schema includes such parameters. Given the complexity of the schema (6 optional parameters) and the absence of an output schema, the description is incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with each of the 6 parameters already having descriptive text in the schema. The tool description itself adds no additional parameter semantics or context beyond what the schema provides. According to the rubric, this baseline score of 3 is appropriate when the schema handles parameter documentation comprehensively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to retrieve a list of product bundles (取得商品方案列表) and provides the API endpoint (GET /v1/bundles). However, it does not distinguish itself from the sibling tool 'list_product_bundles', which likely has a similar purpose. The verb 'get' and resource 'bundles' are specific, but the lack of differentiation from siblings prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternative sibling tools such as 'list_product_bundles' or 'get_bundle'. There is no mention of use cases, prerequisites, or scenarios where this tool is preferred. The only implied usage is 'when you need a list of bundles,' which is not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for transparency. It only discloses the HTTP method (GET), which implies read-only behavior, but nothing about permissions, pagination, response structure, or side effects. This is minimal and insufficient for a tool with no external metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single phrase with an endpoint reference. It is front-loaded and contains no fluff, which earns it a high conciseness score. However, it is also under-specified, so it doesn't reach a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 optional parameters, no output schema, and no annotations, the description is insufficient for an agent to understand filtering capabilities, return values, or when to call this over siblings. The one-line description does not provide enough context for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and every parameter already has a description in the input schema (e.g., page, size, status, sort_field). The tool description adds no additional parameter semantics, but the schema does the heavy lifting, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '渠道列表' clearly means 'channel list', and the endpoint GET /v1/channels reinforces the resource and action. It is specific in identifying the tool's purpose, but it does not distinguish it from sibling tools like list_channel_products or list_pricing_channels, so it isn't a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other list_* tools. There is no mention of authentication, prerequisites, or typical use cases, leaving the agent to infer entirely from the name and endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only indicates a GET endpoint, which implies a read-only operation, but provides no details on response structure, pagination, hierarchy, or any potential side effects. This falls short of the transparency expected without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the tool's purpose and endpoint. It contains no fluff and is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a minimal description. It does not explain what the response looks like, how the optional parameters affect results, or when this tool is appropriate. For a list tool with sibling alternatives, this is insufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters (layer, limit, parent_id). The description adds no additional parameter meaning, so a baseline score of 3 is appropriate since the schema already documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a commodity category menu (取得商品類別選單) and provides the exact endpoint (GET /v1/vendors/commodities/categories). The verb and resource are specific, but it does not explicitly differentiate from sibling tools like list_vendor_categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention any context, exclusions, or related tools. The agent is left to infer usage solely from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the HTTP method GET, implying a read-only operation, but adds no information about pagination behavior, response shape, filtering semantics, or potential edge cases. This is minimal disclosure beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the tool's purpose and endpoint. It is efficient with zero waste, though it could be slightly enhanced with usage guidance without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no annotations, no output schema), the description is too sparse. It does not explain return format, pagination behavior, or how filters combine, leaving the operational context unclear despite the schema covering parameter definitions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 9 parameters are described in the schema with 100% coverage, so the baseline is 3. The description adds no additional parameter context, but the schema already provides complete meaning for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '超取出貨明細列表' (CVS shipment details list) with the endpoint GET /v1/shipments/cvs/details, clearly identifying the resource and operation. It does not explicitly distinguish from sibling list_home_delivery_shipment_details, but the tool name itself conveys the CVS vs home-delivery difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives like list_home_delivery_shipment_details, nor does it mention any prerequisites or contextual filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the endpoint and resource type without mentioning pagination, sorting, read-only guarantees, authentication requirements, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that includes the resource, action, and endpoint. It is front-loaded and contains no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the schema providing parameter details, the description omits important context such as the return format, pagination behavior, sorting semantics, or when this tool should be preferred over similar list tools. For a tool with 5 parameters and no output schema, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter (id, page, limit, sort_field, sort_order) already has a clear description. The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete action ('取得商品選項列表' - get item options list) and identifies the exact resource via the endpoint path. It is clear and distinct from siblings like list_item_options_selection and list_item_option_inventories, though it does not explicitly contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. Sibling tools such as list_item_options_selection or list_item_option_inventories likely overlap in scope, but the description does not clarify selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It only includes the HTTP method GET, which implies a read-only operation, but provides no other details such as authentication requirements, pagination, or side effects. This is minimal and insufficient for a tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the purpose and endpoint without any redundant words. It is front-loaded with the key action and resource, making it efficient and well-structured for a simple GET list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema/annotations, the description is under-specified. It does not explain what 'options selection' means in relation to the item, what fields the list contains, or how the keyword filter behaves. This leaves an agent with insufficient context to use the tool correctly without further exploration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two parameters (id and keyword), and the schema already includes meaningful descriptions (e.g., keyword filters by product name or vendor SKU). The tool description itself adds no extra parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose clearly: '取得商品選項選擇列表' (Get product option selection list) with the explicit HTTP endpoint. It identifies the verb (get) and resource (product options selection list), but does not differentiate it from sibling tools like list_item_options or list_item_selection, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_item_options or list_item_selection. No scenarios, exclusions, or alternative mentions are given, leaving usage entirely implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only notes the HTTP GET method, which implicitly suggests read-only behavior but does not state it. It also fails to mention pagination behavior, filtering semantics, return format, or any side effects. This is comparable to the 'update_drive' example where a mutation with no annotations scored 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line with no wasted words. It states the action and the endpoint in a compact form. There is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively complex with 9 optional parameters and many sibling list tools, yet the description is minimal. It does not explain what distinguishes 'products' from related concepts like 'items' or 'bundles', nor does it describe any return value structure (no output schema). This leaves significant gaps for an agent to correctly contextualize and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for parameter descriptions, so the baseline is 3. The description itself adds no parameter information, but the schema already documents each param with terse descriptions like '頁碼 (1-based)' and '排序欄位'. No additional meaning is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '取得商品列表' (Get product list) and includes the endpoint 'GET /v1/products', which identifies the tool's purpose as a specific verb+resource. However, it does not distinguish this from sibling tools like list_items or list_product_bundles, which may also retrieve product-like data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name and the generic 'list' verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It only states the endpoint and a direct translation, without mentioning whether the operation is read-only, requires specific permissions, or returns any particular format. This is insufficient for safe tool selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one short phrase and the endpoint. It is front-loaded and contains no wasted words, which is appropriate for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits essential context that an agent needs to correctly select and invoke the tool. It does not explain what the returned data represents, how it relates to vendor roles and actions, or what makes it different from similar list tools. This is a minimal but inadequate description for a one-parameter list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter role_id with a Chinese label '角色 ID', so schema coverage is 100%. The description itself adds no additional parameter meaning, which aligns with the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource (get vendor role permissions) and includes the endpoint. However, it does not explicitly distinguish it from closely related siblings like list_vendor_actions or list_vendor_roles, so it lacks full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, which is a significant gap given the presence of many related vendor list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only mentions the endpoint and the fact that it lists roles, omitting details about pagination, authentication, ordering, or response format. The GET method and list wording imply a read-only query, but this is minimal and under-specified compared to what an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise line, front-loaded with the operation and endpoint. It avoids unnecessary detail, but is arguably too terse; however, it is appropriately sized for a simple list endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and annotations, so the description should compensate by explaining return values and behavioral nuances. It only states the endpoint and purpose, failing to mention how pagination works or what the response contains. This is incomplete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both page and limit having descriptions in Chinese ('頁碼 (1-based)' and '每頁筆數'). The tool description adds no additional parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '取得廠商角色列表' (Get vendor role list) and includes the endpoint GET /v1/vendors/roles, clearly indicating a specific verb and resource. However, it does not explicitly distinguish this tool from the many sibling list_* tools, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_vendor_users or list_vendor_actions. The description simply names the operation, leaving the agent to infer usage solely from the tool name and endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It only mentions the HTTP method (GET) and endpoint, implying a read operation, but does not disclose response format, pagination, authentication requirements, or any side effects. This is minimal and insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It communicates the core purpose immediately and is well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explain what the returned data contains or under what conditions this tool should be invoked. Given the large number of sibling list tools, this minimal description could lead to ambiguity or incorrect selection. It is minimally adequate for a simple list but lacks crucial context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (type and store_type) with clear descriptions, achieving 100% schema coverage. The tool description adds no additional parameter-level context, so the baseline score of 3 is appropriate; the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: obtaining convenience store pickup application data via a GET endpoint. It references a specific resource (vendor store pickups) with a clear verb, though it does not explicitly distinguish itself from sibling tools like 'get_vendor_store_pickup' or other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'list_uncollected_cvs_returns' or 'get_vendor_store_pickup'. There are no contextual cues, exclusions, or alternative recommendations, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It does indicate the HTTP method GET, implying a read-only operation, but fails to mention pagination, return format, authentication needs, or any other behavioral traits. This is minimal and insufficient for a tool with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with the endpoint in parentheses, making it extremely concise and free of redundant wording. It is well-structured for quick scanning, though it could arguably include more detail without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description leaves out essential context such as what the list returns, pagination behavior, or when to use this tool. The minimal description is insufficient for a complete understanding of the tool's operation and purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all 5 parameters, so the schema already documents each parameter. The description adds no additional parameter semantics, but per the rubric, the baseline is 3 when schema coverage is high, and the description does not degrade it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('取得' = get) and resource ('廠商使用者列表' = vendor user list), and includes the API endpoint 'GET /v1/vendors/users'. This is specific and unambiguous, though it does not explicitly differentiate from sibling list tools, the resource name itself is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other list_vendor_* or list_* tools. There is no mention of use cases, prerequisites, or scenarios where this tool should be preferred, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 indicates a read-only GET operation but does not mention authentication requirements, pagination, or what the returned list contains. Beyond the HTTP method, no meaningful behavioral 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the purpose and includes the endpoint. It is front-loaded and efficient, with no wasted words, though it lacks any additional structured detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations or output schema, the description is the sole source of context. It provides only a minimal restatement of the tool name plus an endpoint, failing to explain what a product status is, what the response looks like, or when this list is useful. It is inadequate for a tool within a large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is vacuously complete. According to the rubric, a baseline of 4 applies for 0-parameter tools. The description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of product statuses, with a specific verb and resource. It includes the endpoint, which adds precision. However, it does not explicitly differentiate from related sibling tools like list_event_product_statuses, so it does not fully meet the 'distinguishes from siblings' criterion for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any exclusions or recommended context. The description simply states the action without explaining scenarios or prerequisites, providing no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes the HTTP GET method, implying a read operation, but does not explicitly disclose side effects, authentication requirements, or other behavioral traits. With no annotations, the description carries the full burden but doesn't go beyond the method.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It is front-loaded and directly states the action and endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get with one parameter and no output schema, the description is minimally adequate but lacks details on the return value or any error conditions. It doesn't explain what the application object contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter with a clear description of valid values (711/fme). The description does not add additional semantics beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it retrieves vendor convenience store pickup application, with the API path providing additional specificity. It distinguishes from list_vendor_store_pickups by singular vs plural, but doesn't explicitly describe the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus list_vendor_store_pickups or other related tools. Lacks context about appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only repeats the tool's name and gives the HTTP endpoint. It implies a read operation via '獲取' and GET, but does not disclose idempotency, authentication needs, return format, or any side effects. With no annotations provided, the description fails to carry the behavioral disclosure burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and includes the endpoint URL. It avoids waste, though it lacks any additional structural or contextual value that could make it more helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the extreme simplicity (0 params, no output schema), the description is minimally adequate: it names the resource and the list operation. However, it does not describe the response structure or what a 'notify type' represents, leaving the agent without concrete expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed since there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '獲取公告通知類型列表' (Get announcement notification type list) with the endpoint, clearly identifying the resource and action. It is distinct from siblings like list_announcement_notify_levels and list_announcement_notify_scopes by specifying 'type', though it does not explicitly call out these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the sibling announcement list tools, nor any exclusions or alternative recommendations. The user must infer usage solely from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only mentions 'GET', which implies read-only behavior, but it does not disclose pagination behavior, default sorting, filtering scope, or any access requirements. The description adds minimal value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that includes the action and endpoint. No words are wasted, and it is front-loaded with the primary purpose. Despite being terse, it is appropriately concise for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully documents parameters, and the description provides a clear purpose and endpoint. However, there is no output schema or behavioral details, and the lack of differentiation from sibling tools leaves gaps in understanding what exactly this list returns and when to use it. It is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 8 parameters (e.g., 'upc', 'page', 'keyword'), resulting in 100% schema coverage. The description itself adds no parameter information, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a list operation for items with the Chinese phrase '取得商品列表' and includes the HTTP endpoint 'GET /v1/items'. However, it does not differentiate from sibling tools like list_products or list_item_selection, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description lacks any context about typical use cases, exclusions, or relationships to sibling tools, so an agent cannot decide between list_items and similar list functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the endpoint and does not disclose read-only behavior, authentication needs, pagination, return format, or data scoping. The GET method implies read-only operation but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that includes the resource and endpoint, making it appropriately sized and front-loaded. However, it is terse and omits valuable context, though no unnecessary words are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should indicate what the returned list contains, but it only says 'price list' without detailing fields, pagination, or filtering behavior. Given the 4 parameters, this is insufficient context for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented with descriptions. The tool description adds no extra meaning beyond identifying the endpoint variable product_id; it doesn't clarify usage semantics or relationship between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '取得' (get) and resource '商品方案渠道價錢列表' (product bundle channel price list), clearly indicating the tool lists bundle prices for a product and channel. The endpoint is provided, which distinguishes it from siblings like list_product_bundles (lists bundles) and list_pricing_channels (lists pricing channels).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as list_product_bundles or list_pricing_channels. No exclusions, prerequisites, or context for choosing this tool are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It discloses the HTTP method GET (via the endpoint), implying a read-only operation, but does not mention auth requirements, error behaviors, or response format. The description adds little beyond the function name and parameter schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence including the endpoint, front-loading the action and resource. No wasted words; every element contributes to identifying the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, yet the description does not mention what the response contains or any special behaviors. While the tool is simple, the description lacks essential context such as expected return structure or prerequisite conditions, making it incomplete for an agent to fully understand the invocation outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with bundle_id described as '方案 ID'. The description's '檢視指定方案' implies the parameter selects which bundle to view, but adds no detail beyond the schema. Baseline 3 is appropriate since the schema already fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states '檢視指定方案' (view specified bundle) with the REST endpoint GET /v1/bundles/{bundle_id}. This clearly identifies a specific verb (view) and resource (specified bundle), distinguishing it from sibling list_bundles (list all bundles) and get_bundle_item (view an item within a bundle).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention that this tool is for retrieving a single bundle by ID, nor does it exclude cases where list_bundles or get_bundle_item would be more appropriate. Usage must be inferred from the endpoint and parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. The explicit 'GET' method indicates a read-only operation with no side effects, which is useful. However, it does not mention authentication requirements, error conditions, or response contents, so transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that includes the tool's name, action, and endpoint. There is no redundant text or unnecessary detail, making it highly concise and efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should explain what the tool returns or any notable behaviors. It only states the HTTP endpoint and action, omitting response shape, error handling, or any prerequisites. This leaves the agent underinformed about the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since both parameters have descriptions, so the baseline is 3. The description adds value by showing product_id in the URL path, clarifying it is a path parameter, but it says nothing about the 'version' parameter, leaving its purpose solely to the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '取得商品' (get product) clearly identifies the specific resource and action, and the endpoint '/v1/products/{product_id}' reinforces that it retrieves a single product by ID. It is distinct from sibling list tools like list_products, but it does not explicitly name alternatives, so it loses one point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_products or get_item. The only implicit usage context is that the path includes a product_id, implying single-product retrieval, but there are no explicit when/when-not statements or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It implicitly indicates a read-only operation via the 'GET' method, but does not mention response format, error behavior, authentication needs, or any other side effects, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only a Chinese phrase and the endpoint. Every word is meaningful, and the structure is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is minimally adequate but lacks details about the return value (e.g., single object vs. list, fields included). With no output schema or annotations, the description could better clarify what the agent should expect after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and the schema contains no properties to elaborate on.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves vendor information using a GET request to /v1/vendors. It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like get_vendor_profile, which could cause some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description only states the action and endpoint, with no context about appropriate scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions the GET endpoint, implying a read-only operation, but does not state whether the tool returns a full profile, what fields are included, or any authentication requirements. The transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a short phrase and the endpoint. Every token is useful, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and no output schema, the description provides basic clarity but lacks detail on the response structure. The endpoint is helpful, but without an output schema or explanation of the data returned, the agent may not know what to expect from the result. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema has 100% coverage trivially. The description adds no parameter details because none exist. Baseline for 0 params is 4, and the description does not need to compensate for missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '取得廠商基本資料' (get vendor basic information) and includes the HTTP endpoint, giving a specific verb and resource. However, it does not differentiate from the sibling tool 'get_vendor', which likely also retrieves vendor information, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of alternatives. No prerequisites, exclusions, or context are provided, leaving the agent to infer usage based on the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It mentions the HTTP method GET, implying a read-only operation, but does not disclose any other traits such as authentication requirements, pagination, or response format. This is insufficient for an agent to fully understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that immediately conveys the tool's purpose and endpoint. It is front-loaded and contains no redundant or unrelated information, achieving high efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple, parameterless list endpoint, but it lacks details about the returned statuses or their semantics. Since there is no output schema, the agent has no information about the response structure, making the description minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter ambiguity. The baseline for 0-parameter tools is 4, and the description doesn't need to compensate. The endpoint further clarifies that no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of event product statuses (獲取活動商品狀態列表) and includes the specific endpoint. The verb 'get' and resource 'event product status' make the purpose distinct from sibling list tools, though it does not explicitly differentiate itself from similar list endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It only states the function and endpoint, with no exclusion criteria, prerequisites, or comparison to sibling tools like list_product_statuses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does reveal that this is a GET request (read-only), but it doesn't disclose auth requirements, return format, pagination, or any side effects. Basic behavior is transparent, but richer disclosure is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that includes both the purpose and the endpoint. There is no unnecessary text, and every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter list tool, the description is minimally sufficient but lacks context about the return structure or meanings of gross profit statuses, especially given no output schema. It clearly states the action and resource but doesn't fill in the gaps an agent might need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameters, and the empty schema already communicates the absence of inputs. The endpoint reference is a minor additive detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get gross profit status list' with the endpoint, using a specific verb and resource. It distinguishes the resource from other list_* tools, though it doesn't explicitly contrast with sibling tools. The inclusion of the HTTP method and path adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any use cases, prerequisites, or exclusions. For a simple list endpoint, the usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions the HTTP GET endpoint, which implies read-only, but does not elaborate on what history is included, pagination behavior, or any access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that includes the endpoint and purpose. It is concise and front-loaded, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters and no output schema or annotations, the description is too sparse. It does not explain what the history records represent, what the response structure is, or how the sorting/pagination parameters interact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters like id, page, limit, sort_field, sort_order have basic descriptions. The tool description does not add any additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves product history records with a specific verb and resource, and the endpoint clarifies the scope. It distinguishes from sibling tools like get_item by focusing on historical records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_item or list_product_versions. The description only states what the tool does without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the HTTP method (GET), implying a read-only operation, which is useful given the absence of annotations. However, it does not elaborate on pagination, filtering behavior, or response format, which is minimal but acceptable for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one brief, front-loaded sentence that states the endpoint and purpose. Every word is substantive, and there is no irrelevant or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 optional filter parameters and no output schema, the description is too sparse. It does not mention what kind of results are returned, pagination behavior, or typical use cases, leaving the agent without sufficient context for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all 10 parameters documented. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to retrieve a list of item option inventories, and it includes the HTTP endpoint. However, it does not explicitly differentiate this tool from sibling list tools beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any indication of prerequisites or context. The description simply restates the resource and endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only reveals the HTTP method (GET), which implicitly suggests a read-only operation, but it does not mention authentication needs, response format, or any side effects. This is minimal transparency for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential action and endpoint. No words are wasted, and the length is appropriate for a tool with no parameters and a straightforward purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite its brevity, the description is reasonably complete for a zero-parameter list endpoint. It states the purpose and the HTTP endpoint, which is sufficient for an agent to invoke the tool. There is no output schema to reference, but the return value (a list of banks) is implicitly clear from the tool name and description. Minor gaps remain around response structure, but the low complexity keeps the completeness score high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this. Per the rubric, 0 parameters earns a baseline of 4. The description adds no parameter-specific info because there are none to describe, so this baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('獲取' = get) and resource ('銀行列表' = bank list), clearly stating what the tool does. It includes the API endpoint for additional clarity. However, it does not explicitly differentiate this from sibling list tools, though the resource name itself provides implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It simply states the function and endpoint, with no mention of prerequisites, context, or exclusions. For a list tool, one might expect a note about typical use cases or relation to other list endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It only reveals that this is a GET request (read-only) via the endpoint, but does not mention pagination, sorting, response format, required permissions, or any side effects. For a list tool returning possibly many bundles, the lack of behavior details is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence stating the purpose and endpoint. Every element serves a purpose, and there is no fluff. It is concise while conveying the essential operation and target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, one required) and the description gives the core operation. However, there is no output schema and no mention of return structure, pagination limits, or how to differentiate from sibling list tools. Given the lack of annotations and the presence of many similar tools, the description is functional but incomplete for a fully informed agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both product_id and product_version have descriptions). The description adds the endpoint structure showing product_id as a URL path parameter, but this is already implicit in the parameter name and schema. No additional semantic meaning beyond the schema is provided, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's exact function: '取得商品方案列表' (get product bundle list) and provides the HTTP endpoint 'GET /v1/products/{product_id}/bundles', which clearly identifies the resource and scope (bundles of a specific product). This distinguishes it from siblings like 'list_bundles' (global bundles) and 'list_bundle_items' (items within a bundle) via the product_id path parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'list_bundles' or 'get_bundle'. The description merely states what the tool does without any exclusions, prerequisites, or comparison to sibling tools. There is no mention of when this is preferred over other similar list/get operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only states the HTTP method (GET), which implies read-only, but does not mention required authentication, response format, pagination, or any other behavioral traits. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that includes both the action and the endpoint. It is front-loaded and contains no filler or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation, the description conveys the core purpose and endpoint, but lacks any additional context such as what the returned list contains or typical use cases. With no output schema and no annotations, the description is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the baseline is 4. The description adds no parameter information, but none is needed. The schema coverage is effectively 100% as there are no properties to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '取得廠商權限列表 (GET /v1/vendors/actions)' clearly states the operation (get/vendor permission list) and includes the exact REST endpoint, which disambiguates it from sibling tools like list_vendor_roles or list_vendor_role_actions. The verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no context, and no exclusions. It is a bare statement of what it does, without situating it among the many sibling list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states 'GET /v1/vendors/categories', which implicitly suggests a read-only operation, but it does not explicitly describe side effects, return format, or any edge cases. For a list operation, some context about pagination or the shape of the response would be expected, but none is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that combines the purpose and the HTTP endpoint. Every word is meaningful, and it is appropriately front-loaded with the action. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema, the description is nearly complete. It identifies what the tool does and the endpoint. However, it does not describe what fields or structure the returned category list contains, which might be helpful when no output schema exists. Still, the simplicity of the tool makes this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter detail to explain. The baseline for 0 params is 4, and the description correctly omits any parameter information because none exists. It does not mislead or add confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '取得廠商分類列表' (get vendor category list) and provides the API endpoint. This is a specific verb+resource pair that matches the tool name and adds the endpoint as additional context. However, it does not differentiate from sibling list tools beyond the resource type, so it lacks the extra scoping that would merit a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like list_commodity_categories or list_vendor_users. There is no mention of prerequisites, intended scenarios, or when not to use it. This is a clear gap in usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It indicates a GET request (implying read-only) but adds no details about pagination, response format, or potential side effects. It does not contradict any annotations but provides minimal extra behavior info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the endpoint in parentheses. It is front-loaded with the purpose and contains no unnecessary words, maximizing clarity per character.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional param, no output schema), the description is minimally adequate. However, it lacks context about the meaning of return modes or how they relate to similar sibling tools, leaving some ambiguity about the expected result shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the only parameter (store_type), so the baseline is 3. The description does not add any additional meaning beyond what the schema already documents, making it neutral.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets vendor store pickup return modes, with the HTTP method and path provided. It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like list_vendor_store_pickup_return_dc or get_vendor_store_pickup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no context about scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes the HTTP method GET, which implies a read-only operation, but it does not disclose permissions, response format, or error behavior. With no annotations provided, the description only partially covers behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that includes the action and endpoint, with no redundant words or repetition. It is front-loaded with the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should explain what the tool returns (e.g., boolean, status code), but it only says 'check if exists'. It lacks information about the response and usage context, which is a significant gap for an API tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the email parameter, and the description's mention of '使用者 Email' adds little beyond the schema. The endpoint shows the email is a path parameter, a minor addition, but no deeper semantics like format constraints are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: '檢查使用者 Email 是否存在' (Check if user email exists), with a specific resource (user email) and endpoint. It distinguishes from sibling tools like check_vendor_tax_number by explicitly focusing on email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention prerequisites, typical scenarios, or exclude cases, leaving the agent to infer usage solely from the tool name and action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden. It discloses that the operation is a GET (read-only) and returns the latest version, which adds some transparency. However, it does not mention authentication requirements, error cases, or what the form structure is, leaving some behavioral detail unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that includes the action, resource, and endpoint. It is front-loaded and contains no unnecessary information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the 'category question group form' is and what data it returns. It only names the resource without providing domain context or expected response structure, leaving a significant gap for the agent to understand the tool's full capability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the only parameter (category_id) with a description '分類 ID'. The description adds the URL template with {category_id}, confirming its role as a path parameter, but does not provide additional semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (取得/get) and resource (最新版的分類題組表單/latest version of category question group form), and includes the full API endpoint. This clearly distinguishes it from sibling tools, many of which are list_* operations or target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites, and no exclusions. The description only states what it does, not when it should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only mentions that this is a GET request, which implies a read-only operation, but it does not disclose other behavioral traits such as authentication requirements, pagination, error handling, or whether the response is a simple list of strings/objects. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, containing only the essential purpose and endpoint. For a zero-parameter tool, this is appropriately sized. It could arguably be augmented with more context, but it avoids any redundancy or bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low complexity with zero parameters and no output schema, so the description can be brief. However, it does not describe the return format or structure of the packaging type list, which would be helpful since there is no output schema. It is adequate but leaves a gap in what the agent can expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the calibration. The description does not need to elaborate on parameter meanings because there are none, and the schema coverage is 100% (empty properties), which is consistent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '獲取' (get) and a specific resource '包材類型列表' (packaging type list), clearly distinguishing it from sibling list tools that target different resources. The endpoint further clarifies the exact API path, leaving no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It simply states what the tool does and the endpoint, without any context about prerequisites, typical use cases, or exclusions. The usage is only implied by the tool name, not substantiated in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden; it does disclose the HTTP GET method, implying a read-only retrieval. However, it does not mention authentication requirements, response shape, or whether any filtering/pagination applies, leaving the safety profile only partially explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that includes both the natural-language purpose and the exact endpoint. No redundant or filler content is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description names the resource and endpoint, which is largely sufficient. However, it leaves the meaning of 'DC' implicit and does not specify what the response represents, so contextual completeness is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to explain. The schema already reflects this with 100% coverage, and the baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '獲取' (get) with the resource '供應商超商退貨 DC' and includes the full endpoint, clearly identifying the tool's function. It does not explicitly contrast with siblings such as list_vendor_store_pickup_return_mode, but the 'DC' resource is distinct enough for a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over related tools like list_vendor_store_pickups or list_vendor_store_pickup_return_mode. The description is purely declarative and offers no contexts, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It explicitly reveals the HTTP method (GET), implying a read-only operation, but does not disclose error handling, authentication, or return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the tool's purpose and endpoint, with no redundant information. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET tool, the description and schema provide basic understanding. However, it lacks output schema, usage alternatives, and error behavior, making it only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions in the schema. The description adds no parameter-specific semantics beyond the endpoint path, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states retrieving a single bundle item option, referencing the specific HTTP endpoint. This distinguishes it from siblings like list_bundle_items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is given. The description does not specify when to use this tool over alternatives like get_item or list_bundle_items, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly states the HTTP method GET and the word '獲取' implies read-only operation, which is useful. However, it does not disclose any other behavioral traits such as authentication requirements, return format, or whether only active delivery types are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that includes both the human-readable purpose and the exact API endpoint. Every word earns its place; it is extremely concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with zero parameters and no output schema, the description clearly states that it returns a list of delivery types, which is sufficient for basic selection. It lacks deeper context about the meaning or structure of delivery types, but given the simplicity, the description is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% coverage. Per the rubric, a baseline of 4 applies when there are no parameters; the description does not need to add parameter meaning because none exist, and it appropriately does not invent any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb '獲取' (retrieve) and specific resource '出貨方式列表' (delivery type list), also providing the REST endpoint (GET /v1/common/delivery-type). This clearly conveys the tool's function, though it does not explicitly differentiate from the many sibling list_* tools other than by naming the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no statement of context, prerequisites, or mention of scenarios where this list is needed, leaving the agent to infer based solely on the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure, but it only states that it retrieves a list. It does not explicitly state that it is read-only, whether authentication is required, or any details about the response. The GET method is a weak implicit signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that includes the endpoint, which is efficient for a tool with no parameters. It avoids unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (zero parameters, no output schema), the one-line description is mostly adequate, but it could add context such as what review statuses are used for or that it returns all statuses without filters. The description is minimal but not misleading.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter semantics to clarify. According to the rubric, a baseline of 4 is appropriate when no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '獲取' (get) and names the resource '審核狀態列表' (review status list), clearly distinguishing it from sibling status-list tools like list_product_statuses or list_bundle_delivery_statuses. The HTTP endpoint further clarifies the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other list_* tools. It lacks any context about which scenarios require review statuses or any mention of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes the HTTP method GET, indicating a read-only operation, and the phrase '是否存在' implies a boolean existence check. However, with no annotations provided, the description carries the full burden and does not disclose response format, error behavior, authentication requirements, or any side effects. The GET method and existence semantics provide some transparency but leave key behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and includes the full endpoint. There is no filler or redundant content; every word contributes to understanding the tool. It is appropriately sized for a simple validation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description provides the core purpose and the exact endpoint, making it reasonably complete. It does not explicitly state the return value, but the phrase '是否存在' strongly implies a boolean result. Given the simplicity of the operation, the description covers most necessary context, though it could benefit from a note on the expected response type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter tax_number as '統一編號' (unified business number), and the tool description's '統編' is just an abbreviation of the same term. Thus, the description adds no new semantic value beyond the schema. With 100% schema coverage, the baseline of 3 is appropriate, and the description does not elaborate on format, length, or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to check if a unified business number (統編) exists, with the specific GET endpoint. This distinguishes it from the sibling tool check_vendor_user_email, which validates vendor user emails instead. The verb 'check' and the resource 'tax number' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or any exclusions. It does not mention that it is specifically for vendor tax numbers or suggest when to choose it over other validation tools. There is no context about prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While the HTTP method GET signals a read-only operation, the description does not mention error behavior (e.g., 404 for missing item), authentication requirements, or response format. The description is too sparse to satisfy transparency expectations without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose and endpoint. It is front-loaded with the action and resource, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and no output schema, the description adequately covers the core purpose. The return value (item details) is implied by the description. It is not exhaustive, but it is complete enough given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a 100% description coverage for the only parameter (id is described as '商品 ID'). The description merely echoes the parameter in the endpoint path and adds no additional semantic value beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed information for a specific item, including the exact HTTP endpoint (GET /v1/items/{id}). This explicitly identifies the resource and action, distinguishing it from list_items (which lists items) and get_product (which may fetch product-level data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need details for a single item by ID), but it does not explicitly mention scenarios when to avoid it or alternative tools. There is no direct comparison with siblings like list_items or get_bundle, leaving the usage context largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states that it retrieves a list. It does not disclose any behavioral traits such as authentication requirements, pagination, response shape, or whether any side effects occur. While a GET list is typically safe, the description itself provides no such assurance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the operation and endpoint. Every part is useful and there is no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a zero-parameter list operation with no output schema and no annotations. The description provides the essential invocation information (operation + endpoint). It does not mention what the response contains, but given the simplicity of the tool, the description is largely sufficient for an agent to select and call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing for the description to explain. The description adds no parameter semantics, but with 0 parameters, the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a list of announcement notification scopes (獲取公告通知範圍列表) and provides the exact endpoint (GET /v1/common/announcement-notify-scope). This specific verb+resource fully distinguishes it from siblings like list_announcement_notify_types and list_announcement_notify_levels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many sibling list tools. It lacks any context about use cases, prerequisites, or alternatives, so an agent must infer when to select this among similar list endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It only reveals the HTTP method (GET), implying a read-only operation, but does not disclose response format, authentication requirements, or any side effects. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused phrase that states the purpose and endpoint immediately. It contains no filler and is perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-list tool with no parameters and no output schema, the description's statement of purpose and endpoint is sufficient for an agent to understand the basic function. It lacks any mention of typical use cases or returned data, but given the simplicity, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100% trivially. The description adds no parameter-specific information, but none is needed; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (獲取/get) and the resource (方案出貨狀態列表/bundle delivery status list), including the API path. This distinguishes it from related siblings like list_bundle_delivery_notes and list_delivery_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of typical scenarios, exclusions, or prerequisites, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the HTTP method GET, implying a read-only operation, but does not elaborate on pagination, authentication requirements, or any limitations. Since no annotations are provided, the description carries full burden; the GET method offers a basic hint but omits potential edge cases or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that includes both the human-readable purpose and the API endpoint. It is front-loaded and contains no filler, earning a perfect conciseness score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 is minimal. It states the tool returns a list, but does not describe the structure of the delivery note objects or any relevant response details. For a zero-parameter list operation, this is acceptable but leaves room for ambiguity regarding the data returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. Per rubric, 0 params defaults to a baseline of 4. The description adds no parameter details because none exist, and none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '獲取方案出貨備註列表' (Get bundle delivery note list) and includes the endpoint (GET /v1/common/bundle-delivery-note), providing a specific verb and resource. It distinguishes itself from siblings like list_bundle_delivery_statuses and list_bundles by focusing on delivery notes specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention any filtering capabilities, exclusions, or related tools. The agent is left without context for selecting this tool among the many list_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The HTTP method 'GET' is included, implying a read-only operation with no side effects, which is useful given no annotations. However, it does not explicitly state safety, authentication needs, rate limits, or return structure. Since annotations are absent, more behavioral detail would be beneficial, but the GET method provides a baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states purpose and endpoint with no unnecessary words. It is highly concise and well-structured, delivering maximum information in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, but the description does not specify what the returned list contains (e.g., strings, objects, codes) or any other contextual details. It is minimally adequate but leaves some ambiguity about the return payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, so there are no parameter semantics to elaborate. The description correctly omits any parameter details. The baseline of 4 for zero-parameter tools is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action '獲取' (get) and the resource '方案類型列表' (bundle type list), and it also includes the API endpoint GET /v1/common/bundle-type. This distinguishes it from sibling tools like list_bundles or list_product_bundles by explicitly focusing on bundle types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or recommend other tools for related scenarios. The description only states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses the HTTP method (GET), strongly implying a read-only operation, and specifies the exact path. However, it does not mention pagination behavior, authorization requirements, or response characteristics beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the purpose and endpoint, with no redundant information. It is appropriately front-loaded and optimally brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list endpoint with six parameters and no output schema, the description provides the essential purpose and endpoint but omits details about return structure, pagination defaults, or any access constraints. It is adequate for basic tool selection but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the endpoint path showing product_id in the URI, which reinforces that product_id is a path parameter, but it does not significantly enhance the existing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '取得商品註解紀錄列表' (get product annotation logs list), and includes the exact REST endpoint. This specific verb+resource combination distinguishes it from sibling list tools such as list_product_bundles and list_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving product annotation logs but provides no explicit when-to-use guidance, alternatives, or exclusions. The unique resource name is a contextual cue, but no direct comparison to other list tools is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a GET request, indicating a read-only operation, which is a meaningful behavioral trait. However, with no annotations provided, it does not go further to describe return format, pagination, or any potential side effects, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that includes the Chinese phrase and the URL. It is front-loaded with the core purpose and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is adequate but leaves gaps. It does not explain what a product version is, what fields the response will contain, or any list-level behavior like pagination. The absence of an output schema places more burden on the description to clarify the return value, which it does not fully do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter product_id with a description, but the URL template '{product_id}' in the tool description adds semantic meaning by showing it is a path parameter and how it is used in the endpoint, going beyond the schema's simple label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '取得商品版本列表' (get product version list) clearly states the tool's purpose with a specific verb and resource. The appended URL 'GET /v1/products/{product_id}/versions' further specifies the operation and resource, distinguishing it from sibling tools like list_products or get_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context about prerequisites, exclusions, or alternative tools, leaving the agent to infer usage solely from the name and URL.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a GET request (implying read-only) and implies the user must be logged in, but it does not explicitly state that there are no side effects, what happens when not authenticated, or any rate limits. The endpoint provides some behavioral context, but the description could be more explicit about safety and error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the action and resource, with the API endpoint in parentheses for extra clarity. There is no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, no output schema, no annotations), and the description covers the core purpose. It is adequately complete for a straightforward get-current-user endpoint, though it could mention the shape of the returned information or typical use cases. Given the low complexity, the description is mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter information to add. Per the rubric, a baseline of 4 is appropriate. The description adds nothing about parameters, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('取得' - get) and a specific resource ('目前登入供應商使用者' - currently logged-in supplier user). It clearly distinguishes from siblings like get_vendor_profile (which likely gets a vendor by ID) and auth_status (which checks authentication status). The inclusion of the API endpoint (GET /v1/auth/me) further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention when this should be preferred over similar tools such as auth_status or get_vendor_profile, nor does it specify any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It discloses the HTTP method (GET), implying a read-only operation, and the resource being fetched. However, it does not mention any authentication requirements, return format, or potential side effects. For a simple zero-parameter list, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence containing both the human-readable purpose and the technical endpoint. It is concise, direct, and free of unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description provides adequate context: it identifies the resource and the action. The endpoint adds technical specificity. It could be improved by clarifying the return structure, but this is not essential for a simple list. The existence of similar sibling tools is not mentioned, but the 'levels' qualifier mitigates ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema description coverage is trivially 100%. The baseline for zero parameters is 4, and the description does not need to add parameter details. It correctly omits any parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '獲取公告通知等級列表' (get announcement notification level list) and includes the specific HTTP endpoint. It distinguishes from siblings like list_announcement_notify_types and list_announcement_notify_scopes by specifying 'levels' as the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool compared to alternatives. There is no mention of context, prerequisites, or exclusion criteria. Sibling tools with similar names (types, scopes) are not referenced, leaving the agent without differentiation cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses a key behavior (only approved items) and implies a read-only operation via the GET endpoint, but it does not mention pagination, ordering, response structure, or any required authentication. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and includes the endpoint and key filter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the essential context: resource, endpoint, purpose, and the approval filter. Given the tool has no output schema and no annotations, it covers the core needs for a simple list tool. It omits pagination or return field details, but these are not critical given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters (is_gift, keyword, item_ids), each with clear descriptions. The tool description itself adds no parameter details, but the schema already handles this, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an item selection list (GET /v1/item-selection) and specifies that it only includes approved products for plan selection. This distinguishes it from general item lists like list_items, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: '供方案選擇商品用' (for plan product selection). It also notes the list contains only approved items, implying when it is appropriate. However, it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the HTTP method (GET) and the list nature of the operation, implying read-only behavior. However, it doesn't provide any additional behavioral context such as authentication needs, rate limits, or the content structure, which is expected given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with an endpoint reference, front-loading the primary information without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no parameters or output schema, the description adequately conveys the purpose. It could be enhanced by describing the return format, but the tool's simplicity and the explicit resource name make it sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema is complete and the description has no need to clarify parameter semantics. The baseline of 4 applies because no param info is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a list of bundle pricing channels via the endpoint /v1/bundles/pricing-channels. The specific resource 'pricing_channels' distinguishes it from siblings like list_channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternative list tools. The description only states what it does, without any context on usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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. It does reveal the HTTP method (GET), which implies a read-only operation, but it doesn't explicitly state that the operation is safe or describe any response format or edge cases. This is adequate for a simple list endpoint but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that includes both the action and the API endpoint. It contains no unnecessary words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (0 parameters, no output schema, no annotations), the description is complete. It fully conveys the purpose and the HTTPS endpoint, which is all an agent needs to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description adds nothing about parameters, but none are needed; the schema is trivially complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get invoice type list' and specifies the exact endpoint (GET /v1/common/invoice-type). This is a specific verb+resource that distinguishes the tool from sibling list tools like list_bundle_types or list_delivery_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly explain when to use this tool or mention alternatives. Usage is only implied by the tool name and its membership among similar list-type tools, so it meets the minimum viable level but lacks clear context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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. It clarifies that the tool lists attachments and that file download is not available, which prevents a common misunderstanding. However, it does not mention authentication, pagination, or response structure, leaving some behavioral details undisclosed. The added caveat about Phase 1 strengthens transparency beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the purpose and endpoint, while the second adds a relevant limitation without any redundant wording. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list endpoint with no parameters and no output schema, the description provides the essential information: what it lists and a key limitation. However, it does not detail the returned fields or any pagination/filtering behavior, and the 'Phase 1' reference is somewhat ambiguous. Despite these gaps, the tool's simplicity and clear name make the description reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema reflects this with 100% coverage. The description correctly omits parameter information, and the baseline for zero-parameter tools is 4. No additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '取得廠商上傳文件列表' (get vendor uploaded file list) and specifies the endpoint GET /v1/vendors/attachments. It unambiguously identifies the tool's purpose and differentiates it from sibling list tools like list_vendor_users or list_bundles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or name alternatives. However, the note that file body download is a binary endpoint not implemented in Phase 1 serves as an implicit limitation, indicating that this tool is for metadata listing only and not for downloading files. This provides some usage guidance, but lacks explicit exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and clearly discloses a key behavior: 'Does NOT hit the upstream API — purely a local cache check.' This alerts the agent that the tool is safe and fast, avoiding unnecessary network calls. It could add more detail about response format or staleness, but this is sufficient for a simple status tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three lines, front-loaded with the purpose, followed by usage guidance and a key behavioral caveat. Every sentence earns its place with no fluff. It is tightly structured and immediately readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status check tool, the description fully covers what it does, when to use it, and its local-cache behavior. No output schema exists, but 'Report whether' sufficiently indicates the return type. No additional context is needed for the agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes 0 parameters, so the baseline is 4. The description correctly omits parameter details since there are none, and the schema is already at 100% coverage (vacuous). No additional explanation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb 'Report' and clearly identifies the resource: 'whether the MCP currently has a usable vendor access token.' This distinguishes it from sibling tools like vendor_login and get_current_user by focusing on token availability rather than the login process or user info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Directly states when to use: 'Call this before other tools if you're unsure whether login is needed.' This gives explicit usage context and implies that other tools may require a valid token. The note 'Does NOT hit the upstream API' also guides users to prefer this tool for a quick, side-effect-free check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses all significant side effects: opening a real Chromium window, best-effort prefill, user solving reCAPTCHA, capturing the login response, updating the in-memory cache, and writing tokens back to .env. It also reveals blocking behavior up to 10 minutes, which is critical for agent expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, explicit usage conditions, and a numbered flow. Every sentence adds operational value (prefill, captcha, cache, .env, blocking) without fluff, making it easy to parse and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the full lifecycle: triggers, user interaction steps, backend side effects, persistence, and timeout behavior. No output schema exists, but the description sufficiently explains what happens during and after execution, making it complete for an interactive login tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to elaborate. The baseline of 4 applies because the description correctly implies no parameters are needed, and no additional semantic explanation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb phrase ('Open a real Chromium window') and identifies the exact resource (vendor frontend) and goal (user login). It clearly distinguishes this from sibling read-only tools like auth_status and get_current_user by describing an interactive login flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use this when' conditions tied to auth_status=false or token errors, making it unambiguous when to invoke. The numbered flow also clarifies the expected sequence and user involvement, effectively indicating when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-buy123-vendor MCP server](https://glama.ai/mcp/servers/asgard-ai-platform/mcp-buy123-vendor/badges/card.svg)](https://glama.ai/mcp/servers/asgard-ai-platform/mcp-buy123-vendor)

Score Badge

Copy to your README.md:

[![mcp-buy123-vendor MCP server](https://glama.ai/mcp/servers/asgard-ai-platform/mcp-buy123-vendor/badges/score.svg)](https://glama.ai/mcp/servers/asgard-ai-platform/mcp-buy123-vendor)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/asgard-ai-platform/mcp-buy123-vendor'

If you have feedback or need assistance with the MCP directory API, please join our Discord server