dittu
Server Details
Turns a phone into a camera+Bluetooth remote so AI assistants can see and control any PC.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.8/5 across 12 of 12 tools scored. Lowest: 2.7/5.
Each tool has a distinct action: clicking, double-clicking, key presses, typing, scrolling, mouse movement, screenshot variants, and calibration operations. No two tools overlap in purpose.
All tool names follow a consistent verb_noun pattern in snake_case, e.g., 'get_corners', 'take_screenshot', 'move_mouse'. Very predictable and clear.
With 12 tools, the set covers all necessary operations for remote computer control via phone camera, including calibration aids. Not excessive or insufficient.
Core functionalities are present, but missing common actions like right-click or drag-and-drop may limit some use cases. However, the provided tools are well-suited for calibration and basic control.
Available Tools
12 toolsclickAInspect
Click at normalized screen coordinates.
nx, ny: float 0.0000–1.0000 where (0,0) = top-left, (1,1) = bottom-right.
| Name | Required | Description | Default |
|---|---|---|---|
| nx | Yes | ||
| ny | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the coordinate normalization but does not specify the mouse button, click type (e.g., left click), or behavior for out-of-range coordinates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the purpose. It uses two sentences without unnecessary words. Could benefit from slight expansion on click behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description lacks details about return value or error handling. The output schema exists but is not shown; no mention of what the tool returns. Sibling tools like 'double_click' are not distinguished behaviorally.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description clearly defines nx and ny as floats from 0.0000 to 1.0000 with the coordinate system (top-left to bottom-right), which is essential context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Click at normalized screen coordinates' with a verb-resource pair. It distinguishes from sibling 'double_click' by implying a single click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use or not use this tool versus alternatives like 'double_click'. Usage is implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
double_clickBInspect
Double-click at normalized screen coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| nx | Yes | ||
| ny | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description only states action without details on button (left/right), timing between clicks, or side effects. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded with verb and object. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple action, but missing definition of 'normalized', button preference, or click interval. Output schema may cover return, but behavioral context is sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
0% schema coverage; description says 'normalized' but doesn't define range (0-1) or coordinate system. Adds little value beyond schema titles 'Nx', 'Ny'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Double-click' and resource 'screen coordinates'. Distinguishes from sibling 'click' which is a single click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use. Implicitly for double-click actions, but lacks context compared to alternatives like 'click'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_cornersAInspect
Get the phone's current screen-corner calibration.
Returns {"tl": [nx,ny], "tr": [nx,ny], "br": [nx,ny], "bl": [nx,ny]} — each corner
is a normalized point (0.0–1.0) in the RAW camera frame, defining the perspective
warp that maps the camera view onto a flat rectangle representing the monitor.
These four points are an arbitrary quadrilateral (trapezoid), not a bounding box —
adjust one corner at a time without assuming the others move symmetrically.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fully discloses the output structure (object with four corners), the meaning of normalized points (0.0–1.0 in camera frame), and the quadrilateral nature, explicitly stating it is not a bounding box. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states the purpose, and the second explains the output in detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with zero input parameters and no output schema, the description is fully complete. It explains what is returned and the significance of the data, which is sufficient for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No input parameters, and schema coverage is 100%, so baseline is 3. The description adds value by explaining the output parameters and their semantics beyond what the schema (which is empty) provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'get' and the resource 'phone's current screen-corner calibration', and describes the output format with a specific data structure. Distinguishes from sibling tools like set_corners by focusing on a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, but the purpose is clear. The description implies it is used for retrieving calibration data, and sibling tools include set_corners for writing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_raw_screenshotAInspect
Capture the RAW camera frame — no perspective warp, no crop to the calibrated
screen quad. Use this to see exactly what the camera sees before any correction,
e.g. when troubleshooting why take_screenshot looks wrong, or before adjusting
corners with get_corners/set_corners.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavior. It explains that no warp or crop is applied, which is the key difference from take_screenshot. It doesn't mention performance or side effects, but for a capture tool the behavior 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action and key differentiators. Every word serves a purpose—no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description fully covers what the agent needs to know: what it does, why it exists, and when to use it. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description doesn't need to explain them. The baseline score of 4 applies, as the description adds no param info (unnecessary).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures the raw camera frame without warp or crop, distinguishing it from take_screenshot. It specifies the verb 'Capture' and the resource 'RAW camera frame', making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: troubleshooting take_screenshot errors or before adjusting corners with get_corners/set_corners. It implies the alternative (take_screenshot) but doesn't explicitly list when not to use, which is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
keyBInspect
Press a key combination.
modifiers bitmask: LCtrl=1, LShift=2, LAlt=4, LWin=8
Common keycodes: Enter=40, Escape=41, Tab=43, Space=44,
F4=61, PageDown=78, PageUp=75, Win=227
Examples:
Alt+F4 → key(4, [61])
Ctrl+W → key(1, [26])
| Name | Required | Description | Default |
|---|---|---|---|
| keycodes | Yes | ||
| modifiers | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as whether the action is destructive, requires authentication, or affects system state. The description only explains the parameter encoding, not what happens when a key is pressed (e.g., system-wide effect, timing).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, with a clear format: action, bitmask definition, keycode list, and examples. However, it could be slightly more structured (e.g., bullet points) for easier scanning. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and the presence of an output schema (not shown but mentioned), the description covers parameter semantics well but lacks information about return values or side effects. Considering the tool's complexity (bitmask and keycodes), the description is adequate but not fully complete for an agent to understand all behavioral nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which only defines types. It explains the bitmask for modifiers (LCtrl=1, LShift=2, etc.) and provides common keycodes (Enter=40, Escape=41, etc.), making the parameters immediately usable. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Press a key combination' with a verb+resource. It provides examples like Alt+F4 and Ctrl+W, which help clarify the tool's function. However, it does not explicitly distinguish itself from the sibling 'type_text' tool, which also deals with keyboard input but likely sends text rather than key combinations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'type_text' or 'click'. The examples imply usage for hotkeys like Alt+F4, but there is no mention of when not to use it or what prerequisites apply (e.g., window focus).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
move_mouseAInspect
Move mouse cursor to normalized coordinates WITHOUT clicking.
nx, ny: float 0.0000–1.0000.
| Name | Required | Description | Default |
|---|---|---|---|
| nx | Yes | ||
| ny | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states the behavior: move mouse without clicking, and explains the coordinate format and range. However, it does not mention potential side effects, permissions, or system requirements. Given the simplicity of the action, the transparency is high but could be slightly more comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with no unnecessary words. It front-loads the key action and immediately provides parameter details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity and the description covers essential aspects: action, coordinate format, and a key qualifier (no clicking). It lacks explicit mention of whether coordinates are screen-relative or application-relative, and missing info on return value (though output schema exists). Still, it is largely complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain parameters. It does so effectively: 'nx, ny: float 0.0000–1.0000' provides crucial semantic meaning (type and range) that the schema lacks. This is exactly what the agent needs to correctly populate the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Move mouse cursor' and specifies the resource (normalized coordinates). It explicitly distinguishes from clicking with 'WITHOUT clicking', which differentiates it from siblings like 'click'. The verb-resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need to move the mouse without clicking) but does not explicitly state when not to use it or provide alternatives like 'click' or 'double_click'. The phrase 'WITHOUT clicking' gives some context, but more explicit guidance would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scrollBInspect
Scroll the mouse wheel.
delta: number of ticks. Positive = scroll down, negative = scroll up.
| Name | Required | Description | Default |
|---|---|---|---|
| delta | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explains scroll direction and ticks but lacks details about scroll units (pixels/lines), behavior at extremes, smoothness, or return value. The output schema exists but is not described, and behavioral traits like rate limits or side effects are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous words. It is front-loaded with the action and follows with parameter explanation. Perfectly concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, simple action) and the presence of an output schema, the description is mostly adequate. However, it lacks explanation of output behavior and does not specify the unit of 'ticks' (pixels, lines, etc.), leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'delta' as 'number of ticks' with direction semantics, adding meaning beyond the schema (which only defines type integer). This provides necessary context for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Scroll' and resource 'mouse wheel'. It explains the delta parameter. While it doesn't explicitly differentiate from siblings, scrolling is a distinct action among the listed sibling tools (click, key, etc.), so it is sufficiently clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The usage context is implied because siblings are different actions (clicking, typing, etc.), but there are no when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_cornersAInspect
Update the phone's screen-corner calibration.
Each corner is [nx, ny] normalized 0.0–1.0 in the raw camera frame.
tl/tr/br/bl = top-left/top-right/bottom-right/bottom-left of the monitor as seen
by the camera (an arbitrary trapezoid due to perspective — not a rectangle).
Call get_corners() first to read the current values before nudging one of them.
| Name | Required | Description | Default |
|---|---|---|---|
| bl | Yes | ||
| br | Yes | ||
| tl | Yes | ||
| tr | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions perspective distortion (trapezoid), but does not disclose persistence, side effects, or that changes might require re-calibration. Could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, each adding essential information: update purpose, format explanation, corner mapping, perspective note, and usage hint. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values not required. Missing details like whether calibration persists or requires special mode. Good for a calibration tool with required parameters, but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates. It explains each corner (tl/tr/br/bl) and format [nx, ny] normalized 0.0-1.0 in raw camera frame. Lacks examples or explicit range constraints, but adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates screen-corner calibration, defines each corner (tl/tr/br/bl) and explains they form a trapezoid. It distinguishes from siblings like get_corners.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to call get_corners() first to read current values before making adjustments, providing a clear usage sequence. However, no guidance on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
take_screenshotBInspect
Capture the current screen via the Dittu phone camera. Returns a JPEG image. Call this to see what's on screen before acting.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It mentions the return type (JPEG image) but omits details like whether the action is read-only, required permissions, latency, or that it captures only one screen at a time. This leaves the agent uncertain of side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, front-loaded sentences that efficiently convey the purpose and result. Every sentence adds value without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description covers the basics but lacks details such as screenshot dimensions, file size, or how it differs from similar tools like 'get_raw_screenshot'. It is adequate for a simple tool but could be more informative for optimal agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%, so the description does not need to add parameter details. The baseline for 0 parameters is 4, and the description appropriately adds no redundant information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool captures the current screen and returns a JPEG image, using a specific verb and resource. However, it does not distinguish itself from sibling tools like 'get_raw_screenshot' or 'take_screenshot_with_crosshair', which could cause confusion about which to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Call this to see what's on screen before acting', which implies a common use case but does not explicitly state when not to use it or mention alternative tools (e.g., 'get_raw_screenshot' for raw data). No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
take_screenshot_with_crosshairAInspect
Capture the screen, crop tightly around (nx, ny), zoom in, and draw a crosshair
at exactly that expected position.
Use this for screen-corner calibration: move_mouse(nx, ny) near a screen edge,
then call this to see whether the actual cursor lines up with the crosshair
(where it SHOULD be if calibration is perfect). If the cursor is offset from the
crosshair, or missing entirely (edge is cropped out of frame), corners need
adjusting — see get_corners/set_corners.
nx, ny: the same coordinates you passed to move_mouse.
zoom: magnification factor for the cropped region (default 4x).
| Name | Required | Description | Default |
|---|---|---|---|
| nx | Yes | ||
| ny | Yes | ||
| zoom | No |
Tool Definition Quality
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 explains the tool performs a screenshot, cropping, zooming, and crosshair drawing—a read-only operation. It does not disclose any side effects, but the behavior is well-described; a 4 is appropriate as it adds good context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with no wasted words. It front-loads the purpose, then provides usage steps, and finally explains parameters. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no output schema, and three parameters, the description is complete. It covers purpose, usage, parameter details, and references sibling tools for calibration follow-up. An agent can correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It does: nx and ny are the same coordinates passed to move_mouse, and zoom is a magnification factor (default 4x). This adds meaning beyond the schema's type info, though a small improvement could explicitly mention default for zoom.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a screen region, crops around (nx, ny), zooms in, and draws a crosshair at the expected position. It distinguishes itself from sibling tools like take_screenshot and take_screenshot_with_grid by specifying its purpose for screen-corner calibration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use after move_mouse(nx, ny) to check alignment, and if offset, refer to get_corners/set_corners for adjustments. It tells when to use and what to do if results are not as expected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
take_screenshot_with_gridAInspect
Capture the screen and overlay a coordinate grid.
step: grid spacing (default 0.1, use 0.05 for finer grid on small UI elements).
Returns a JPEG image with grid drawn on top.
| Name | Required | Description | Default |
|---|---|---|---|
| step | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool captures a screenshot and overlays a grid, returning a JPEG image. It implies a read-only operation with no side effects. This is transparent for a simple screenshot tool, though it could mention if it alters any state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: purpose, parameter explanation, return format. Every sentence is necessary and free of fluff. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description is complete. It covers the action, parameter usage, and output format. No additional context is needed for an AI agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only type and default for step (0% description coverage). The description adds context: 'grid spacing', default 0.1, and a tip for finer grids (0.05). This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Capture the screen and overlay a coordinate grid', specifying the verb (capture) and resource (screen with grid). Among siblings, it distinguishes from 'take_screenshot' (no overlay) and 'take_screenshot_with_crosshair' (different overlay). The return format (JPEG) is also mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage tip for the step parameter (default 0.1, use 0.05 for fine grid), but does not explicitly state when to use this tool versus alternatives like take_screenshot or take_screenshot_with_crosshair. There is no guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
type_textCInspect
Type text on the computer keyboard.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only states the action. It does not specify whether text is typed instantly or simulated keystroke by keystroke, how special characters are handled, or if there are any side effects (e.g., modifier keys).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (6 words) and front-loaded, but for a tool with one parameter, it is minimally adequate. However, it omits important details that could be added without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no annotations) and existence of an output schema, the description still fails to provide enough context. It does not explain return values, typing behavior, or prerequisites (e.g., focus on a text field).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'text' has 0% schema description coverage, and the tool description adds no meaning beyond the schema. It does not clarify format (e.g., plain text vs. key combinations), length limits, or character restrictions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Type text on the computer keyboard' uses a specific verb ('type') and resource ('text on computer keyboard'), clearly distinguishing it from siblings like 'key' (single key) and 'click' (mouse action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'key' for single keys, or other input methods). There is no mention of exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!