Create Thailand Post shipments, print labels, and track parcels in Thailand via ProShip.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 11 of 11 tools scored. Lowest: 2.5/5.
Each tool targets a distinct action or resource: order CRUD, duplicate check, status reference, shop listing, label printing, account creation, and parcel tracking. No two tools overlap in purpose.
All 11 tool names follow a consistent snake_case verb_noun pattern (e.g., create_order, list_shops, update_order_status). Even 'signup' and 'check_duplicate' fit the pattern naturally.
With 11 tools covering order lifecycle, shops, tracking, and account setup, the count is well-scoped for the domain. Each tool earns its place without being excessive or sparse.
Core workflows (create, get, list, update status, cancel, print label, track) are covered. Minor gaps include no tool to update order details (e.g., address or weight) or manage shops beyond listing, but these are not critical for most use cases.
cancel_orderCInspectDelete/cancel an order by id.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It states the tool deletes/cancels, implying destruction, but does not clarify if this is a hard or soft delete, whether reversal is possible, or what side effects (e.g., on linked records) occur. For a destructive action, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no extraneous words. It is concise but could include more detail (e.g., behavioral notes) without becoming verbose. The structure is clear and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (one parameter), the description lacks key context for a destructive operation, such as irreversibility, confirmation requirements, or impact on related data. Given the sibling list, no guidance on when to cancel vs update status further undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate. It mentions 'by id' but does not explain what 'order_id' represents, its format, or any constraints. The value added beyond the parameter name is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete/cancel' and the resource 'order', with the identifier 'by id'. This is specific and distinguishes the tool from siblings like 'update_order_status' or 'get_order', though it does not explicitly call out differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives (e.g., 'update_order_status' for non-deletion changes, or 'create_order' for new orders). No prerequisites, conditions, or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_duplicateBInspectCheck whether a customer phone number already has a recent order (duplicate-shipment guard).
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | Customer phone number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states it 'checks' but does not disclose whether the tool is read-only, what constitutes 'recent' (time window), the exact return value, or any side-effects. This leaves significant ambiguity for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 15 words, front-loaded with the verb 'Check', and contains zero filler. Every word serves a purpose, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain the return value. It only says 'Check whether...' without stating what the tool returns (boolean, order ID, etc.). Additionally, 'recent' is vague. For a simple 1-parameter tool, this lack of completeness forces the agent to guess behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The tool description adds context ('duplicate-shipment guard') but does not add format, constraints, or example values beyond the schema's 'Customer phone number' description. It meets the minimum but does not exceed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if a phone number has a recent order, with a specific use case ('duplicate-shipment guard'). The verb 'check' and resource 'customer phone number' are precise, and it distinguishes itself clearly from sibling tools that create, cancel, or retrieve orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The phrase 'duplicate-shipment guard' hints at use before creating an order, but there is no when-to-use, prerequisites, or mention of related tools like create_order. The agent must infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_orderAInspectCreate a shipment order. Defaults to Thailand Post EPS (thaipost0). Weight is in GRAMS. Returns the order_id — it contains a pipe suffix (order-xxx|123); always pass the FULL id to other tools. Optional cod_amount enables cash-on-delivery.
| Name | Required | Description | Default |
|---|---|---|---|
| user | No | Optional: ProShip username. Normally decoded from your token automatically. | |
| ref_no | No | Optional: your own order reference | |
| weight | Yes | Parcel weight in grams | |
| remarks | No | ||
| shop_id | Yes | Your shop id (see list_shops) | |
| customer | Yes | ||
| products | No | Optional line items | |
| cod_amount | No | Optional: cash-on-delivery amount (THB) | |
| shipping_method | No | Default thaipost0 (EPS). thaipost requires a Thailand Post contract on your account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. Clearly states return value (order_id with pipe suffix), weight unit (grams), optional COD behavior, default shipping method. Discloses that ID needs full value passed to other tools. Lacks info on error modes, idempotency, or whether order is created immediately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load key details. No fluff or repetition. Could potentially combine first two sentences, but remains tight. Missing punctuation is minor.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 9 params, nested objects, no output schema, and no annotations, description covers essential defaults and return format but omits many usage patterns: what happens on failure, required permissions, idempotency, relationship to check_duplicate or update_order_status. Barely adequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 78% – already detailed in schema. Description adds critical context for weight ('in GRAMS'), shipping_method defaults, and cod_amount purpose. Explains order_id return format. However, some params like remarks still lack schema description and description doesn't compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a shipment order' with specific verb and resource. Distinguishes from siblings like cancel_order, get_order, list_orders by focusing on creation. Somewhat vague on exact scope (creates only? returns immediately?). Could clarify if it's async or synchronous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states default shipping method (Thailand Post EPS) and provides alternative ('thaipost requires contract'). Hints at prerequisites by referencing list_shops for shop_id. Could add more when-to-use vs cancel/update tools, but context is reasonable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_orderAInspectGet one order by id (full pipe-suffixed id is fine). Returns status with Thai label and tracking number.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes |
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 that the ID can be a 'full pipe-suffixed id' and that the return includes status, Thai label, and tracking number. However, it does not mention whether the operation is read-only, requires authentication, or has any side effects, nor does it specify the full response structure. The useful format hint helps, but overall behavioral details are limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences totaling 20 words. The first sentence states the purpose and parameter format, the second specifies return fields. Every word earns its place, and the information is front-loaded. No wasted or redundant language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations, and many siblings), the description covers the basic call and return fields but lacks details about the full response object (e.g., whether it returns the entire order or just the mentioned fields). It also does not mention error handling or missing IDs. The description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only the parameter name 'order_id' with no description (0% coverage). The description adds meaning by stating that a 'full pipe-suffixed id is fine,' which clarifies the accepted format. This goes beyond the schema, but it does not specify other valid formats or constraints, so it is not fully comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get one order by id') and the resource ('order'), with a specific verb and resource. It distinguishes from siblings like 'list_orders' (multiple orders) and 'track_parcel' (tracking without order context) by focusing on a single order retrieval and mentioning return fields (status, Thai label, tracking number).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used when you need a single order by its ID, but it does not explicitly state when to use this versus alternatives like 'list_orders' for multiple orders, 'get_order_statuses' for statuses, or 'cancel_order' for cancellation. No exclusions or prerequisites are given, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_order_statusesAInspectReference data: the ProShip order status pipeline. Returns every status code with its Thai label and English meaning. Use these codes with list_orders and update_order_status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It states it returns status codes with labels and meanings, which is adequate for a zero-parameter read-only tool. Lacks mention of whether the data is cached or live, but this is minor for a reference data tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and followed by usage guidance. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description fully covers what the tool does, what it returns, and how to use its output. No gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with no parameters, so the description has no parameters to explain. The description adds value by naming the response contents (status codes, Thai labels, English meanings), which helps agents understand what the empty input will produce.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Returns every status code with its Thai label and English meaning', which clearly states the tool's purpose as a reference data provider for the order status pipeline. It is distinct from siblings like list_orders or update_order_status by being a read-only enumeration of statuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use these codes with list_orders and update_order_status', giving direct guidance on when to use this tool and how it relates to sibling tools. No alternative or when-not-to-use is needed given its simple reference nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_ordersAInspectList orders on YOUR account. Optional numeric status filter (see get_order_statuses). Paginated.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Default 1 | |
| status | No | Optional status code filter | |
| per_page | No | Default 50, max 100 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral traits. It discloses the account-scoped access ('on YOUR account'), filtering capability, and pagination. However, it does not state that the operation is read-only (safe), describe result ordering, or mention any side effects. Lacks explicit read-only hint, but the behavior is mostly implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence delivers the core purpose immediately; the second packs optional filtering and pagination into a single concise clause. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers account scope, optional filter, and pagination. It also points to a sibling tool for status code reference. Missing details like result ordering or field list, but for a paginated list tool with 3 simple parameters, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds value by stating 'on YOUR account' (scoping results), referencing 'get_order_statuses' for valid status codes, and labeling the tool as paginated. This enriches understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List orders on YOUR account' – a specific verb (list) and resource (orders), with explicit scoping to the authenticated user's account. This distinguishes it from sibling tools like 'get_order' (single order), 'create_order', 'cancel_order', etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions an optional numeric status filter and references 'get_order_statuses' for valid codes, hinting at when to apply filtering. It also notes pagination, implying large result sets. However, it does not explicitly state when to prefer this tool over alternatives (e.g., use get_order for a single order), nor does it provide negative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_shopsAInspectList the shops on YOUR ProShip account. Use the shop_id with create_order.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly indicates a read operation ('List'), but lacks details on pagination, ordering, or potential edge cases (e.g., empty list). For a simple parameterless tool, this is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence front-loads the core purpose, and the second adds practical guidance. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, no output schema, no annotations). The description explains what it does and why it's useful (to obtain shop_id for create_order). It could be slightly more explicit about the return format (e.g., 'returns a list of shops with their IDs'), but it is substantially complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema already covers everything. Per the rubric, 0 parameters yields a baseline of 4. The description adds no parameter information, which is appropriate since there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List the shops on YOUR ProShip account', using a specific verb and resource. It distinguishes itself from sibling tools (which are mostly order-related) by focusing on shops, and provides additional context by mentioning the shop_id's use in create_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing the user's shops and hints at downstream usage ('Use the shop_id with create_order'). However, it does not explicitly state when to use this tool versus alternatives, though no sibling tools exist for listing shops, so the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
print_labelAInspectGenerate the shipping label PDF for one or more orders. REQUIRES the FULL pipe-suffixed order ids (order-xxx|123) — stripped ids are rejected upstream. Returns a temporary URL (valid ~10 minutes) where the PDF can be downloaded.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Label size, default "normal" | |
| printer | No | Label format, default "proship" | |
| order_ids | Yes | FULL pipe-suffixed order ids |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns a temporary URL (valid ~10 minutes) for PDF download, which is key behavioral info. However, it does not state whether the tool is destructive (e.g., consumes the label or marks orders) or if authentication/rate limits apply, preventing a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no wasted words. Purpose, critical requirement, and return value are all front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with 3 parameters, 1 required, and no output schema. The description covers the purpose, input constraint, and return type well. However, it lacks details on error conditions (e.g., invalid order id behavior, label generation failures) which could be useful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already describes all parameters and defaults. The description adds the critical constraint about pipe-suffixed ids and the PDF return URL, but does not explain the effect of size or printer options beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a shipping label PDF for one or more orders, specifying the exact resource (shipping label) and action (generate). It distinguishes from siblings like get_order and list_orders by focusing on label generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the required format for order IDs (pipe-suffixed full ids) and warns that stripped ids will be rejected. It does not explicitly name alternatives for printing labels, but given the sibling list contains no other print-related tools, this is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
signupAInspectCreates a real ProShip account and shop, ready for Thailand Post EPS (thaipost0) shipping. The response contains your API token, user, and shop_id — SHOWN ONLY ONCE. Save the token into your MCP client's Authorization header. A full thaipost contract additionally requires a Thailand Post account arranged with ProShip support (multi-day human process).
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | Thai mobile number for the shop, e.g. 0812345678 | |
| address | Yes | Thai address, structured | |
| shop_name | Yes | Name of your shop (prints on labels) | |
| display_name | No | Optional account display name (defaults to shop_name) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations are provided, the description fully carries the burden of behavioral transparency. It discloses that the response contains the API token, shop_id, and user shown only once, and warns to save the token immediately. It also reveals the multi-day human process required for a full contract, which is critical for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, no redundancy. The first sentence states the core purpose, the second gives critical behavioral details about the response, and the third provides context on additional requirements. Every sentence is earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool creation nature, complexity (nested address object, token return), lack of output schema, and wealth of sibling tools, the description covers purpose, behavioral traits, post-invocation steps, and human prerequisites comprehensively. No obvious gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the 'shop_name' prints on labels and 'display_name' defaults to shop_name, which are not in the schema. However, it doesn't add semantics for 'phone' or 'address' beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a real ProShip account and shop for Thailand Post EPS shipping. It uses specific verbs ('Creates') and nouns ('ProShip account and shop'), and distinguishes this tool from siblings like create_order by focusing on account creation rather than order operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for initialization/registration) and provides important post-usage guidance about saving the token and noting the one-time display. It mentions that a full thaipost contract requires additional human process, but does not explicitly contrast with siblings like list_shops or create_order, which would clarify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
track_parcelAInspectTrack any parcel by tracking number (Thailand Post and other Thai carriers). Returns current status with Thai label plus the event history. Works without auth if the server has a tracking token configured; otherwise pass your Bearer token.
| Name | Required | Description | Default |
|---|---|---|---|
| tracking_no | Yes | Carrier tracking number, e.g. TH0139... |
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 output format: 'Returns current status with Thai label plus the event history.' It also explains the auth behavior. It does not cover rate limits, error handling, or data freshness, but the provided details are sufficient for a low-complexity tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each serving a distinct purpose: purpose, output details, and auth context. It is front-loaded with the core action and avoids any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 required parameter, no output schema, no nested objects), the description adequately covers purpose, output, and authentication. It could be improved by mentioning error handling or invalid tracking numbers, but it is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (tracking_no is described with an example). The description adds no additional semantic meaning beyond the schema; it merely restates the purpose. Per the baseline rule for high coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Track any parcel by tracking number' and specifies carriers (Thailand Post and other Thai carriers). It distinguishes well from sibling tools like create_order, cancel_order, etc., which are order management functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool – to track parcels. It also provides authentication guidance: 'Works without auth if the server has a tracking token configured; otherwise pass your Bearer token.' However, it does not explicitly state when not to use it (e.g., for non-Thai carriers) or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_order_statusBInspectSet an order status by numeric code (see get_order_statuses).
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | Status code, e.g. 5 = cancelled by seller | |
| order_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Set an order status by numeric code', without mentioning side effects, idempotency, authorization requirements, or what happens if the order is already in that status. The description adds minimal value 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the key action. It is efficient and avoids redundancy. However, the brevity sacrifices necessary detail, making it less valuable than a slightly longer but more informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 parameters, no nested objects, no output schema) and lack of annotations, the description is incomplete. It does not explain the order_id parameter, return values, error conditions, or prerequisites. The tool is a mutation, but the description provides no context on what constitutes a valid update or what happens upon success/failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (order_id has no description). The description adds value by referencing 'get_order_statuses' for the status parameter, but it does not explain the order_id parameter at all. For the status parameter, the schema already provides example values, so the description's contribution is marginal. Overall, partial compensation for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set an order status') and specifies the mechanism ('by numeric code'). It references 'get_order_statuses' for valid codes, which helps distinguish this tool from others. However, it does not explicitly differentiate from the sibling 'cancel_order', which could be considered a specific status update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by referencing 'get_order_statuses' to obtain valid codes, providing some guidance on when to use this tool. However, it offers no explicit instructions on when to use this tool versus alternatives like 'cancel_order', nor does it mention prerequisites or context (e.g., order must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.