Skip to main content
Glama
sangingeum
by sangingeum

history_get

Read-onlyIdempotent

Inspect one recorded filesystem operation to view status, actor, paths, before/after hashes, and modes. Read-only; no file content is returned.

Instructions

Show one recorded operation: status, actor, paths, before/after hashes and modes.

    Read-only. Unknown identifiers are OPERATION_NOT_FOUND. No file content is
    returned; use history_diff for a before/after diff.
    

Input Schema

NameRequiredDescriptionDefault
operation_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.8

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotent/non-destructive, so the bar is lower, yet the description adds genuinely new behavior: the OPERATION_NOT_FOUND failure mode for unknown identifiers and the explicit boundary that no file content is returned. It does not address ordering, size of result, or permissions, which keeps it from a 5.

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?

Three short sentences, front-loaded with what is returned, followed by safety/error and the sibling redirect. No filler and nothing repeated verbatim from the schema.

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 compensates by enumerating the returned fields, and annotations cover the safety profile. The remaining gap is that it never says where operation_id values come from (history_list), which an agent needs to actually reach a successful call.

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

Parameters4/5

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

Schema coverage is 0%, so the description must carry the burden for the single parameter and it largely does: operation_id is framed as identifying one recorded operation, and the 'Unknown identifiers are OPERATION_NOT_FOUND' clause tells the agent what an invalid value produces.

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?

States a specific verb and resource ('Show one recorded operation') and immediately enumerates what is returned: status, actor, paths, before/after hashes and modes. It explicitly contrasts itself with the sibling history_diff, so an agent can distinguish the two without opening 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear retrieval context and names the alternative: 'use history_diff for a before/after diff.' It does not, however, explain how an operation_id is obtained (e.g., via history_list) or state when this is a poor choice beyond the diff case.

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