Witzense MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clear distinct purposes (device info, locations, tracks, reports, streaming, OBD, etc.). Some potential confusion exists between location-related tools (e.g., get_witzense_device_locations vs list_witzense_account_locations) and URL tools, but descriptions clarify the scope. The fallback call_witzense_method is explicitly for uncovered methods, reducing ambiguity.
Naming Consistency5/5
All tools follow a consistent verb_witzense_noun pattern in snake_case (e.g., list_witzense_devices, get_witzense_track, get_witzense_obd_data). The verbs are limited to list, get, and call, and every tool includes the witzense prefix, making the naming highly predictable and uniform.
Tool Count4/5
23 tools is above the typical 3-15 range, but the server covers a broad and varied domain (devices, locations, geofences, media, alarms, reports, OBD, RFID, tags). Each tool serves a specific function and no redundancy is apparent, so the count is justified despite being heavy.
Completeness4/5
The tool surface covers the main read-oriented operations for a device tracking platform: device management, locations, tracks, mileage, geofences, groups, media, streaming, alarms, reports, OBD, RFID, and tags. However, there are no create/update/delete operations for resources like geofences or devices, so management actions are limited. The presence of call_witzense_method mitigates gaps by allowing access to uncapitalized methods.
Average 2.9/5 across 22 of 23 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of explaining behavior. It does not mention side effects, permissions, rate limits, or return format, leaving the agent without critical execution context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy, but it is so minimal that it omits essential details. It is not verbose, but it also does not efficiently pack needed information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description fails to provide a complete picture. It does not explain the return structure, filtering options, pagination behavior, or any constraints, making it inadequate for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only references account and time range, but the schema includes five other parameters (imeis, card_ids, page_no, page_size) that are left entirely undocumented, despite zero schema descriptions. The agent cannot infer their meaning or optionality from the description.
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 states the action (get) and the resource (RFID reporting records), including the key scope (account and time range), which distinguishes it from sibling functions focused on devices, tracks, or other report types.
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?
The description provides no information on when to use this tool versus alternatives, such as criteria for filtering by IMEI or card IDs, or when pagination is needed. No comparison with sibling tools is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states that it retrieves a URL but does not mention any side effects, required permissions, or limitations. Since it is a 'get' operation, it likely is read-only, but that is not explicitly stated, and no further behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no unnecessary words, but it lacks any structural organization beyond a single sentence. It is front-loaded but under-specified. While brevity is a positive, the extreme terseness reduces its utility, making it hard to extract any actionable details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters (including an enum for type and voice) and no output schema or annotations, the description is incomplete. It does not explain what 'live or historical' means in the parameters, what values are expected, or what the returned URL format is. The sibling tools suggest a broader context, but this description fails to provide sufficient context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description provides no information about the parameters (imei, type, voice). It does not explain what these parameters represent or how they affect the output. The description is entirely inadequate for guiding parameter usage, as it does not compensate for the lack of schema descriptions.
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 states the tool fetches a streaming page URL for a device, with a distinction between live and historical. It uses a specific verb and resource, making the primary function understandable. However, it does not differentiate from sibling tools like get_witzense_rtmp_url, which also deals with streaming URLs, so it lacks explicit differentiation.
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 this tool versus alternatives. The description is a single sentence with no context about typical use cases, prerequisites, or distinctions from similar sibling tools. It does not mention exclusions or 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.
Behavior2/5
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 doesn't mention pagination behavior (page_size, start_row), whether the report is read-only, any rate limits, or what the response structure looks like. The description is too terse to convey behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it's under-specified. It front-loads the core purpose but omits critical details. It's not verbose, but the brevity comes at the cost of usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description is inadequate. It doesn't explain the report types, required time range format, filtering options, or pagination. The tool is complex enough that a richer description is needed for correct usage.
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 mentions 'daily or detailed' which hints at the 'type' parameter but doesn't explain the meaning of start_time, end_time, imeis, account, page_size, or start_row. The description adds minimal value beyond the schema's bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves trip report data in daily or detailed formats, which is a clear verb+resource. However, it doesn't distinguish this from sibling report tools like get_witzense_parking_report or get_witzense_fence_duration_report, and the 'type' parameter's meaning (day vs list) is not explained.
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 this tool versus alternatives. The description doesn't mention prerequisites, typical use cases, or how the 'type' parameter affects the report format. Sibling tools exist for other report types, but no differentiation is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 behavioral burden. It only states 'Get mileage trip data', offering no details on pagination (despite page_size and start_row parameters), default IMEI behavior (though the schema mentions it), or any read-only or side-effect implications. This is a significant gap for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is concise, but it is under-specified. There is no fluff, but the brevity undermines usefulness. It is appropriately front-loaded but lacks substantive content that would earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is far too sparse. It does not explain what 'mileage trip data' includes, how to interpret results, or any edge cases. The context is incomplete for an agent to fully understand the tool's behavior.
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 only 20% (only imeis has a description). The description adds no clarification for begin_time, end_time, page_size, or start_row. With low schema coverage, the description should compensate, but it does not, leaving the agent to infer from names alone.
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 states the action 'Get' and the resource 'mileage trip data' with a scope of 'one or more devices'. While it distinguishes the general topic from siblings like get_witzense_track or get_witzense_trips_report, it does not explicitly differentiate itself, so it falls short of a 5.
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?
There is no mention of when to use this tool versus alternatives like get_witzense_trips_report or get_witzense_device_locations. The description provides no contextual cues for when this tool is appropriate, and no guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does not mention pagination, time range handling, the meaning of acc_type 'on'/'off' in relation to parking/idling, authentication, or any return characteristics. It only repeats the tool's name-level purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is compact and front-loaded with the key action and resource, but it is under-specified for a tool with 7 parameters and no other documentation. The brevity is not earned by completeness; it reads as a placeholder rather than a deliberately concise spec.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no annotations, no output schema, and no parameter descriptions. The description fails to cover essential context such as how devices are selected, what acc_type on/off signifies for parking versus idling, pagination semantics, or the expected response format. It is materially incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter explanations. Seven parameters remain undocumented in both the schema and the description; acc_type, start_row, and page_size semantics are particularly unclear, leaving the agent unable to construct a valid invocation with confidence.
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 ('Get') and resource ('parking or idling records'), and it clearly distinguishes this tool from sibling tools like get_witzense_trips_report or get_witzense_fence_duration_report. It states what the tool returns with direct, unambiguous wording.
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?
The description provides no context on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply restates the basic function without any guidance on selecting it among the many Witzense report tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 disclosing behavioral traits. It only states 'Get detail information' without mentioning side effects, authentication requirements, rate limits, or whether the operation is read-only. This is a significant gap for a tool that could have implicit expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, generic sentence. While it is not verbose, it is under-specified, providing no structural detail, examples, or context. This falls into the category of under-specification rather than conciseness, akin to the 'Process' example in the calibration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a single parameter, the description should clarify what the tool returns (e.g., device attributes, status, etc.), typical errors, or any prerequisites. It does none of this, leaving the tool's functionality largely unexplained despite its simple interface.
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 schema defines a single required parameter 'imei' with no description beyond minLength. The tool description adds no meaning to this parameter, and schema coverage is 0%. The user must infer that 'imei' is a device identifier, but the description does not clarify its format or purpose. Given the low coverage, the description should compensate but does not.
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 states the action (get detail information) and resource (one Witzense device). It distinguishes from sibling tools like list_witzense_devices (returns multiple) and get_witzense_device_locations (specific location info), but the phrase 'detail information' is vague and could specify what kind of details.
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 when to use the tool (when you need details for a single device), but there is no explicit guidance on when not to use it or how it compares to alternatives like list_witzense_devices or other get_* tools. No exclusionary language is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description holds full responsibility. It only states 'Get details' without disclosing read-only behavior, permissions, or any side effects. No additional traits beyond the basic action are revealed.
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?
A single sentence, perfectly concise for a simple getter. No redundancy, every word contributes to the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even for a low-complexity tool, the description is under-specified. It fails to mention what 'details' include, expected response structure, or possible failure modes. Lacks essential context that would guide correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain 'fence_id' beyond its existence. There is no guidance on format, source, or relationship to other data, leaving the agent to infer from the name alone.
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 clearly that it retrieves details for a single geofence, distinguishing it from list_witzense_geofences by specifying 'one'. Captures the verb and resource, 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.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no context on when to use this tool versus alternatives. No mention of prerequisites (e.g., obtaining a fence_id from a list call) or occasions where a different getter might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should carry the full burden of transparency. It only says 'Get camera photo or video URLs' without disclosing pagination (page_no/page_size), time filters (start_time/end_time), or the meaning of camera and media_type enums. It doesn't mention if this is read-only or has side effects. The description is too minimal for the behavioral complexity implied by 8 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, which is concise, but it's under-specified. Conciseness should not come at the cost of missing critical information. It doesn't elaborate on parameters, usage, or constraints, so it's not well-structured for an agent to use effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters flavors (imei, token, camera, page_no, media_type, and likely date range), the description is extremely incomplete. No pagination details, no clarification of camera/media_type enums, no mention of required vs optional fieldsoutputs. It fails to provide enough context for an agent to know what to pass and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% – the property descriptions are entirely absent. The description doesn't explain what 'camera' values (1,2,3) mean, what 'media_type' values represent (1=photo? 2=video?), the format of time strings, or the role of token, page_no. The description mentions 'photo or video' but doesn't link it to media_type. With 5 optional parameters and zero documentation, this is a serious deficiency.
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: 'Get camera photo or video URLs for a device.' It uses a specific verb (get) and resource (camera photo or video URLs) with a context (device). It distinguishes from siblings like get_witzense_live_url or get_witzense_rtmp_url by focusing on stored media, so it's unambiguous.
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 usage (for retrieving media files from a device) but does not explicitly state when to use it over alternatives. It mentions 'photo or video' which differentiates from live/streaming endpoints, but there's no explicit when-not-to-use or alternative names. Context suggests it's for archived media, but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states the tool 'gets' data, but doesn't mention pagination, time range constraints, or whether it's read-only. The lack of detail on response format or side effects is a gap.
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?
The description is a single sentence, which is concise and front-loaded. However, it's under-specified, so while it's short, it doesn't earn its place by adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description is insufficient. It doesn't explain the data returned, how to filter by IMEI/account, or pagination behavior. The tool is moderately complex and needs more context.
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 doesn't explain any parameters, including required start_time/end_time or optional imeis, account, page_no, page_size. The description adds no meaning beyond the schema's basic types.
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 states the tool retrieves OBD/CAN telemetry from devices, which is a specific resource and action. It distinguishes from siblings like get_witzense_obd_faults (faults) and get_witzense_track (location), though it doesn't explicitly differentiate.
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 on when to use this tool versus alternatives like get_witzense_obd_faults or get_witzense_track. The description implies it's for telemetry data but doesn't specify use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It does not mention whether this is a read-only operation, any pagination behavior, rate limits, or what the response contains. The description is minimal and does not add behavioral context beyond the basic action.
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?
The description is a single sentence, which is concise and front-loaded. It states the core purpose without fluff. However, it is under-specified, which is a trade-off; the conciseness is good but at the expense of necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the required time range, the meaning of optional filters, or the response structure. The agent would need to guess or rely on external knowledge, making the tool hard to use correctly.
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 does not explain any parameters. The schema provides names and types but no semantics (e.g., what 'imeis' or 'account' mean, how time formats are expected). The description adds no value in explaining parameters, leaving the agent to guess.
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 states the tool's purpose: retrieving OBD fault codes reported by devices. It uses a specific verb ('Get') and resource ('OBD fault codes'), and the context of devices is implied. It distinguishes from siblings like get_witzense_obd_data by focusing on fault codes specifically, though it doesn't explicitly differentiate.
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 this tool versus alternatives like get_witzense_obd_data or get_witzense_device. The description does not mention any prerequisites, time range requirements, or typical use cases. The agent must infer usage from the parameter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states 'Get the latest location'. It does not mention return format, error conditions, authentication needs, or any side effects, leaving the agent uncertain about behavior.
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?
The description is a single sentence, highly concise and front-loaded. It wastes no words, but the brevity borders on under-specification; however, for a simple getter, the length is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations, so the description must provide sufficient context. It fails to explain the meaning of 'latest' (time window), the nature of TAG devices, or the expected response structure, leaving significant gaps for an agent.
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 'imeis' is a string with zero schema description coverage. The description does not explain what values it accepts (e.g., comma-separated list, JSON array, single IMEI) or its relationship to 'TAG devices', relying solely on the parameter name for inference.
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 verb 'Get' and resource 'latest location' are clear, and 'TAG devices' adds specificity. However, it doesn't explicitly differentiate from similar sibling tools like get_witzense_device_locations or get_witzense_track, though the name implies a distinct scope.
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?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no context about prerequisites or typical use cases. It simply states what it does without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the basic action and time range, without revealing return format, pagination, data limits, authorization needs, or any other behavioral traits.
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?
The description is a single short sentence with no filler, and the core verb and object are front-loaded. However, the phrase 'documented time range' is slightly vague and could have been clarified within the same concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, no annotations, and no output schema, the description provides only the most basic context. It does not explain what track points look like, what map_type controls, any constraints on the time range, or what the response will contain.
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 50%, so the description should compensate for the undocumented imei and map_type parameters. It does not. The text only echoes the general notion of one device and time range, and adds no meaning for map_type or imei format beyond the schema's basic type declaration.
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 uses a specific verb ('Get') with a clear resource ('track points for one device within the documented time range'), indicating the tool's core function. It distinguishes itself from most sibling tools by specifying track points, but does not explicitly contrast with the similar-sounding get_witzense_device_locations.
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 about when to use this tool versus any sibling alternative. There is no mention of exclusions, prerequisites, or comparisons to other location/track related tools, so the usage context is entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosing side effects or permissions. It only states the action without mentioning that it is read-only, whether it might fail, or if any data is modified. This lack of transparency is a significant gap.
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, concise sentence with no redundant information. It is well-structured and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is extremely minimal, covering only the basic purpose. It does not address parameters, usage context, expected output, or any constraints. Given the complexity of the tool (six parameters, no annotations), the description is far from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists six parameters (imeis, account, end_time, page_size, start_row, start_time) with no descriptions, and the description does not explain any of them. Since schema coverage is 0%, the description should compensate by defining parameter roles, but it does not, leaving the agent without semantic understanding.
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 action (Get) and the resource (device fence entry and exit duration records), making the tool's purpose unambiguous. It is distinct from sibling tools that focus on geofences, alarms, or trips.
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?
The description provides no guidance on when to use this tool relative to alternatives. It does not mention any specific scenarios, prerequisites, or comparisons with sibling tools like list_witzense_geofences or get_witzense_track.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 the basic retrieve action but does not mention output format, URL expiration, device online requirements, or whether any state changes occur. For an unannotated tool, this is insufficient.
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 clear sentence with no extraneous information; it is efficiently front-loaded with the action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and only a minimal parameter schema, the description is too sparse. It does not describe the return type, any prerequisites (e.g., device online, permissions), or the relationship to similar sibling tools like get_witzense_live_url.
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 schema has one required parameter 'imei' with minLength 1 and no description; the description does not mention the parameter at all. Schema description coverage is 0%, so the description fails to compensate. The parameter name is self-explanatory but the tool adds no semantic detail beyond the schema.
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?
Description uses a specific verb 'Get' and resource 'RTMP streaming URL for a device,' clearly stating the core functionality. However, it does not distinguish this from sibling tools like get_witzense_live_url or get_witzense_media_urls, which may serve similar streaming purposes.
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?
The description provides no guidance on when to use this tool versus alternatives such as get_witzense_live_url. It only states the action, with no context for tool selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose rate limits, pagination behavior (despite page_no/page_size params), time range constraints, or what 'supported time range' means (e.g., max 1 month, timezone). With no annotations and no output schema, this is a significant gap. The description mentions 'supported time range' but doesn't elaborate on what that range is or how it behaves.
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 one sentence and does not waste words. It is short and to the point, which is appropriate for a tool that should add just a bit of context beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Six parameters, no output schema, no annotations, and no parameter descriptions mean the description carries a heavy burden to provide context. It fails to explain the time format, parameter semantics, or return value shape. The lack of any guidance on the time range filters (which look critically important given the description's mention of a 'supported time range') is a major gap.
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?
With 0% schema description coverage and 6 parameters, the description must compensate, but it only mentions 'for one or more devices' which loosely maps to the 'imeis' parameter. No meaning is added for the time range parameters (begin_time/end_time), pagination, or alertTypeId filter. The description fails to clarify the format of time strings (e.g., Unix timestamp vs ISO 8601) or how imeis is delimited (e.g., comma-separated).
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 uses a specific verb ('List') and names the resource ('alarms') and the key qualifier ('for one or more devices within the supported time range'). While it doesn't explicitly distinguish it from siblings, the 'supported time range' phrase adds a constraint worth noting. No sibling tool is named as an alternative, so no differentiation is given, but the core purpose is clear.
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?
The description is silent on when to use this tool versus alternatives. With 22 siblings (including get_witzense_device, get_witzense_track, get_witzense_device_locations), the description should clarify cases for using list_witzense_alarms, such as 'use for historical alarm queries' versus 'use get_witzense_device for device status.' No such guidance exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description adds little beyond the basic 'get' semantics. It does not disclose whether the URL is permanent, requires permissions, has expiration, or what the response includes. This leaves significant behavioral ambiguity.
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, focused sentence with no unnecessary words. It presents the core purpose efficiently and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, the description should clarify the input and expected behavior, but it does not. It lacks context about URL generation, device requirements, or what the agent can do with the result, making it incomplete for a production 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?
The schema has a single required 'imei' parameter with no description, and the description does not mention it either. Saying 'for a Witzense device' only vaguely implies a device identifier, so the agent must infer that imei is the required device ID.
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 verb 'Get' and the resource 'a shareable map URL for a Witzense device', making the purpose unambiguous. It distinguishes itself from sibling tools like get_witzense_live_url and get_witzense_device_locations by focusing on the shareable map URL.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios, exclusions, or how this tool differs from other device-related URL tools, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It only states the action and resource, but does not clarify whether this is a read-only operation (though likely implied by 'get'), any authentication requirements, potential rate limits, or what happens when multiple IMEIs are passed. The lack of such detail reduces transparency.
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?
A single sentence that is direct, front-loaded, and free of filler. Every word contributes to understanding the core purpose. This is an appropriately minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, no output schema), the description is minimal but incomplete for effective use. It lacks usage context, expected return shape, or any behavioral notes. The absence of alternative guidance and behavioral transparency makes it incomplete despite low complexity.
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 input schema covers both parameters with descriptions (100% coverage), so the description adds no additional meaning. Per guidelines, baseline is 3 when schema coverage is high. The tool description does not clarify parameter formats or behavior beyond what the schema already provides.
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: 'Get the latest location for one or more Witzense devices.' It uses a specific verb ('Get') and resource ('latest location'), and conveys the scope (one or more devices). This distinguishes it from sibling tools like get_witzense_tag_location (single tag) or get_witzense_track (tracking history).
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?
The description offers no guidance on when to use this tool versus alternatives. With 22 sibling tools covering various Witzense functions (tracks, reports, geofences, etc.), the agent receives no context about when this is the right choice. It neither mentions alternatives nor provides any selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states only the action without disclosing potential side effects, permissions, pagination behavior, or output format. For a read-only list operation, it is minimally transparent but lacks context.
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 filler or repetition. It communicates the core function efficiently.
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 simplicity of the tool (one parameter, no output schema), the description is adequate but not complete. It omits any mention of return structure, pagination, or special behaviors, which could be important for an agent invoking it. However, for a basic list operation, it may suffice.
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 one required parameter 'account' with no description (0% coverage). The description clarifies that the account is the owner of the device groups being listed, providing some meaning. However, it does not specify whether this is an account ID, name, or other identifier, leaving room for ambiguity.
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 ('List') and a clear resource ('device groups') with a scope ('belonging to an account'). This clearly distinguishes it from siblings like list_witzense_devices, which lists devices, and list_witzense_child_accounts, which lists accounts.
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?
The description provides no guidance on when to choose this tool over alternatives such as list_witzense_devices or list_witzense_child_accounts. There is no mention of prerequisites, exclusions, or use cases. The usage is only implied by the name and resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose whether the operation is read-only, if it has side effects, or any potential rate limits. The term 'list' implies read-only, but this is not explicitly stated, leaving room for uncertainty.
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 concise sentence with no superfluous words or redundant information. It directly states the core function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no annotations, and the description lacks details about response format, pagination behavior, error handling, or edge cases. It is minimal and leaves many operational aspects undefined, making it incomplete for a robust tool description.
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 input schema defines three parameters, but the description provides no explanation of their meaning or usage. The schema gives basic types and defaults, but the account parameter's purpose (e.g., account ID) is not clarified, and pagination parameters are not described.
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 lists geofences associated with an account, which is specific and unambiguous. It distinguishes this tool from siblings that list other entities like devices or locations.
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 no explicit guidance on when to use this tool versus alternatives, nor does it mention pagination or other usage considerations. It is a minimal but adequate statement for a simple list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It only mentions listing sub-accounts but gives no information about read-only nature, pagination, return format, required permissions, or potential side effects. For a tool with zero annotation coverage, this is insufficient transparency.
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, front-loaded sentence with zero redundancy. Every word contributes to the meaning. It is appropriately sized for a simple tool with one optional parameter, achieving maximal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and leaves several questions unanswered: what does the output look like (no output schema), does it return all nested levels or just direct children, and are there any access restrictions? Without annotations or an output schema, more detail is needed for an agent to use the tool confidently, especially given it is part of a large family of similarly named tools.
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?
With schema description coverage at 100%, the baseline is 3. The single parameter 'target' is described in the schema as 'Account to query; defaults to the configured account.' The tool description adds no extra semantic context beyond what the schema already provides, so it meets but does not exceed the baseline.
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 action: 'List sub-accounts under a Witzense account.' It uses a specific verb ('List') and resource ('sub-accounts'), and the scope is distinct from all sibling tools (no other tool targets child accounts). The name and description align perfectly, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to enumerate sub-accounts for a given Witzense account. However, it does not explicitly state when to use this tool vs alternatives, nor does it provide exclusions or prerequisites. Since it's the only tool for this purpose, the context is implied but not clearly framed against siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It only states the action without addressing permissions, rate limits, edge cases (e.g., devices without locations), or the meaning of 'latest' beyond the literal wording.
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?
A single sentence, front-loaded with the main purpose and no filler. Every word is useful and the structure is optimal for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 optional parameters, no output schema, and no annotations, the description is too minimal. It lacks detail on return format, map_type semantics, and any preconditions or limitations, leaving the agent to guess important context.
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 coverage is 50% (target has a description, map_type does not). The description mentions 'under an account' which aligns with target, but does not explain map_type or its possible values. With low coverage, the description should compensate, but it does not.
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 action ('Get'), the object ('latest location'), and the scope ('all devices under an account'). It distinguishes from sibling tools like get_witzense_device_locations by focusing on all devices rather than a single one.
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 implies use for account-wide location retrieval, but it does not explicitly name alternatives or state when not to use it. The context is clear, but exclusions are absent.
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 provided, the description carries the full burden of disclosing behavior. It accurately indicates a read-like operation ('list') and the association with a Witzense account, but it does not describe potential side effects, error conditions, or default behavior beyond what is in the schema. It is not misleading but also not particularly revealing.
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 eight-word sentence that is direct and front-loaded. Every word adds value, and there is no redundancy or fluff.
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 simple list operation with one optional parameter and no output schema, the description is sufficiently complete. It clearly states what the tool does and the key qualifier (owner of devices). It could have mentioned default pagination or return format, but these are not critical for a straightforward listing action.
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 description coverage is 100% because the sole parameter `target` includes an inline description: 'Account to query; defaults to the configured account.' The main description does not add additional parameter context, but the baseline of 3 is appropriate given the schema already fully documents the parameter.
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 uses a specific verb ('list') and resource ('devices') with a qualifying context ('belonging to a Witzense account'), which clearly differentiates it from siblings like 'get_witzense_device' (singular) and 'list_witzense_child_accounts'. However, it does not explicitly call out the distinction from those alternatives, so it doesn't earn a 5.
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?
Usage is implied by the tool's name and description, but there is no explicit guidance on when to use this over `get_witzense_device` or other list tools. The description does not mention exclusions or alternatives, but the simplicity of the operation makes the lack of conflict acceptable for a basic use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions that credentials and signing are configured, but does not describe side effects, error handling, rate limits, or whether the operation is read-only or mutating. Since it is a generic wrapper, such details are method-specific, but the description offers no guidance on what to expect beyond a generic call.
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 purpose and a clear usage directive. There is no fluff or repetition; every word contributes to understanding the tool's role.
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?
Given the tool is a generic method caller with two well-documented parameters and no output schema, the description covers the essential context: what it does and when to use it. It does not need to list every method or return format, as that is method-specific. It is complete enough for its intended generic role.
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 coverage is 100% with both parameters described. The description adds minimal extra value: it clarifies that authentication and signing are handled by the server, which is helpful to avoid clients including auth parameters. However, this is also present in the schema's params description. It does not add meaning beyond what the schema already provides, so a baseline 3 is appropriate.
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 calls a Witzense API method with managed credentials and signing, and explicitly frames it as a fallback for methods not yet exposed as dedicated tools. This distinguishes it from the many specific sibling tools (e.g., get_witzense_device) by indicating it is the generic entry point for undocumented methods.
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 explicitly states when to use: 'Use this for documented methods not yet exposed as dedicated tools.' This clearly implies that dedicated tools should be preferred when available, providing a clear directive for tool selection among the many siblings.
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:

[![WITZENSE-MCP MCP server](https://glama.ai/mcp/servers/MightyCMEMBRENO/WITZENSE-MCP/badges/card.svg)](https://glama.ai/mcp/servers/MightyCMEMBRENO/WITZENSE-MCP)

Score Badge

Copy to your README.md:

[![WITZENSE-MCP MCP server](https://glama.ai/mcp/servers/MightyCMEMBRENO/WITZENSE-MCP/badges/score.svg)](https://glama.ai/mcp/servers/MightyCMEMBRENO/WITZENSE-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/MightyCMEMBRENO/WITZENSE-MCP'

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