ble-fleet-mcp

by JephinJose

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Each tool has a distinct role: register, scan, read, write, watch, status, pool_status, and operation_status. The three 'status' tools are differentiated by scope (device health vs. pool telemetry vs. batch progress), though the naming overlap could cause minor confusion.
Naming Consistency5/5
All tools share the 'fleet_' prefix and use consistent snake_case. Actions are verbs (register, scan, read, write, watch), while queries are nouns (status, pool_status, operation_status), forming a predictable pattern.
Tool Count5/5
Eight tools is well-scoped for a fleet management server, covering core operations without unnecessary bloat. Each tool serves a clear purpose in the lifecycle.
Completeness4/5
The set covers discovery, registration, read/write, watching, device health, pool telemetry, and operation tracking. Missing a deregister or fleet deletion operation is a minor gap, but the primary workflows are fully supported.
Average 3.9/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It states the output fields but does not explicitly indicate that the operation is read-only, has no side effects, or any authentication requirements. The read-only nature is implied but not stated.
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?
The description is a single sentence with no wasted words. It front-loads the purpose and lists the key output attributes compactly, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, output schema present), and the description covers the main output aspects. However, it lacks caveats about data freshness, behavior on non-existent fleets, or permissions, which would be valuable given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'fleet' is referenced as 'in a fleet' in the description, which confirms it is the target fleet, but adds little beyond the schema. The description does not explain the expected format (e.g., fleet ID vs name) or other constraints, leaving the parameter semantics minimally enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (fleet devices) and the information returned (health status, failure count, connectivity). It effectively distinguishes from sibling tools like fleet_operation_status or fleet_pool_status by focusing on device health, though it lacks an explicit verb like 'retrieves'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use fleet_status versus alternatives such as fleet_operation_status or fleet_pool_status. There are no stated prerequisites or exclusions, leaving the decision to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses an asynchronous behavior via 'operation snapshot keyed by operation_id' and lists per-device result statuses (success/unreachable/timeout/still_queued). However, it does not explain the operation lifecycle, how to retrieve final results, or any side effects/auth requirements.
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?
The description is two sentences, front-loaded with the core action, and every phrase adds value—scope ('across every device'), optional subsetting, and the response format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core read operation and result statuses, and an output schema exists to detail return values. However, the mention of 'operation_id' introduces a follow-up workflow (likely fleet_operation_status) that is not referenced, and key parameters like priority/timeout_s are unexplained. This leaves meaningful gaps for a 5-parameter async tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 compensate. It only adds meaning for 'addresses' via 'or a subset by address.' Parameters 'fleet' and 'resource' are self-explanatory, but 'priority' and 'timeout_s' are not described at all, leaving their semantics unclear.
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?
The description clearly states the tool's action: 'Read one resource across every device in a fleet, or a subset by address.' This is specific and differentiates from siblings like fleet_write (write) and fleet_scan/watchers (other operations). The verb 'read' and resource scope are explicit.
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 implies a clear use case (reading a resource fleet-wide or by subset) but does not explicitly compare with alternatives like fleet_status or fleet_operation_status. It lacks when-not-to-use guidance or mention of sibling tools, so usage context is present but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 specific telemetry data returned and the 'live' nature, but it does not explicitly state that the operation is non-destructive or mention any side effects. This is a minor gap for a status/telemetry tool.
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?
The description is two sentences, front-loaded with the key data points and a memorable label ('live debugging surface'). Every word earns its place with no 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?
For a zero-parameter, read-only telemetry tool with an output schema, the description sufficiently conveys purpose and return content. It could be strengthened by referencing sibling tools, but the simplicity of the tool makes this adequate.
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?
The tool has zero parameters, so the schema fully covers parameter semantics. The description adds useful context about what the telemetry covers, but no parameter-specific explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool's focus as connection pool telemetry and lists specific metrics (active/idle/evicting counts, queue depth, wait times), which clearly distinguishes it from sibling fleet-level tools like fleet_status. It lacks a direct verb, but 'telemetry' implies retrieval.
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?
Calling it 'the live debugging surface for the pool' gives a clear context for when to use it (debugging pool state), but it does not explicitly compare to alternatives such as fleet_status or fleet_operation_status, nor state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a meaningful behavioral trait: 'safety_critical devices are excluded from fleet_write batches unless explicitly confirmed' and defines risk_tier values. However, it omits other important behaviors such as whether registration is idempotent, whether existing fleet entries are overwritten, or any permission requirements.
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?
The description is concise: two sentences, front-loaded with the core purpose, followed by a focused note on risk_tier. Every sentence adds value without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no annotations, and an output schema, the description covers the core purpose and one key behavior but lacks context about prerequisites (e.g., whether the fleet must exist), parameter interactions, or how this tool fits with fleet_scan and fleet_write. The output schema handles return values, but other completeness gaps remain.
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 0%, so the description must compensate. It explains risk_tier (with allowed values) and the three selection mechanisms (addresses, name_pattern, service_uuids), but does not explain scan_timeout_s, the 'name' parameter's role, or whether parameters are mutually exclusive. Partial compensation, but significant gaps remain.
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?
The description clearly states the tool's purpose: 'Register a device or group (by explicit address list, or by name pattern / service UUIDs discovery filter) into a named fleet.' It provides specific verbs and resources, and distinguishes this from sibling tools like fleet_scan (discovery), fleet_read, and fleet_write.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly provides usage context: use this to add devices/groups to a fleet, with alternative selection methods. It also references fleet_write behavior for safety_critical devices, giving a cross-tool guideline. However, it doesn't explicitly state when not to use this tool or directly compare with other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 important behavioral trait that watching pins a pool connection slot for the duration, which is beyond the schema. It could add more about buffer limits or lifecycle, but the key side effect is conveyed.
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?
Two sentences, front-loaded with the main verbs, and no filler. Every sentence contributes to understanding the tool's purpose and a critical side effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and a key behavioral caveat, but lacks definition for most parameters. The presence of an output schema helps with returns, yet the tool's 5-parameter complexity demands more parameter-level explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only explains the 'action' parameter in prose. The 'fleet', 'resource', 'addresses', and 'debounce_s' parameters are not described at all, leaving the agent to guess their meaning and constraints.
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?
The description clearly states the tool's function with specific verbs: subscribe, unsubscribe, and poll for a resource across a fleet. It distinguishes itself from siblings like fleet_read and fleet_write by focusing on watching/notification behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on the three action modes and explicitly mentions a resource-consumption tradeoff (pinning a pool connection slot). No explicit exclusions or alternatives are named, but the guidance is sufficient for basic usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that this operation is non-invasive ('without connecting to or registering them') and implies a read-only scanning action. However, it does not mention potential side effects (e.g., network traffic), timeouts, or permissions, but the core safety trait is well conveyed.
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?
The description is exceptionally concise, consisting of two sentences that deliver the core purpose, the key behavioral distinction, and usage guidance. No superfluous words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the essential purpose and safety context. However, with no parameter explanations and no annotation support, the agent may struggle to construct the right filter arguments. The description is adequate for understanding 'why' but lacks 'how' for parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 compensate for parameter meaning, but it does not. The phrase 'matching a filter' is vague and does not explain specific parameters like 'addresses', 'name_pattern', or 'service_uuids'. Only the schema names and defaults are given, leaving the agent to infer what each parameter does.
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?
The description clearly states the tool's function: 'Discover devices matching a filter, without connecting to or registering them.' It uses a specific verb and resource, and explicitly contrasts with fleet_register, making it distinct from siblings.
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?
The description gives explicit usage guidance: 'Use this to see what's out there before fleet_register.' This names the alternative (fleet_register) and indicates when to use it (before registering). It also clarifies what the tool does not do ('without connecting to or registering'), providing a clear when-not-to-use signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and uses it well: it discloses the write-allowed prerequisite, the readback verification process, and the skipping behavior for safety_critical devices. It also explains the dual reporting of acknowledged and converged. This covers the key behavioral traits beyond the basic 'write' action.
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 with no filler: purpose, prerequisite, verification, and safety handling. Each sentence adds essential information without redundancy, earning a 5.
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?
For a mutation tool with 7 parameters and no annotations, the description covers the essential behavioral context: what it writes, when it's allowed, how writes are verified, and how safety classification affects execution. Missing parameter semantics for a few fields, but the output schema likely compensates for return values, making this reasonably complete.
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?
The schema has zero parameter descriptions, so the description must compensate. It adds genuine meaning for confirm_addresses (overrides safety_critical skip) and implies resource/fleet, but value, priority, addresses, and timeout_s remain undocumented. The coverage gap keeps this at a 3.
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?
The description opens with 'Write one resource across a fleet,' which is a specific verb and resource that clearly distinguishes it from siblings like fleet_read and fleet_scan. It also adds context about write verification and safety-category handling, leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a hard prerequisite (FLEET_ALLOW_WRITES=1) and explains when safety_critical devices will be skipped unless confirmed. While it doesn't explicitly name alternatives, the read/scan/watch/status siblings are implicitly differentiated by the write focus. This gives clear context without formal exclusions, matching a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses the critical guarantee that no device is silently dropped (each resolves to success, specific error, or still_queued) and that results can be partial or complete. This is valuable behavioral context beyond the schema. It could mention auth/rate limits but those are not critical for a status poll.
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?
Two sentences, no filler, front-loaded with the core purpose. The second sentence adds an important behavioral guarantee without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter and an output schema present, the description delivers the essential context: what it polls, what it returns (partial/complete, and the device resolution guarantees). It is sufficiently complete for an agent to invoke correctly.
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?
The only parameter, operation_id, is described as identifying the batch to poll, adding meaning beyond the schema's bare 'Operation Id' title. Since schema coverage is 0%, this mention partially compensates and clarifies the parameter's role.
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?
The description uses a specific verb ('poll') and identifies the resource ('a fleet_read/fleet_write batch') and the key discriminator ('by operation_id'). This clearly distinguishes it from sibling tools like fleet_read/fleet_write (which initiate operations) and fleet_status (which likely shows general fleet status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies usage after a fleet_read/fleet_write batch has been issued, with operation_id as the handle. However, it doesn't explicitly mention alternatives or exclusions (e.g., 'use fleet_status for...'), so it's one step below full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ble-fleet-mcp MCP server](https://glama.ai/mcp/servers/JephinJose/ble-fleet-mcp/badges/card.svg)](https://glama.ai/mcp/servers/JephinJose/ble-fleet-mcp)

Score Badge

Copy to your README.md:

[![ble-fleet-mcp MCP server](https://glama.ai/mcp/servers/JephinJose/ble-fleet-mcp/badges/score.svg)](https://glama.ai/mcp/servers/JephinJose/ble-fleet-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JephinJose/ble-fleet-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server