Bot-Hosting.net

Show the file tree

files_tree

Read-onlyIdempotent

See the whole project layout in ONE call: every file and folder under a path, indented, with sizes. Use this FIRST when exploring, instead of walking directories with files.list. It returns structure only - read the files you want with files.readMany. Dependency folders (node_modules, vendor, .git, ...) are listed but not opened unless you pass includeVendor.

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": {
      "id": "<id>"
    },
    "name": "files_tree"
  }
}

Input Schema

Name	Required	Description
`id`	Yes
`path`	No	Directory to start from. Defaults to the volume root.
`depth`	No	How many directory levels to descend. Default 6.
`maxEntries`	No	Default 400.
`includeVendor`	No	Also walk INTO node_modules, vendor, .git and friends. Default false - they hold thousands of files. Point `path` at one instead to look inside just that one.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, closed-world. The description adds non-obvious context: the result is structure only with no file contents, and vendor/dependency folders are shown as entries but not descended into unless includeVendor is set. It does not mention truncation behavior when maxEntries is hit, but the schema carries that.

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?

Four short sentences, front-loaded with the core capability and the routing decision, then the output nature and the vendor caveat. Nothing is redundant or padded.

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

Completeness4/5

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

There is no output schema, so the description must convey the return shape, and it does (indented tree, sizes, structure only). Slight gap: nothing about truncation or what happens when the entry cap is reached, though the schema's maxEntries description mitigates that.

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 80%, so the baseline is 3. The description mainly restates the includeVendor default that the schema already documents; the one genuine addition is clarifying that vendor folders still appear in the output but aren't opened, which is a small increment.

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?

"See the whole project layout in ONE call: every file and folder under a path, indented, with sizes" names a specific verb, resource, output form, and scope. It explicitly contrasts with files.list, so an agent can choose between the two without inspecting either schema.

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?

States an explicit ordering rule ("Use this FIRST when exploring") and names the alternative it replaces ("instead of walking directories with files.list"), plus a follow-up action (files.readMany) for file contents. When-to-use and what-not-to-do are both covered.

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

All Bot-Hosting.net tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?