Skip to main content
Glama

ServiceSchedule

by io.github.everyai-com
OverviewDiscussionsAdmin

Service timeline

service_timeline
Read-onlyIdempotent

Project the next 12 months of driving and list which maintenance services fall due in each month, from the odometer and monthly distance. Use when planning maintenance over the coming year. Do NOT use for what is due right now (use due_services) or prices (use service_cost_estimate).

Input Schema

NameRequiredDescriptionDefault
unitNoUnit of the odometer value: 'km' (default) or 'mi'
odometerYesCurrent odometer reading, non-negative, in the unit given by unit, e.g. 48000
km_per_monthYesAverage distance driven per month in km (always km, 100-10000), e.g. 1200
months_since_last_oilNoMonths since the last oil change; time baseline for every service, default 0

Output Schema

NameRequiredDescriptionDefault
noteYesAssumptions behind the projection
monthsYesTwelve monthly entries, month 1 = next month

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • changedInput schema / properties / km_per_month / description
      Previous value: -"Average km driven per month (100-10000)"New value: +"Average distance driven per month in km (always km, 100-10000), e.g. 1200"
    • addedInput schema / properties / km_per_month / maximum
      Added value: +10000
    • addedInput schema / properties / km_per_month / minimum
      Added value: +100
    • changedInput schema / properties / months_since_last_oil / description
      Previous value: -"Months since the last oil change; time baseline when no other history is given"New value: +"Months since the last oil change; time baseline for every service, default 0"
    • addedInput schema / properties / months_since_last_oil / minimum
      Added value: +0
    • changedInput schema / properties / odometer / description
      Previous value: -"Current odometer reading"New value: +"Current odometer reading, non-negative, in the unit given by unit, e.g. 48000"
    • addedInput schema / properties / odometer / minimum
      Added value: +0
    • changedInput schema / properties / unit / description
      Previous value: -"Unit of the odometer values, default km"New value: +"Unit of the odometer value: 'km' (default) or 'mi'"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "months": {
+      "description": "Twelve monthly entries, month 1 = next month",
+      "items": {
+        "properties": {
+          "due": {
+            "description": "Service ids due that month",
+            "items": {
+              "enum": [
+                "oil_change",
+                "tire_rotation",
+                "brake_inspection",
+                "air_filter",
+                "cabin_filter",
+                "coolant_service",
+                "spark_plugs",
+                "transmission_service",
+                "battery_check"
+              ],
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "month": {
+            "description": "Months from now, 1-12",
+            "type": "integer"
+          },
+          "projected_km": {
+            "description": "Projected odometer in km at that month",
+            "type": "number"
+          }
+        },
+        "required": [
+          "month",
+          "projected_km",
+          "due"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "note": {
+      "description": "Assumptions behind the projection",
+      "type": "string"
+    }
+  },
+  "required": [
+    "months",
+    "note"
+  ],
+  "type": "object"
+}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "results": {
-      "description": "List of service timeline entries.",
-      "items": {
-        "properties": {
-          "month": {
-            "description": "The month in the 12-month projection (1-12)",
-            "type": "integer"
-          },
-          "odometer": {
-            "description": "Projected odometer reading at the start of the month",
-            "type": "number"
-          },
-          "services_due": {
-            "description": "List of maintenance services due in the month",
-            "items": {
-              "description": "Name of the service",
-              "type": "string"
-            },
-            "type": "array"
-          }
-        },
-        "required": [
-          "month",
-          "odometer",
-          "services_due"
-        ],
-        "type": "object"
-      },
-      "type": "array"
-    }
-  },
-  "required": [
-    "results"
-  ],
-  "type": "object"
-}New value: +null
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "results": {
+      "description": "List of service timeline entries.",
+      "items": {
+        "properties": {
+          "month": {
+            "description": "The month in the 12-month projection (1-12)",
+            "type": "integer"
+          },
+          "odometer": {
+            "description": "Projected odometer reading at the start of the month",
+            "type": "number"
+          },
+          "services_due": {
+            "description": "List of maintenance services due in the month",
+            "items": {
+              "description": "Name of the service",
+              "type": "string"
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "month",
+          "odometer",
+          "services_due"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "results"
+  ],
+  "type": "object"
+}
  4. First observed

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds value beyond them by disclosing the projection horizon (12 months) and the fact that results are derived from odometer plus monthly distance, i.e. it is a forecast rather than a lookup. It does not discuss limits on the forecast or the assumptions behind the projection, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with what the tool produces before the routing constraints. No filler, no restatement of the title, and every sentence carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and full parameter documentation, the description need not explain return values, and it covers purpose, usage and alternatives. The one omission is any mention of months_since_last_oil's role as the time baseline for every service, which materially shapes the projection but is left entirely to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents unit, odometer, km_per_month and months_since_last_oil including ranges and defaults. The description only restates that odometer and monthly distance drive the result; it adds no syntax or unit nuance (e.g. that km_per_month is always km while unit applies only to the odometer). Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('project the next 12 months of driving and list which maintenance services fall due in each month') plus the derivation basis (odometer and monthly distance). It is immediately distinguishable from due_services and service_cost_estimate, which are named in the same paragraph.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use ('planning maintenance over the coming year') and explicit when-not-to-use with named alternatives: 'Do NOT use for what is due right now (use due_services) or prices (use service_cost_estimate)'. All routing decisions are pre-made for the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ServiceSchedule toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources