Skip to main content
Glama
Sign In
bosch-flow-mcp

bosch-flow-mcp

by partymola
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

bosch_get_components

Retrieve registered Bosch eBike components with part, serial, and firmware versions to track firmware updates and identify parts for warranty or service. Filter by bike or component type.

Instructions

List registered components for your Bosch eBike with software versions.

Shows the bike's components - drive unit, battery, ConnectModule, head unit, remote control, ABS - with part numbers, serial numbers, and firmware versions. The source depends on your sign-in: a standard Bosch eBike Flow account reads them from the bike profile (mobile app API); an EU Data Act (euda) client reads them from the Data Act registrations endpoint.

Useful for tracking firmware versions and identifying components for warranty or service purposes.

Args: bike_id: Optional bike UUID to filter to one bike. component_type: Optional component type filter, e.g. "driveUnit", "battery", "headUnit", "connectedModule", "remoteControl". Matched against the types your bikes registered, ignoring case, so every stored spelling of a type answers together. A value none of them match is refused, naming the types that are held.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "bosch_get_components"
  }
}

Input Schema

NameRequiredDescriptionDefault
bike_idNo
component_typeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.10.0
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "bosch_get_componentsOutput",
-  "type": "object"
-}New value: +null
  2. Addedv0.2.3
  3. Removedv0.2.2
  4. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations supplied, the description does real work: it discloses that the backing endpoint changes with sign-in (bike profile via mobile app API vs EU Data Act registrations endpoint) and that an unmatched component_type filter is rejected with a message naming the held types. It omits pagination/result limits and any explicit permission or rate-limit behavior, 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.

Conciseness4/5

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

Front-loaded with the action and returned data, then source behavior, then use cases, then Args — a workable structure. The Args block restates material already covered in the prose (component types appear twice), so a little trimming is possible, but no sentence is filler.

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?

There is no output schema, and the description compensates by naming the fields returned and the two possible data sources. For a two-optional-parameter read tool this is close to sufficient; only pagination/volume expectations are left unaddressed.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must carry the load, and it largely does: bike_id is described as an optional UUID filter to a single bike, and component_type is given example values, case-insensitive matching semantics, and defined error behavior. The example type list omits "ABS" mentioned earlier in the body, and neither parameter's omitted-value default is spelled out explicitly.

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?

Opens with a specific verb+resource ("List registered components for your Bosch eBike") and immediately enumerates both the component kinds returned (drive unit, battery, ConnectModule, head unit, remote control, ABS) and the fields (part numbers, serial numbers, firmware versions). This clearly separates it from siblings such as bosch_get_software_updates and bosch_get_batteries.

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

Usage Guidelines3/5

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

The description gives a purpose-driven context ("useful for tracking firmware versions and identifying components for warranty or service purposes") and explains the sign-in-dependent source, which implies when it applies. However, it never names an alternative or states when NOT to use it — e.g., nothing tells the agent to prefer bosch_get_software_updates for update history rather than current firmware versions.

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

Deploy Server

Other Tools