Skip to main content
Glama

tealflow_snapshot_renv_environment

Idempotent

Record the current state of R package dependencies into renv.lock for a reproducible project environment. Use after installing or updating packages to create a consistent snapshot.

Instructions

Create an renv snapshot of the current R project environment.

This tool captures the current state of installed R packages and records them in renv.lock. This creates a reproducible record of your project's dependencies that can be restored later or shared with others.

When to use this tool:

  • After installing new packages

  • After updating existing packages

  • Before sharing your project with others

  • To create a reproducible checkpoint of your environment

Requirements:

  • renv must already be initialized (use tealflow_setup_renv_environment first)

  • Project must have an active renv environment

Args: project_path (str, optional): ABSOLUTE path to the R project directory. MUST be an absolute path (e.g., "/home/user/project" or "C:\Users\user\project"). Relative paths like "." will resolve to the MCP server's directory, not the user's project. Defaults to "." but should always be explicitly provided as an absolute path. response_format (str, optional): Output format - 'json' or 'markdown'. Defaults to 'json'.

Returns: str: JSON/markdown with status, message, and logs_excerpt.

Error Types: - filesystem_error: Project path does not exist - rscript_not_found: R is not installed or not in PATH - renv_not_initialized: renv has not been initialized in this project - snapshot_failed: Failed to create renv snapshot - execution_error: Unexpected error during snapshot

Examples: - Snapshot current directory: (no parameters needed) - Snapshot specific project: project_path="/path/to/project" - Get markdown output: response_format="markdown"

Note: This tool only snapshots packages that are used in your project code. Make sure you have library() calls in global.R or your R scripts for packages you want to include in the snapshot.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_pathNo.
response_formatNojson

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

Annotations already provide idempotentHint=true and destructiveHint=false. The description adds useful context about writing to renv.lock, only snapshotting packages used in project code, and lists specific error types. It does not contradict annotations, though it could be slightly more explicit about overwriting an existing lockfile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with markdown sections for purpose, usage, requirements, arguments, returns, errors, and examples. It is somewhat long, but every section contributes value, especially the absolute path warning and error type list. A slightly shorter version could be more concise, but the structure and front-loading are effective.

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

Completeness5/5

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

The description covers when to use, prerequisites, parameter semantics, return value summary, error types, and a note about library() calls. Since an output schema exists, the lack of detailed return format documentation is acceptable. The context is complete for a well-understood tool with moderate complexity.

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

Parameters5/5

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

The input schema has zero descriptions, but the description fully compensates by explaining that project_path must be an absolute path and warning about relative path resolution, and by defining response_format values ('json' or 'markdown'). This adds significant meaning beyond the schema.

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?

The description states 'Create an renv snapshot of the current R project environment.' with a specific verb ('Create'), resource ('renv snapshot'), and scope ('current R project environment'). It clearly distinguishes from the sibling tool tealflow_setup_renv_environment by noting that renv must be initialized first.

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

Usage Guidelines5/5

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

An explicit 'When to use this tool' section lists concrete scenarios such as after installing or updating packages, before sharing, and for reproducibility. It also provides a requirement referencing tealflow_setup_renv_environment, which acts as a clear alternative/context for when this tool should not be used.

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/Appsilon/TealFlowMCP'

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