BCD — Bridge Control Delegate

stat_path

Read-only

File or folder details: size, modified/created times, mode, text line count and appendPosition, or spreadsheet sheet sizes. Returns JSON. A missing path is an error unless missingOk is true; to check whether a path exists, pass missingOk: true and read exists.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "stat_path"
  }
}

Input Schema

Name	Required	Description
`path`	Yes
`deviceId`	No	Computer name or id from list_devices. Optional with one computer online or a default set.
`missingOk`	No	Return {"exists": false} instead of an error when the path does not exist.
`workSessionId`	No	Work session from create_work_session. Pass the same ID on every call in this conversation; omit for legacy unscoped work.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 21, 2026

addedInput schema / properties / missingOk

Added value: +{
+  "default": false,
+  "description": "Return {\"exists\": false} instead of an error when the path does not exist.",
+  "type": "boolean"
+}

Changed1 schema field changedSep 30, 2026

addedInput schema / properties / workSessionId

Added value: +{
+  "description": "Work session from create_work_session. Pass the same ID on every call in this conversation; omit for legacy unscoped work.",
+  "format": "uuid",
+  "type": "string"
+}

First observedSep 30, 2026

TDQS

A3.8/5.0

Behavior4/5

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

The annotations already establish that this is a read-only, non-destructive, non-open-world operation. The description adds useful behavioral context beyond that, especially the error behavior for missing paths and the missingOk alternative that returns an exists flag.

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 compact and front-loaded, starting with the returned metadata and then covering JSON output and the missing-path edge case. Every sentence contributes directly to correct invocation.

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

Completeness4/5

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

With no output schema, the description usefully lists representative returned fields and explains the missing-path behavior. It does not fully document the JSON structure or mention device/work-session scoping, but the input schema covers the remaining parameters adequately.

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

Parameters3/5

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

Schema description coverage is 75%, so the schema already documents most parameters, including missingOk and deviceId. The description reinforces missingOk semantics but does not add meaning for path, deviceId, or workSessionId beyond what the schema provides.

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

Purpose4/5

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

The description clearly identifies the resource as a file or folder and enumerates the metadata it returns, such as size, times, mode, line count, appendPosition, and sheet sizes. It lacks an explicit verb like 'retrieve' and does not directly differentiate itself from nearby tools such as list_directory or read_file.

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?

It gives one explicit usage scenario: to check whether a path exists, pass missingOk: true and read exists. However, it does not explain when to use this tool versus alternatives like list_directory, read_file, or search_files, leaving general selection guidance implicit.

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

All BCD — Bridge Control Delegate tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?