bol-ai
Server Details
Extract structured data from Bills of Lading: parties, ports, containers, incoterms. EU-hosted.
- 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.3/5 across 8 of 8 tools scored.
Each tool targets a distinct operation: extraction (single and batch), retrieval, listing, correction, export, reconciliation, and usage. No overlapping purposes; descriptions clearly differentiate them.
All tool names use snake_case with a consistent verb_noun pattern (e.g., export_documents, extract_batch, get_document). No mixing of conventions.
8 tools is well-scoped for a document extraction and management service, covering all essential operations without being too few or excessive.
The tool set covers the full lifecycle: extraction (single and batch), retrieval, listing, corrections, export, reconciliation, and usage monitoring. No obvious gaps for the domain.
Available Tools
8 toolsexport_documentsExport documents as normalized rowsARead-onlyInspect
Export completed extractions as TMS/ERP-ready normalized line rows (one row per container / invoice line / package / goods line), newest first. Optional doc_type filter and max_rows cap. Corrected data wins over the original extraction. For CSV/XLSX files use GET /api/bol/export on the REST API.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Only include documents of this type | |
| max_rows | No | Maximum rows to return (default 500) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by specifying that corrected data takes precedence over original extraction and that results are ordered newest first. No contradictions 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 concise—one core sentence plus a pointer to the REST API for alternative formats. Every part adds value without 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?
Given no output schema, the description explains the output format (normalized lines per container/invoice/package/goods) and ordering. It lacks details on potential error states or edge cases, but for a simple list tool with two optional parameters, it 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?
The description mentions both parameters ('Optional doc_type filter and max_rows cap') but does not add meaning beyond the input schema, which already has full coverage (100%) and includes individual descriptions. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'export' and the resource 'documents', specifying the output as 'TMS/ERP-ready normalized line rows'. It mentions optional filters and ordering. However, it does not explicitly distinguish this tool from sibling tools like extract_batch or get_document, though the export function is unique among them.
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 indicates when to use this tool (exporting normalized rows) and provides an alternative for CSV/XLSX via the REST API. It does not explicitly state when not to use it or compare to sibling tools, but the context is clear that this is for export purposes only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_batchExtract multiple freight documentsAInspect
Extract up to 10 freight documents in one call. Provide an array of fetchable URLs; each document is processed and billed independently, and the response reports a per-document outcome so partial success (e.g. running out of credits mid-batch) is explicit.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | URLs of documents to fetch and extract (max 10) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds significant context: each document is processed and billed independently, and partial success is reported. This goes beyond annotations without 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?
The description is two sentences (60 words), front-loaded with the core purpose. Every sentence provides necessary information without 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?
Given no output schema, the description adequately explains the per-document outcome and partial success behavior. It lacks mention of authentication requirements but annotations and context signals suffice for a complete understanding.
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% (only 'urls' parameter). The description adds meaning by specifying that URLs must be 'fetchable' and that documents are processed independently. This provides additional context beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Extract up to 10 freight documents in one call,' clearly specifying the action (extract) and resource (freight documents). It distinguishes from siblings like extract_bol (single document) and export_documents (different action).
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 input requirement (array of fetchable URLs) and the behavior (independent processing, billing, per-document outcomes). It implicitly guides when to use (batch extraction) but does not explicitly state when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_bolExtract freight documentAInspect
Extract structured data from a freight document (PDF, PNG or JPG, max 10 MB): Bill of Lading, commercial invoice, packing list, or CMR road waybill. The document type is detected automatically and returned as doc_type. Provide either a fetchable url or base64 file content. Fields not present in the document are null — never guessed. Each successful extraction bills one document.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL of the document to fetch and extract | |
| base64 | No | Base64-encoded file content (alternative to url) | |
| filename | No | Filename including extension, e.g. shipment-4711.pdf |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-idempotent, non-destructive, and open-world behavior. The description adds valuable context: automatic doc_type detection, null fields for missing data, never guesses, and billing per extraction. No contradictions 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 a single paragraph that efficiently packs key information: document types, size limit, input options, automatic detection, null behavior, and billing. No redundancy, but could be slightly better structured with bullet points or separation of concerns.
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?
While the description covers input constraints and high-level behavior, it lacks details on the actual output structure (the fields extracted beyond doc_type). With no output schema, this information would help the agent understand what to expect from a successful extraction.
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 descriptions for url, base64, and filename. The description goes beyond the schema by clarifying usage (provide url or base64, filename needed) and adding constraints (max 10 MB, document types). This adds meaningful guidance beyond the raw 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 uses specific verbs like 'extract structured data' and clearly names the resource (freight documents: Bill of Lading, commercial invoice, packing list, CMR road waybill). It distinguishes itself from siblings by specifying single document extraction, unlike extract_batch which does batch processing.
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 when to use (for extracting data from freight documents) and provides constraints (max size, input options url/base64, document type auto-detected). It does not contrast with sibling tools like extract_batch, leaving that inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_documentGet extraction resultARead-onlyInspect
Get the extraction result for a document by id: doc_type, extracted fields, user corrections (when present), and deterministic verification warnings (ISO 6346 container check digits, plausibility flags). fields is the best available data (corrections win); original_fields and corrected_fields show both sides.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Document id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by explaining the return structure, the precedence rules for fields (corrections win), and the distinct roles of original_fields and corrected_fields. It also mentions specific verification warnings (ISO 6346 container check digits, plausibility flags), providing rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with high information density. The first sentence states the main purpose and lists contents; the second explains data structure and precedence. No unnecessary words, well front-loaded.
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 compensates by detailing return fields (doc_type, extracted fields, corrections, verification warnings) and their relationships. It could mention error cases or id format, but overall it is sufficiently complete for a simple single-param 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?
With only one parameter (id) and 100% schema coverage, the description does not add significant meaning beyond the schema's 'Document id'. Baseline 3 is appropriate as the schema already documents the parameter adequately.
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 retrieves the extraction result for a document by id, listing specific contents (doc_type, extracted fields, user corrections, verification warnings). It distinguishes from sibling tools like list_documents (which lists documents) and save_corrections (which saves corrections).
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 use when you have a document id and need extraction results, but it does not explicitly state when to use this tool versus alternatives like list_documents or extract_batch. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_usageCheck credits and subscriptionARead-onlyInspect
Check this account's remaining prepaid credits and subscription status. Call this before large batches to avoid running out of credits mid-workflow. When the account cannot bill more documents, a human can top up at the returned buy_credits_url.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. Description adds that it returns a buy_credits_url for topping up, and explains it checks prepaid credits and subscription status, enhancing transparency. 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?
Three concise, front-loaded sentences. Each sentence adds value: purpose, when to use, and what happens if out of credits. No 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?
For a zero-parameter, read-only tool, the description covers key aspects: what is checked, why to call, and an important output element (buy_credits_url). Documenting return format more explicitly could improve, but sufficient.
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?
No parameters in input schema, so baseline 4 applies. No need for parameter details.
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 account's remaining prepaid credits and subscription status. The verb 'check' and resource 'credits and subscription' are specific. Among sibling tools (export_documents, extract_batch, etc.), this is unique and well-distinguished.
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 advises to call before large batches to avoid running out of credits mid-workflow. Also mentions fallback action (human top-up via buy_credits_url). No explicit when-not-to-use, but tool's simplicity and uniqueness make it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_documentsList documentsARead-onlyInspect
List the 100 most recent documents for this account with id, filename, status (pending/done/failed), doc_type and primary reference number.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, which is consistent. The description adds behavioral details: returns only 100 most recent documents and specific field names. No contradictions or omissions about 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?
Single, well-structured sentence. Front-loaded with the action and limit, then lists fields. No unnecessary 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 no output schema, the description adequately describes the return fields and the limit (100 most recent). This is complete for a list tool with sibling tools covering other use cases.
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?
No parameters exist, so the schema description coverage is 100%. Baseline is 4 for zero parameters. The description does not need to add parameter details.
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 (List), resource (documents), and scope (100 most recent, per account), and lists the returned fields (id, filename, status, doc_type, primary reference number). This distinguishes it from siblings like get_document or export_documents.
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 implicitly suggests use for listing recent documents but does not provide explicit guidance on when to use this tool versus alternatives like get_related_documents or when not to use it. No when-to-use or when-not-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_correctionsSave field correctionsAIdempotentInspect
Save corrected field values for an extracted document. The original extraction is kept alongside the corrections; corrected data takes precedence in get_document, exports and reconciliation. Pass the complete corrected fields object (same shape as returned by get_document).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Document id | |
| fields | Yes | Complete corrected fields object, including doc_type |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark it as idempotent and non-destructive. The description adds valuable context: original extraction is preserved, corrections override in get_document, exports, and reconciliation. No contradictions 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?
Two sentences deliver purpose, behavior, and input requirements without any extraneous information. Every word adds value.
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 save operation with two parameters and no output schema, the description fully explains the effect (corrections take precedence) and input expectations. No gaps remain given 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?
Schema coverage is 100% with adequate descriptions. The description adds extra guidance by requiring the fields object to have the same shape as get_document's output, which helps the agent construct correct input.
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 saves corrected field values for extracted documents, explaining that corrections coexist with originals and take precedence in downstream operations. This distinguishes it from retrieval tools like get_document and export tools like export_documents.
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 specifies to pass the complete corrected fields object matching get_document's shape, providing clear usage context. While it doesn't explicitly list when not to use or alternatives, the purpose is narrowly defined and practical.
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!