Indonesia Logistics (Biteship: courier rates / cek ongkir, create orders, track waybills)
Server Details
Indonesia shipping for AI agents via Biteship: courier rates, create orders, track waybills.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.5/5 across 4 of 4 tools scored.
Each tool targets a distinct lifecycle phase: check_rates for quoting, create_shipment for ordering, cancel_shipment for cancellation, query_tracking for tracking. No functional overlap.
All tools use a verb_noun pattern (check_rates, create_shipment, cancel_shipment, query_tracking), consistent and predictable.
Four tools perfectly cover the core logistics workflow (rates, order, cancel, track) without unnecessary extras or gaps.
Covers the full lifecycle: rate inquiry, order creation, conditional cancellation, and tracking. No obvious missing operations for the stated purpose.
Available Tools
4 toolscancel_shipmentADestructiveIdempotentInspect
Cancel an Indonesia Biteship order by its Biteship order id, with a cancellation reason. Cancellation is only possible before the parcel is picked up / in transit — an already-picked-up order cannot be cancelled here. Returns the cancellation result reported by Biteship.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The Biteship order id to cancel (the id create_shipment returned). Required. | |
| cancellation_reason | No | Why the order is being cancelled (free text). Optional — a default reason is used if omitted. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructive, read-only false, and idempotent. Description adds context on cancellation conditions (pickup status) and return value. No contradiction.
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 verb and resource, no redundant text. Every sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description suffices by mentioning return value. Parameter behavior and constraints fully covered. Complexity is low, and description is 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?
Adds value beyond schema by linking order_id to create_shipment output and stating cancellation_reason is optional with default. Schema coverage is 100%.
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 it cancels an Indonesia Biteship order by order ID, with a reason. The verb-resource pairing is precise and distinguishes it from sibling tools like check_rates, create_shipment, and query_tracking.
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 specifies when cancellation is possible (before pickup/in transit) and when not (after pickup). Also clarifies that order_id is from create_shipment, guiding correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_ratesARead-onlyInspect
Indonesia shipping courier rates — THE tool to call FIRST. Given an origin and a destination (each by 5-digit Indonesian postal code OR a Biteship area_id), the parcel items (name, value IDR, weight in GRAMS, quantity), and optionally which couriers to compare, it returns every available courier service (JNE, J&T, SiCepat, AnterAja, Gojek, Grab, Ninja, Pos Indonesia, Lion Parcel and more) with its shipping fee (IDR), estimated duration and service type, plus which one is cheapest — the Indonesia killer feature (cek ongkir). Read-only: quotes only, creates nothing and spends nothing. Bring your own Biteship API key via header x-biteship-key.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Parcel line items. At least one. Each: { name (required), value (required, IDR), weight (required, GRAMS), quantity (required int), length?/width?/height? (cm) }. | |
| couriers | No | Comma-separated courier codes to compare, e.g. "jne,jnt,sicepat,anteraja,gojek,grab". Optional — defaults to a broad set of popular Indonesian couriers. | |
| origin_area_id | No | Biteship area_id for the origin (from the Maps/Areas lookup). Alternative to origin_postal_code. | |
| origin_postal_code | No | Origin 5-digit Indonesian postal code the parcel ships FROM. Provide this OR origin_area_id. | |
| destination_area_id | No | Biteship area_id for the destination. Alternative to destination_postal_code. | |
| destination_postal_code | No | Destination 5-digit Indonesian postal code the parcel ships TO. Provide this OR destination_area_id. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the tool is read-only: 'Read-only: quotes only, creates nothing and spends nothing.' This aligns with the readOnlyHint annotation. It adds additional behavioral context beyond the annotation, such as requiring an API key, and explains it returns quotes without 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is well-structured: starts with purpose, then explains inputs, then behavioral note. It is relatively concise but includes some marketing language ('Indonesia killer feature') that adds character but slightly reduces strict conciseness. Overall efficient.
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 complexity (6 parameters, nested items, optional fields) and no output schema, the description covers essential aspects: how to specify origin/destination, required item fields, courier selection, and the output content (fees, duration, cheapest). It is fairly complete for an agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the relationship between postal codes and area_ids, clarifying units (grams, IDR, cm), and indicating that couriers parameter is optional with a default broad set. It also summarizes item structure.
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 explicitly states it checks Indonesia shipping courier rates, details the inputs (origin/destination by postal code or area_id, parcel items, optional couriers), and outputs (every available courier with fees, duration, service type, and cheapest). It distinguishes itself from siblings like create_shipment or query_tracking by emphasizing it is 'THE tool to call FIRST' and read-only.
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 clearly indicates when to use the tool: to compare courier rates before creating a shipment. It says 'THE tool to call FIRST' implying priority. It does not explicitly state when not to use it, but the sibling tools' purposes (cancel, create, query) provide natural exclusions. It also mentions needing an API key, which guides usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_shipmentAInspect
Create an Indonesia shipping order in Biteship — pass the origin (pickup) contact + address, the destination (recipient) contact + address, the parcel items, and the chosen courier_company + courier_type (from check_rates courier_code + courier_service_code). Each location needs a postal_code OR area_id. Returns the Biteship order id, the courier waybill_id (once allocated) and the price (IDR). delivery_type defaults to "now" (immediate pickup). Bring your own Biteship API key via header x-biteship-key — a biteship_live_ key ships real parcels and debits your Biteship balance; a biteship_test_ key stays in the sandbox. Owner policy headers gate the order value (IDR) before creation.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Parcel line items. At least one. Each: { name (required), value (required, IDR), weight (required, GRAMS), quantity (required int), description?, sku?, length?/width?/height? (cm) }. | |
| order_note | No | Free-text note for the whole order. Optional. | |
| origin_note | No | Note for the courier at pickup. Optional. | |
| courier_type | Yes | Courier service type from check_rates (courier_service_code), e.g. "reg", "yes", "instant", "same_day". Required. | |
| reference_id | No | Your own order reference (any unique string). Optional. | |
| delivery_date | No | Scheduled pickup date "YYYY-MM-DD" (only when delivery_type=scheduled). | |
| delivery_time | No | Scheduled pickup time "HH:mm" (only when delivery_type=scheduled). | |
| delivery_type | No | "now" (immediate pickup, default) or "scheduled" (with delivery_date + delivery_time). | |
| origin_address | Yes | Full pickup street address. Required. | |
| origin_area_id | No | Biteship area_id for the pickup location. Alternative to origin_postal_code. | |
| courier_company | Yes | Courier code from check_rates (courier_code), e.g. "jne", "jnt", "sicepat", "anteraja", "gojek", "grab". Required. | |
| destination_note | No | Delivery note for the courier. Optional. | |
| courier_insurance | No | Declared insurance amount in IDR. Optional. | |
| origin_postal_code | No | Pickup 5-digit postal code. Provide this OR origin_area_id. | |
| destination_address | Yes | Full recipient street address. Required. | |
| destination_area_id | No | Biteship area_id for the recipient. Alternative to destination_postal_code. | |
| origin_contact_name | Yes | Pickup contact person name. Required. | |
| origin_contact_phone | Yes | Pickup contact phone (Indonesian number). Required. | |
| shipper_contact_name | No | Business/shipper name shown to the courier. Optional — defaults to the origin contact name. | |
| destination_postal_code | No | Recipient 5-digit postal code. Provide this OR destination_area_id. | |
| destination_contact_name | Yes | Recipient name. Required. | |
| destination_contact_email | No | Recipient email. Optional. | |
| destination_contact_phone | Yes | Recipient phone (Indonesian number). Required. | |
| destination_cash_on_delivery | No | COD amount to collect in IDR. Optional — omit for prepaid. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects (real shipment with live key, sandbox with test key) and authorization (owner policy headers). Annotations already indicate mutation (readOnlyHint=false), description adds valuable context beyond.
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?
Description is thorough but slightly verbose. It front-loads the purpose and then details parameters and constraints. Every sentence adds value, but could be more concise.
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?
Covers workflow, prerequisites, authentication, owner policy, return values, and parameter relationships. No output schema but mentions return fields. Complete for the complexity of 24 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. Description adds meaning: explains origin/destination roles, courier_company/type from check_rates, postal_code/area_id alternatives, delivery_type default, and return fields order id, waybill_id, price.
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 verb 'Create' and the specific resource 'Indonesia shipping order in Biteship'. It lists the required components (origin, destination, items, courier) and distinguishes from siblings like cancel_shipment and check_rates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: use after check_rates, provides API key requirement, owner policy gate, and delivery_type defaults. Does not explicitly list when-not-to-use, but context implies when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_trackingARead-onlyInspect
Track an Indonesia shipment. Provide the Biteship tracking_id (returned by create_shipment) OR the Biteship order_id OR a public waybill + courier_code pair. Returns the current status plus a plain-English hint. Common Biteship statuses: confirmed, scheduled, allocated, picking_up, picked, dropping_off, delivered, on_hold, courier_not_found, return_in_transit, returned, rejected, disposed, cancelled. The raw response (history scans, courier, link) is always included. Non-terminal statuses carry next_steps. Safe to call anytime. NOTE: a brand-new order may show "confirmed" with no waybill until a courier is allocated.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | No | Alternative: the Biteship order id (looks up the order and its current status). | |
| waybill_id | No | Alternative (public tracking): the courier AWB / waybill number. Requires courier_code too. | |
| tracking_id | No | The Biteship tracking_id returned by create_shipment (preferred). | |
| courier_code | No | Courier code for public waybill tracking, e.g. "jne", "jnt", "sicepat". Required when using waybill_id. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (safe read). The description adds value by detailing return contents (status, plain-English hint, raw response, next_steps) and explaining behavior for new orders (shows 'confirmed' with no waybill). No contradiction with annotations.
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 moderately sized with front-loaded purpose. It efficiently conveys key information, though it could be slightly more concise (e.g., 'Safe to call anytime' is implicit from annotations).
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 explains return values (status, hint, raw response, next_steps) and common statuses. It covers edge cases (new orders) and parameter alternatives, making it fairly complete for a tracking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter. The description adds extra meaning by explaining the three use cases, preferences, and the relationship between waybill_id and courier_code, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool tracks Indonesia shipments, specifies the verb 'track', identifies the resource (shipment), and distinguishes it from siblings (cancel_shipment, check_rates, create_shipment) by focusing on tracking status.
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 explains the three alternative ways to call the tool (tracking_id, order_id, or waybill+courier_code), indicates preference (tracking_id is preferred), and notes that it's safe to call anytime. However, it does not explicitly state when not to use it or compare to siblings.
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.
Discussions
No comments yet. Be the first to start the discussion!