Skip to main content
Glama
santoshray02

CSV Editor

by santoshray02

get_history

Retrieve operation history for a CSV editing session to track changes and review data manipulation steps.

Instructions

Get operation history for a session.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
session_idYes
limitNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • MCP tool registration for 'get_history'. This thin wrapper registers the tool with FastMCP and delegates to the main handler in history_operations.py.
    async def get_history(
        session_id: str,
        limit: Optional[int] = None,
        ctx: Context = None
    ) -> Dict[str, Any]:
        """Get operation history for a session."""
        return await _get_operation_history(session_id, limit, ctx)
  • Primary handler logic for the get_history tool. Retrieves the session, calls session.get_history(limit), handles errors, logs via ctx, and returns OperationResult.
    async def get_operation_history(
        session_id: str,
        limit: Optional[int] = None,
        ctx: Context = None
    ) -> Dict[str, Any]:
        """
        Get operation history for a session.
        
        Args:
            session_id: Session identifier
            limit: Maximum number of operations to return
            ctx: FastMCP context
            
        Returns:
            Dict with history and statistics
        """
        try:
            manager = get_session_manager()
            session = manager.get_session(session_id)
            
            if not session:
                return OperationResult(
                    success=False,
                    message="Session not found",
                    error=f"No session with ID: {session_id}"
                ).model_dump()
            
            if ctx:
                await ctx.info(f"Getting operation history for session {session_id}")
            
            result = session.get_history(limit)
            
            if result["success"]:
                return OperationResult(
                    success=True,
                    message="History retrieved successfully",
                    session_id=session_id,
                    data=result
                ).model_dump()
            else:
                return OperationResult(
                    success=False,
                    message="Failed to get history",
                    error=result.get("error")
                ).model_dump()
                
        except Exception as e:
            logger.error(f"Error getting history: {str(e)}")
            if ctx:
                await ctx.error(f"Failed to get history: {str(e)}")
            return OperationResult(
                success=False,
                message="Failed to get history",
                error=str(e)
            ).model_dump()
  • CSVSession.get_history method called by the handler. Delegates to history_manager.get_history and adds statistics, or falls back to legacy history.
    def get_history(self, limit: Optional[int] = None) -> Dict[str, Any]:
        """Get operation history."""
        if not self.history_manager:
            # Return legacy history if new history is not enabled
            return {
                "success": True,
                "history": self.operations_history[-limit:] if limit else self.operations_history,
                "total": len(self.operations_history)
            }
        
        try:
            history = self.history_manager.get_history(limit)
            stats = self.history_manager.get_statistics()
            
            return {
                "success": True,
                "history": history,
                "statistics": stats
            }
        except Exception as e:
            logger.error(f"Error getting history: {str(e)}")
            return {"success": False, "error": str(e)}
  • Core HistoryManager.get_history implementation that slices recent history entries and enriches with index, current status, and restore capability.
    def get_history(self, limit: Optional[int] = None) -> List[Dict[str, Any]]:
        """Get operation history."""
        history_list = []
        
        start = 0 if limit is None else max(0, len(self.history) - limit)
        
        for i, entry in enumerate(self.history[start:], start=start):
            history_dict = entry.to_dict()
            history_dict["index"] = i
            history_dict["is_current"] = (i == self.current_index)
            history_dict["can_restore"] = entry.data_snapshot is not None
            history_list.append(history_dict)
        
        return history_list
Behavior2/5

Does 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 states 'Get operation history' but doesn't describe what the history includes (e.g., timestamps, operation types, user details), whether it's paginated or limited, or if it requires specific permissions. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

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?

The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose ('Get operation history') and efficiently specifies the scope ('for a session'). Every part of the sentence contributes directly to understanding the tool's function.

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

Completeness3/5

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

Given the tool has an output schema (which likely defines return values), the description doesn't need to explain outputs. However, with no annotations, 0% schema coverage for inputs, and multiple siblings, it lacks context on usage, parameter details, and behavioral traits. It's minimally viable but has clear gaps in guiding effective tool selection and invocation.

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

Parameters2/5

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

The input schema has 0% description coverage, so the description must compensate. It mentions 'for a session', which aligns with the 'session_id' parameter, but doesn't explain what a session ID is or how to obtain it. It doesn't address the 'limit' parameter at all, leaving its purpose (e.g., pagination, result capping) undocumented. This fails to add meaningful semantics beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'operation history for a session', making the purpose understandable. It distinguishes from siblings like 'clear_history' or 'export_history' by focusing on retrieval rather than modification or export. However, it doesn't specify what 'operation history' entails (e.g., types of operations, format), leaving some ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. While the description implies it's for retrieving history, it doesn't mention when to choose this over 'export_history' (for file output) or 'restore_to_operation' (for reverting to a specific point), nor does it specify prerequisites like needing an active session. This lack of context makes usage unclear.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/santoshray02/csv-editor'

If you have feedback or need assistance with the MCP directory API, please join our Discord server