termix_hosts_get_recent_filesGet a list of recent files for a specific host by host ID. Use this to review recently accessed files on a self-hosted Termix instance.
Get recent files. Retrieves a list of recent files for a specific host.
| Name | Required | Description | Default |
|---|---|---|---|
| hostId | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only that it retrieves a list, which is consistent. It does not disclose any additional behavior such as ordering, limits, or authentication requirements, but for a read-only list operation this is acceptable.
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 short sentences with no wasted words. The core action and scope are front-loaded, making it easy to parse. It is appropriately concise for a simple retrieval tool, though it could add a bit more context without bloat.
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 single parameter, rich annotations, and no output schema, the description is mostly sufficient but leaves out details like what constitutes 'recent' (time window, limit, ordering). Since it is a getter with no side effects, the missing context is a minor gap, but an agent might benefit from knowing if results are sorted or capped.
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% and the description does not elaborate on hostId beyond saying 'specific host'. The schema provides type and range but no semantic meaning; the description does not compensate for the lack of parameter documentation, leaving the agent to infer that hostId identifies the host.
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 states a clear action (retrieves a list) and resource (recent files) scoped to a specific host via hostId. It distinguishes from most siblings by its focus on 'recent files' as opposed to pinned files, command history, or other host data, though it does not explicitly name alternatives.
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 like termix_hosts_get_pinned_files or termix_hosts_get_command_history. The context is implicit (retrieving recent files for a host) but there are no explicit exclusions or alternative pointers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.