Verify if a file is accessible and not locked by another process before opening or modifying it.
Check whether a file can be opened and whether it appears locked by another process.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It discloses the two checks (openable, locked) but does not say what the tool returns, whether the 'can be opened' check actually attempts to open the file (and whether that has side effects), or how 'locked by another process' is determined. For a probe tool whose entire value is its verdict, the outcome semantics are undisclosed.
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 18-word sentence that leads with the verb 'Check' and states the two checks without filler. Every word earns its place, and there is no redundant restatement of the tool name or schema content.
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?
With no output schema, no annotations, and a 0%-coverage parameter schema, the description is the only source of context, and it does not explain how an agent interprets the result (boolean? structured status?) or what distinguishes the two checks (e.g., does a locked file also count as 'cannot be opened'?). An agent cannot reliably act on this tool's outcome with the information given.
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 for the undocumented 'path' parameter. It adds only the implicit notion that the path identifies 'a file,' and says nothing about accepted path formats (absolute, relative, workspace-resolved), whether the file must exist, or constraints like local vs. network paths. Even with a single parameter, the agent is left guessing about path conventions.
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 names a specific verb ('check') and resource ('file') with two concrete aspects: openability and lock status. This distinguishes it from siblings like open_document, scan_model_files, and get_file_composition, none of which perform an access probe. However, the phrase 'appears locked by another process' is slightly hedged and leaves the precise meaning of the check ambiguous.
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 given on when to use this tool versus alternatives. It does not state typical preconditions (e.g., use before open_document, or to diagnose a failed open), nor does it name any alternative tools or exclusion cases. With roughly 130 siblings, an agent must infer the intended usage context entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.