Get file metadata for any path—size, modification time, permissions, and directory/file status—to inspect local files safely without reading their contents.
Return metadata for a path — size, mtime, mode, is_dir, is_file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.2Does 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 convey that this is a read-only metadata operation and lists the result fields, but it does not disclose failure behavior for missing paths, symlink handling, or whether it works on both files and directories (though is_dir/is_file hint at this). The core read-only nature is implied but not explicit.
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 a single, front-loaded sentence with zero filler. It states the action and the key output fields efficiently, earning its place without any unnecessary 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?
The tool is simple, has an output schema, and the description lists the returned fields, so return-value details are covered. However, the description lacks usage guidance and path expectations, which would be valuable given the sibling tools. It is minimally adequate but leaves the agent to infer when and how to invoke it.
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. However, it merely says 'for a path', which only restates the schema's 'path' title without adding meaning about path format (absolute vs relative), whether the path must exist, or what constitutes a valid input. It fails to add any semantic value beyond the parameter name.
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 uses a specific verb ('Return metadata') and resource ('for a path'), and enumerates the returned fields (size, mtime, mode, is_dir, is_file). This clearly distinguishes fs_stat from siblings like fs_read (content) and fs_list_dir (directory entries), so an agent knows exactly what operation this is.
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 that this tool is for inspecting file metadata rather than content, but it never explicitly says when to use it versus fs_read or fs_list_dir. There is no when-to-use guidance, no exclusions, and no mention of alternatives; the agent must infer the intended use from the tool name and the words 'metadata'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.