Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fleetsync-mcp Show me all deliveries scheduled for tomorrow."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that exposes the FleetSync last-mile delivery platform to AI agents — enabling LLMs to query orders, manage routes, track drivers, and analyse delivery performance through natural language.
Turns a logistics platform into a conversational interface. A dispatcher, operations manager, or automated agent can ask questions like:
"What orders are scheduled for tomorrow?"
"Show me all deliveries on route R-04"
"Which routes today have stops more than 10km apart?"
"Create a new delivery order for customer João, Rua das Flores 12, for Friday"
...and get structured, actionable answers — without opening the dashboard.
Related MCP server: Easyship MCP
flowchart LR
A[AI Agent\nClaude / n8n / Custom] -->|MCP tool call| B[fleetsync-mcp\nMCP Server]
B -->|REST API| C[FleetSync\nAPI v2]
C -->|JSON response| B
B -->|structured result| A
subgraph Tools
direction TB
T1[Orders\nget · create · update · delete]
T2[Routes\nget · create · update · delete]
T3[Analytics\nanalyse route distances]
T4[Drivers\nlist drivers]
endTool | Description |
| Get order by number — status, client, address, driver, proof of delivery |
| Get all orders scheduled for a date |
| Get all orders assigned to a route code |
| Get orders with status changes after a datetime (last 24h max) |
| Get the last 25 history entries for an order |
| Create a new unscheduled order |
| Update an existing order's fields |
| Delete an order (irreversible) |
Tool | Description |
| List all routes |
| Get all routes for a date with driver and order count |
| Get a specific route by code |
| Get orders grouped by route for a date |
| Create a new route with optional driver, vehicle, and orders |
| Update an existing route |
| Delete a route (irreversible) |
Tool | Description |
| Compute haversine distances between consecutive stops. Flags pairs exceeding a configurable threshold (default: 5km). Returns total km, avg km, max km, and all violations |
Tool | Description |
| List all drivers with vehicle, phone, and active status |
| Validate API credentials and check rate limits |
Component | Tool |
Protocol | |
Language | TypeScript 5 + Node.js |
Schema validation | |
Logistics platform | FleetSync API v2 |
Node.js 18+
FleetSync account with API key
git clone https://github.com/RobsonAdvincula/fleetsync-mcp.git
cd fleetsync-mcp
npm install
npm run buildFLEETSYNC_API_KEY=your_api_key
FLEETSYNC_BASE_URL=https://api.fleetsync.io/v2Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"fleetsync": {
"command": "node",
"args": ["/path/to/fleetsync-mcp/dist/index.js"],
"env": {
"FLEETSYNC_API_KEY": "your_api_key"
}
}
}
}Operations check:
User: "How many deliveries do we have tomorrow and which routes are active?"
→ fleetsync_orders_by_date({ date: "2026-03-26" })
← { count: 47, orders: [...] }
→ fleetsync_routes_by_date({ date: "2026-03-26" })
← { count: 4, routes: [{ code: "R-01", driver: "...", orders: 12 }, ...] }
Agent: "47 orders across 4 active routes tomorrow. Route R-03 has the most stops (18)."Route quality check:
User: "Is route R-04 well optimised?"
→ fleetsync_analyze_route_distances({ code: "R-04", maxDistanceKm: 8 })
← {
total_km: 34.2,
avg_km: 2.1,
violations_count: 2,
violations: [
{ from: "ORD-112", to: "ORD-113", km: 11.4 },
{ from: "ORD-118", to: "ORD-119", km: 9.7 }
]
}
Agent: "Route R-04 has 2 problematic segments exceeding 8km. Consider reordering stops 112→113 and 118→119."The fleetsync_analyze_route_distances tool uses the Haversine formula to compute great-circle distances between consecutive delivery stops using their GPS coordinates.
distance = 2R × arcsin(√(sin²(Δlat/2) + cos(lat₁)cos(lat₂)sin²(Δlon/2)))Output includes per-segment distances, total route km, and a list of all threshold violations — useful for identifying poorly sequenced routes before dispatch.
MIT — free to use, adapt, and build on.
Built by Robson Advincula — AI & Automation Consultant
Analyze distances between consecutive orders in a route. Flags order pairs exceeding the distance threshold. Useful for diagnosing poorly optimized routes.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Route code to analyze distances between consecutive orders | |
| maxDistanceKm | No | Max acceptable distance in km between orders (default: 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 of explaining behavior. It does not disclose whether the tool is read-only, what it returns beyond 'flags order pairs,' or any side effects like logging or modifying data. The vague output description leaves important gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main action, and contains no filler. Every sentence 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 tool with no output schema and no annotations, the description provides the core purpose and use case but omits details about return format, error behavior, or whether the tool modifies data. It is adequate for a simple analysis tool 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?
Both parameters are fully described in the schema (100% coverage), so the baseline is 3. The tool description adds minimal semantic value beyond the schema, only reinforcing the concept of consecutive orders and threshold, which are already captured.
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 a specific verb ('Analyze') and resource ('distances between consecutive orders in a route'), and clearly distinguishes this tool from sibling retrieval tools. It also explains the core outcome ('Flags order pairs exceeding the distance threshold').
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 provides clear context for when to use the tool: 'Useful for diagnosing poorly optimized routes.' However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new unscheduled order in FleetSync. Requires: Number (max 50 chars), Client, Address, Date (YYYY-MM-DD). Optional: Phone, Email, Note.
| Name | Required | Description | Default |
|---|---|---|---|
| Date | Yes | Delivery date in YYYY-MM-DD format | |
| Note | No | Order notes | |
| No | Client email | ||
| Phone | No | Client phone number | |
| Client | Yes | Client name | |
| Number | Yes | Order number (max 50 chars) | |
| Address | Yes | Delivery address |
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 lists required/optional fields and format constraints, but it does not describe side effects, response behavior, or any post-creation details. The agent is left unaware of what happens after the order is created or what the return value will be.
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, front-loaded with the action and then listing requirements and optional fields. Every sentence earns its place, with 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?
For a simple create operation, the description covers the necessary input fields and constraints. However, with no output schema, it lacks information about the expected response, whether the order is automatically linked to a route, or any potential validation rules beyond the listed constraints.
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 the schema already documents all parameters. The description groups fields into required and optional, which is helpful, but it does not add meaning beyond the schema (e.g., Number max length and Date format are already in schema descriptions).
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 'Create a new unscheduled order in FleetSync', using a specific verb and resource. It distinguishes from sibling tools such as fleetsync_update_order and fleetsync_delete_order by indicating this is the creation operation.
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 does not explicitly mention when to use this tool versus alternatives. It implies use for creating unscheduled orders but does not provide exclusions or alternative tool guidance, such as pointing to fleetsync_create_route for scheduled orders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new route in FleetSync. Requires Code and Date. Optional: DriverName, DriverVehicle, Depot, Orders. Query options: update, updateAddressGps, mergeAddresses.
| Name | Required | Description | Default |
|---|---|---|---|
| Code | Yes | Route code (unique identifier) | |
| Date | Yes | Route date in YYYY-MM-DD format | |
| Depot | No | Depot/start address for the route | |
| Orders | No | Array of order objects to include | |
| update | No | Add/remove orders if route exists on this date | |
| DriverName | No | Driver name to assign | |
| DriverVehicle | No | Vehicle plate number (e.g. 'BU-36-FS') | |
| ReturnToDepot | No | Whether to return to depot | |
| StartFromDepot | No | Whether to start from depot | |
| mergeAddresses | No | Merge orders by address onto one site (default true) | |
| updateAddressGps | No | Force update lat/lon in address directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It does mention query options (update, updateAddressGps, mergeAddresses) which hint at behaviors like merging addresses or updating GPS, but it does not explain side effects, return values, or edge cases. This partial disclosure is better than nothing but leaves 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, two sentences that front-load the purpose and follow with essential requirements and options. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and no annotations, the description is surprisingly brief. It gives the essential creation context and lists parameters, but lacks guidance on response behavior, potential updates if the route exists, or any constraints. The schema mitigates parameter confusion, but the tool-level context remains thin.
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 covers all 11 parameters with descriptions (100% coverage). The tool description merely lists a subset of optional fields and query options without adding any new meaning or constraints beyond the schema. Baseline of 3 is appropriate since schema handles the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new route in FleetSync', which is a clear, specific verb+resource statement. It distinguishes from sibling tools (get, update, delete) and includes key prerequisites (Requires Code and Date).
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 this is for creating a new route and lists required and optional fields, giving practical context. However, it does not explicitly mention alternatives or when not to use the tool, such as references to fleetsync_update_route for existing routes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a FleetSync order by its number. This action is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | Order number to delete |
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 warns that the action is irreversible, which is important for a destructive operation. It does not mention other behaviors such as whether the order must exist or what happens to related data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary action and followed by a critical warning. Every word earns its place; no redundancy or unnecessary detail.
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 simple delete tool with one parameter and no output schema, the description covers the essential context: what is deleted, how it is identified, and the irreversible consequence. It does not address error cases or side effects, but these are not clearly required for completeness 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?
The schema already fully describes the single parameter 'number' with 100% coverage. The description's phrase 'by its number' adds minimal extra meaning 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (FleetSync order) with a specific input (by its number). It distinguishes itself from sibling tools like get_order, create_order, and update_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 usage is implied by the verb 'delete' — use this tool when you need to permanently remove an order. However, there is no explicit guidance on when not to use it, prerequisites, or alternatives (e.g., updating or soft-deleting).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a FleetSync route by its code. This action is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Route code to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses 'This action is irreversible,' a key behavioral trait. However, it does not mention authorization requirements, side effects on dependent orders, or what the response contains. These omissions leave room for improvement, though the irreversibility statement adds real value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences front-load the core action ('Delete a FleetSync route') and then add the consequence ('irreversible'). No filler or repetition.
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 single-parameter delete operation, the description is nearly complete: it identifies the target, the identifier, and the irreversible side effect. It does not specify return semantics or error handling, but no output schema exists; still, the core information is sufficient for selection and 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 coverage is 100% with the 'code' parameter described as 'Route code to delete.' The description's phrase 'by its code' adds no new semantic meaning beyond the schema. Baseline of 3 applies when schema fully documents parameters.
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 explicitly states 'Delete a FleetSync route by its code' – a specific verb and resource, clearly distinguishing it from siblings like fleetsync_create_route or fleetsync_update_route. The irreversibility warning further clarifies the action's nature.
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 guidance is provided on when to use this tool versus alternatives such as fleetsync_update_route for modifications or fleetsync_delete_order for orders. No prerequisites or conditions (e.g., whether the route must be inactive) are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all FleetSync drivers. Returns list of drivers with their names, vehicles, phones, and active status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 explicitly states that the tool returns a list and details the fields included, which provides transparency about the output. It does not mention error handling or pagination, but since the tool takes no parameters, a full list retrieval is the expected behavior.
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 concise sentences that directly communicate the purpose and return content. Every word adds value, with no filler or redundant 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?
For a zero-parameter tool with no output schema, the description is complete. It specifies exactly what the returned list contains, and the lack of parameters means no additional context is needed. The tool is simple, and the description fully covers it.
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 and the schema is empty, so there is nothing to add beyond what the schema already shows. The baseline for zero parameters is 4, and the description appropriately avoids inventing non-existent parameters.
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 action ('Get all FleetSync drivers') and the specific resource it targets. It also enumerates the returned data fields (names, vehicles, phones, active status), making its purpose unmistakable and distinct from sibling tools that handle routes or 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?
The description implies the tool is for retrieving the full list of drivers, which is a clear usage context. It does not explicitly name alternatives or exclusions, but given that no sibling tool for drivers exists, the intended use is self-evident and requires no further guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a FleetSync order by its number. Returns order details including status, client, address, delivery date, driver, and proof of delivery info.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | Order number (e.g. 'EVREMMA2026000105') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It describes the return content (status, client, address, delivery date, driver, proof of delivery), which is useful. It doesn't mention error handling or side effects, but for a simple read operation this is acceptable.
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 the purpose, followed by return details. 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?
For a simple getter with one parameter, the description covers the purpose, the key parameter, and the return fields. There is no output schema, but the listed fields provide adequate expectations. It is sufficiently 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 schema already fully documents the 'number' parameter with an example, so the description adds no additional semantic value beyond what is in 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 uses a specific verb 'Get' and resource 'FleetSync order' with the lookup key 'number', clearly distinguishing it from sibling tools like get_routes and orders_by_date. It also lists the returned fields, making the purpose unambiguous.
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 states the tool fetches an order by its number, implying it is used when the user has the order number. However, it does not explicitly contrast with alternatives like orders_by_date or orders_by_route, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific FleetSync route by its code. Returns route details, driver assignment, orders, and status.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Route code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers the tool's behavior by stating it returns route details, driver assignment, orders, and status. It does not explicitly mention side effects or errors, but as a 'get' operation it is implied to be read-only. It adds value by specifying the return scope.
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 short sentences, front-loaded with the action and resource. Every word adds value, including the list of returned data, with no filler or repetition.
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 simple one-parameter schema and no output schema, the description is complete enough: it identifies the tool, the input, and the expected output content. It doesn't introduce unnecessary prerequisites or caveats.
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 fully documents the 'code' parameter at 100% coverage, so the description adds little beyond naming the lookup key. Baseline of 3 applies since the schema already handles parameter semantics.
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 gets a specific route by code, and distinguishes from siblings like fleetsync_get_routes (plural) by specifying 'specific' and 'by its code.' It also previews the return content, making the purpose unequivocal.
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 for retrieving a single route by its code, but does not provide explicit exclusions or alternative tool references. Since siblings exist for listing all routes or routes by date, the guidance is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all FleetSync routes. Returns a list of all route summaries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 return type (a list of route summaries), which is a useful detail, but it omits any mention of side effects, pagination, ordering, or limitations. The 'Get' verb implies a read-only operation, but the description adds modest value beyond that.
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 short sentences with no filler. It front-loads the action in the first sentence and the return value in the second, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter list-all tool, the description covers the essential behavior and return value. However, with no output schema, it could enhance completeness by explaining what a 'route summary' contains or noting ordering/pagination. Still, it is nearly sufficient for this 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?
The tool has zero parameters and the schema is empty (100% coverage). According to the rubric, a 0-parameter tool earns a baseline of 4. The description correctly provides no parameter details since there are none to explain.
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 gets all FleetSync routes and returns a list of route summaries. The use of 'all' distinguishes it from the singular 'fleetsync_get_route' sibling, making the purpose 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.
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 'fleetsync_routes_by_date' or 'fleetsync_get_route'. The description only states what it does, leaving the agent to infer usage without explicit exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the history of a FleetSync order (last 25 entries). Useful for tracking changes and re-deliveries.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | Order number to get history (last 25 entries) |
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 mentions the 'last 25 entries' limit, which is helpful. However, it does not explicitly state that the tool is read-only or describe potential edge cases (e.g., invalid order number). The description gives basic transparency but lacks explicit safety or error behavior.
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 concise sentences, front-loaded with the core function and then a brief use case. There is no fluff or redundant information, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the response looks like, but it only says 'history' without detailing the structure or contents of each entry. It includes the 'last 25 entries' limitation and a use case, but for a tool with no output schema, the return format is left vague. This is a noticeable gap.
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 schema description for the parameter 'number' already states 'Order number to get history (last 25 entries),' which is nearly identical to the tool description. Since schema coverage is 100%, the description adds little extra meaning beyond what the schema provides. The baseline 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 function: 'Get the history of a FleetSync order (last 25 entries).' It uses a specific verb ('Get') and resource ('history of a FleetSync order'), and mentions the scope ('last 25 entries'). It also provides a use case ('tracking changes and re-deliveries'), which helps distinguish it from sibling tools like fleetsync_get_order or fleetsync_orders_status_changes.
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 phrase 'Useful for tracking changes and re-deliveries' gives clear context for when to use this tool. However, it does not explicitly mention alternatives or exclusions, such as 'For status changes only, use fleetsync_orders_status_changes.' This is clear context without explicit exclusions, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all FleetSync orders for a specific date. Returns list of orders scheduled for that day with their statuses.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date in YYYY-MM-DD format (e.g. '2026-02-10') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return behavior ('Returns list of orders scheduled for that day with their statuses') but does not mention additional traits like pagination, timezone handling, or whether cancelled/future orders are included. Since no annotations are provided, the description carries the full burden but does minimally.
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, front-loaded with the key action, and contains no redundant information. Every word contributes to understanding the tool's purpose.
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 (one parameter, no output schema). The description adequately explains the return type and scope. It could detail ordering or included fields, but for a low-complexity get tool, it is nearly 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% for the single parameter 'date', and the schema fully describes format and example. The description does not add extra parameter semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get all FleetSync orders') and scope ('for a specific date'), which distinguishes it from siblings like fleetsync_orders_by_route and fleetsync_orders_by_route_date. The verb+resource+modifier structure is unambiguous.
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 provides clear context: use this tool when you need orders for a specific date. It does not explicitly mention alternatives or when not to use it, but the context is specific enough to guide selection. Lacks exclusions, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all FleetSync orders assigned to a specific route by its code.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Route code |
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 implies a read-only operation via 'Get all' but does not disclose additional traits like whether all order statuses are included or how results are ordered. This is minimally adequate for a simple 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler, correctly front-loading the verb and resource. 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?
For a one-parameter tool with no output schema, the description gives a complete statement of purpose. However, it lacks any details about return format, pagination, or error behavior, which would improve completeness. A score of 3 reflects this acceptable but not thorough coverage.
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%, with the 'code' parameter described as 'Route code'. The tool description adds no extra parameter context, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('all FleetSync orders assigned to a specific route by its code'). It distinguishes from sibling tools like fleetsync_orders_by_date and fleetsync_get_order by specifying the route-code filter.
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 guidance is provided on when to use this tool versus alternatives, nor any mention of exclusions or preferred scenarios. The description simply states what it does, leaving the decision entirely 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 all FleetSync orders for a specific date grouped by their assigned routes.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date in YYYY-MM-DD format to get orders grouped by route |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of conveying behavioral traits. 'Get' clearly indicates a read-only operation with no side effects. The description discloses the grouping behavior ('grouped by their assigned routes'), which adds useful context. It does not mention pagination or response ordering, but for a simple read operation this is adequate.
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 one sentence, front-loaded with the verb 'Get', and contains no redundant information. 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?
Given the low complexity (one parameter, no output schema) and the annotation-free context, the description is sufficiently complete. It conveys the purpose and the key grouping behavior. It does not describe return value structure, but the grouping mention implies the response format. Overall, it provides the essential information an agent needs.
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 already provides a complete description of the sole parameter ('Date in YYYY-MM-DD format to get orders grouped by route'), achieving 100% schema coverage. The tool description does not add additional parameter semantics beyond what the schema provides, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all FleetSync orders for a specific date grouped by their assigned routes' clearly states the verb (Get), the resource (orders), and the specific criteria (date and grouping). It distinguishes itself from siblings like fleetsync_orders_by_date (which likely does not group by route) and fleetsync_orders_by_route (which likely filters by a single route).
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 for date-based retrieval with route grouping, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative recommendations are provided, leaving the agent to infer based on the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get FleetSync orders that had status changes after a specific date/time. Useful for checking recently delivered/updated orders. Date format: YYYY-MM-DDTHH:mm:ss. Minimum: UTC - 1 day.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date/time in YYYY-MM-DDTHH:mm:ss format. Returns orders with status changes after this date. Min: UTC - 1 day. |
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 discloses the date format and the 'Minimum: UTC - 1 day' constraint, which is important behavioral context. However, it does not mention pagination, response shape, or any limitations beyond the date restriction. The description is transparent about the core behavior but leaves some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with three short sentences covering purpose, use case, and parameter constraints. Every sentence provides useful information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only query tool with one parameter and no output schema, the description covers the essential context: what it does, when to use it, and the input format/constraints. It lacks details about the response structure or pagination, but given the simplicity, the description is nearly 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 description coverage is 100%: the parameter 'date' is fully described in the schema with the same information (format, meaning, minimum constraint). The tool description adds no additional semantic value beyond what the schema already provides. Per the rubric, a baseline 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 function: 'Get FleetSync orders that had status changes after a specific date/time.' This is a specific verb+resource+scope, and the emphasis on 'status changes' distinguishes it from sibling tools like fleetsync_orders_by_date or fleetsync_order_history. The purpose is immediately understandable and non-tautological.
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 provides a clear use case: 'Useful for checking recently delivered/updated orders.' This indicates when to use the tool, though it does not explicitly exclude alternatives or mention when not to use it. Given the sibling tools, this guidance is helpful but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all FleetSync routes for a specific date. Returns route details including driver, status, and order count.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date in YYYY-MM-DD format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosure. It does state what the response includes ('driver, status, and order count'), which is useful. However, it omits details about pagination, authentication, rate limits, or any side effects. For a simple read operation, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the primary function. It is concise with no fluff, earning the highest score for efficiency.
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 (one parameter, no output schema, no annotations), the description covers the essential aspects: what it does and what it returns. It does not need to explain return values in detail since no output schema exists, but it could have referenced sibling tools for better navigation. Still, it is sufficiently complete for a simple query 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?
The schema covers 100% of parameters with the 'date' field described as 'Date in YYYY-MM-DD format'. The description adds little beyond the schema, merely reiterating that the tool is for a specific date. Since schema coverage is full, the baseline 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 ('Get'), resource ('all FleetSync routes'), and qualifier ('for a specific date'), making it easy to understand the tool's purpose. It also distinguishes itself from sibling tools like fleetsync_get_routes (which likely retrieves all routes without a date filter) and fleetsync_get_route (single route).
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 provides clear context that this tool should be used to fetch routes for a specific date, implying a filtering use case. However, it does not explicitly mention when not to use it or name alternative tools, such as fleetsync_orders_by_date for orders on a date, though the context is clear enough for an agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test FleetSync API authentication and check rate limits.
| 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 bears full responsibility for disclosing behavior. It only states the intended action ('Test' and 'check') but does not mention what the tool returns, whether it makes external calls, whether it has side effects, or how the agent should interpret the result. This is a significant transparency gap for a diagnostic 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 a single, front-loaded sentence that conveys both core functions efficiently. Every word earns its place, with no redundancy or filler, achieving ideal 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?
For a simple zero-parameter tool with no output schema, the description should explain what the agent can expect from the response (e.g., success/failure indication, rate limit numbers, error format). It does not, leaving the agent without critical information to act on the tool's result. The description is too thin for complete operational use.
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, and the schema coverage is trivially 100%. The baseline for zero-parameter tools is 4, and since no parameters exist, the description does not need to add parameter details. It appropriately avoids inventing false semantics.
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 verb ('Test' and 'check') and resource (FleetSync API authentication and rate limits). It is immediately distinguishable from all sibling tools, which concern routes, orders, or drivers rather than API diagnostics.
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 provides strong contextual clarity: this tool is for verifying authentication and checking rate limits. While it does not explicitly exclude alternatives, the purpose implicitly signals when to use it (e.g., troubleshooting auth issues) and no sibling offers a similar diagnostic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing FleetSync order. Requires: Number. Optional fields to update: Client, Address, Phone, Email, Date, Note.
| Name | Required | Description | Default |
|---|---|---|---|
| Date | No | Delivery date in YYYY-MM-DD format | |
| Note | No | Order notes | |
| No | Client email | ||
| Phone | No | Client phone number | |
| Client | No | Client name | |
| Number | Yes | Order number to update | |
| Address | No | Delivery address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It communicates that the tool updates an existing order and requires a Number, but it does not disclose partial-update semantics, error handling for missing orders, or return value behavior.
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, front-loaded sentence that immediately states the action and resource. It leads with the core purpose and lists additional details without unnecessary wording.
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 simple update operation and full schema coverage, the description adequately explains what the tool does and what is needed to invoke it. It lacks return-value or error-behavior information, but those are not critical for a straightforward update 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?
The input schema already describes all parameters with 100% coverage, so the description adds no new semantic detail. It restates the required Number and lists optional fields, but this adds no value 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 uses the specific verb 'update' with the resource 'FleetSync order', clearly distinguishing it from sibling create/delete/get tools. It also enumerates the exact fields available for update, removing ambiguity about scope.
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 parameter (Number) and lists optional updatable fields, giving clear operational guidance. It does not explicitly compare against sibling tools, but the phrase 'existing FleetSync order' implies it should not be used for creation or deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing FleetSync route. Requires Code. Optional: Date, DriverName, DriverVehicle, Depot, Orders. Query options: update, updateAddressGps, mergeAddresses.
| Name | Required | Description | Default |
|---|---|---|---|
| Code | Yes | Route code to update | |
| Date | No | Route date in YYYY-MM-DD format | |
| Depot | No | Depot/start address | |
| Orders | No | Array of order objects | |
| update | No | Add/remove orders from route | |
| DriverName | No | Driver name | |
| DriverVehicle | No | Vehicle plate number | |
| mergeAddresses | No | Merge orders by address | |
| updateAddressGps | No | Force update lat/lon |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'Update an existing FleetSync route' and lists parameters, but does not disclose side effects, permission requirements, error behavior, or what happens when the route does not exist. This is insufficient for a mutation 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 one concise sentence, front-loaded with the purpose and followed by a clear enumeration of required and optional fields. 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?
Despite full schema coverage, the tool has 9 parameters, no output schema, and no annotations. The description does not explain return values, side effects, dependencies between parameters (e.g., whether update and mergeAddresses are mutually exclusive), or typical usage patterns. It feels incomplete for such a complex mutation 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%, so the schema already describes every parameter. The description adds little beyond what the schema provides, merely echoing the parameter names and optionality. It does not clarify the meaning of 'Query options' beyond their schema descriptions.
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: 'Update an existing FleetSync route.' This specifies the verb and resource, distinguishing it from sibling tools like create_route, delete_route, and get_route.
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 provides context by stating that Code is required and other fields are optional, but it does not explicitly mention when to choose this tool over alternatives or when not to use it. Usage is implied rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0fleetsync_analyze_route_distancesfleetsync_create_orderfleetsync_create_routefleetsync_delete_orderfleetsync_delete_routefleetsync_get_driversfleetsync_get_orderfleetsync_get_routefleetsync_get_routesfleetsync_order_historyfleetsync_orders_by_datefleetsync_orders_by_routefleetsync_orders_by_route_datefleetsync_orders_status_changesfleetsync_routes_by_datefleetsync_testfleetsync_update_orderfleetsync_update_routeMost tools are clearly distinct, but the overlapping query tools (orders_by_date vs orders_by_route_date, get_routes vs routes_by_date) could cause misselection if an agent doesn't read descriptions carefully. Each tool has a unique filter or aggregation purpose, so ambiguity is low but not absent.
All tools share the fleetsync_ prefix, but the verb_noun pattern is broken by query-style names like orders_by_date, orders_status_changes, order_history, and routes_by_date. This mixed convention reduces predictability, though the domain terms keep the names readable.
At 18 tools, the set is slightly over the ideal 3-15 range, but the count is justified by full CRUD for both orders and routes plus multiple query views and an analytics tool. Each tool has a clear purpose, so it feels slightly heavy rather than bloated.
The set covers CRUD for orders and routes, along with useful queries and distance analysis. However, order status cannot be updated (only read), route status is not manageable, and driver tools are limited to listing. This leaves significant gaps for agents needing to update delivery progress or assignments.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Field operations on a deterministic solver — run jobs, crews & fleet from Claude or ChatGPT.
Furgonetka MCP Server is an extension for LLMs (such as Claude) that integrates AI assistants with Poland's most popular courier brokerage platform. The server enables models to interact directly with services from various couriers (including InPost, DPD, DHL, UPS, and Poczta Polska) through a single, unified interface. With this integration, your AI stops just "writing about logistics" and starts actually managing it.
Route optimization for delivery fleets: plan, edit, and re-optimize multi-stop routes by prompt.
Give your AI agents the tools to build, manage, and run automation workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RobsonAdvincula/fleetsync-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
