Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Gretl MCP run OLS on auto dataset and show coefficients"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Built for AI agents: run Hansl/Gretl workflows, get graph screenshots, and view calculations in the real Gretl GUI.
It lets MCP clients run Gretl/Hansl scripts, raw Gretl command lines, existing
.inp files, package operations, package builds, help lookups, dataset
summaries, and OLS models. The generic gretl_run_script tool is the main path
for prompt-generated Gretl workflows: the client writes Hansl from the user's
request, runs it through Gretl, and returns Gretl's output plus generated
artifacts.
Keywords: Claude Gretl, MCP econometrics, Hansl AI, Gretl GUI automation.
Scriptable Gretl control through gretlcli.
GUI-first workflow tools that launch gretl.exe and fail if the GUI did not open.
Capability discovery for Gretl commands, functions, and package commands.
Generic execution tools for full Hansl scripts, command lists, and local
.inp script files.
Package tools for pkg and makepkg workflows from the Gretl Function
Package Guide.
High-level tools for version checks, command help, dataset summaries, and OLS.
Stdio transport, compatible with common MCP clients.
Safe defaults for arbitrary scripts, with documented escape hatches.
Related MCP server: Stata MCP Server
Node.js 20 or newer.
Gretl 2026b or newer with gretlcli available.
An MCP client that supports stdio servers.
One-command install (after npm publish):
npx -y gretl-mcp@latest --versionLocal install from GitHub:
git clone https://github.com/OndrejLapes/GretlMCP.git
cd GretlMCP
npm install
npm run buildThen point your MCP client at the built server:
{
"mcpServers": {
"gretl": {
"command": "node",
"args": ["C:\\Users\\YOUR_USER\\GretlMCP\\dist\\index.js"],
"env": {
"GRETL_CLI": "C:\\Users\\YOUR_USER\\tools\\gretl\\gretlcli.exe",
"GRETL_GUI": "C:\\Users\\YOUR_USER\\tools\\gretl\\gretl.exe"
}
}
}
}Forecast output example (actual vs forecast):
Forecast error panel:
Download Gretl from the official page: https://gretl.sourceforge.net/win32/
For a no-admin setup, extract the zip archive to:
C:\Users\YOUR_USER\tools\gretlVerify:
& C:\Users\YOUR_USER\tools\gretl\gretlcli.exe --versionInstall via Homebrew (if available on your setup) or the Gretl project site:
brew install gretl
gretlcli --versionInstall from your distro packages, then verify:
sudo apt-get install gretl # Debian/Ubuntu example
gretlcli --versionUse this JSON config for stdio MCP clients:
{
"mcpServers": {
"gretl": {
"command": "node",
"args": ["C:\\Users\\YOUR_USER\\GretlMCP\\dist\\index.js"],
"env": {
"GRETL_CLI": "C:\\Users\\YOUR_USER\\tools\\gretl\\gretlcli.exe",
"GRETL_GUI": "C:\\Users\\YOUR_USER\\tools\\gretl\\gretl.exe"
}
}
}
}After npm publication, the standard MCP config is:
{
"mcpServers": {
"gretl": {
"command": "npx",
"args": ["-y", "gretl-mcp@latest"],
"env": {
"GRETL_CLI": "C:\\Users\\YOUR_USER\\tools\\gretl\\gretlcli.exe",
"GRETL_GUI": "C:\\Users\\YOUR_USER\\tools\\gretl\\gretl.exe"
}
}
}
}Local GitHub build:
claude mcp add gretl node C:\Users\YOUR_USER\GretlMCP\dist\index.jsnpm install path:
claude mcp add gretl npx -y gretl-mcp@latestLocal GitHub build:
[mcp_servers.gretl]
command = "node"
args = ["C:\\Users\\YOUR_USER\\GretlMCP\\dist\\index.js"]
[mcp_servers.gretl.env]
GRETL_CLI = "C:\\Users\\YOUR_USER\\tools\\gretl\\gretlcli.exe"
GRETL_GUI = "C:\\Users\\YOUR_USER\\tools\\gretl\\gretl.exe"npm install path:
[mcp_servers.gretl]
command = "npx"
args = ["-y", "gretl-mcp@latest"]
[mcp_servers.gretl.env]
GRETL_CLI = "C:\\Users\\YOUR_USER\\tools\\gretl\\gretlcli.exe"
GRETL_GUI = "C:\\Users\\YOUR_USER\\tools\\gretl\\gretl.exe"Use the local JSON config above. If the client asks for a command and args separately, use:
command: node
args: C:\Users\YOUR_USER\GretlMCP\dist\index.jscode --add-mcp "{\"name\":\"gretl\",\"command\":\"node\",\"args\":[\"C:\\\\Users\\\\YOUR_USER\\\\GretlMCP\\\\dist\\\\index.js\"],\"env\":{\"GRETL_CLI\":\"C:\\\\Users\\\\YOUR_USER\\\\tools\\\\gretl\\\\gretlcli.exe\",\"GRETL_GUI\":\"C:\\\\Users\\\\YOUR_USER\\\\tools\\\\gretl\\\\gretl.exe\"}}"Ask your agent:
Run a Gretl forecasting dashboard with AR, ARIMA, and VAR. Save plots and compare RMSE/MAE.The MCP response includes generated artifact paths, workspace/script paths, and GUI launch details.
gretl-mcp supports environment variables and CLI flags.
Environment variables:
GRETL_CLI: optional path to gretlcli or gretlcli.exe.
GRETL_GUI: optional path to gretl or gretl.exe.
GRETLMCP_WORKSPACE_DIR: optional directory for Gretl run workspaces.
GRETLMCP_OPEN_GUI: set to false to stop tools from opening Gretl windows by default.
GRETLMCP_REQUIRE_GUI: set to false to allow CLI-only success when GUI opening is disabled or unavailable.
GRETLMCP_ENFORCE_GUI_ONLY: set to true to reject any headless workflow request.
CLI options:
gretl-mcp --gretl-cli C:\Users\YOUR_USER\tools\gretl\gretlcli.exe
gretl-mcp --gretl-gui C:\Users\YOUR_USER\tools\gretl\gretl.exe
gretl-mcp --workspace C:\Users\YOUR_USER\gretl-mcp-runs
gretl-mcp --enforce-gui-only
gretl-mcp --allow-headless
gretl-mcp --help
gretl-mcp --versiongretl_version: checks Gretl availability.
gretl_gui_version: checks Gretl GUI availability.
gretl_gui_launch: launches the visible Gretl desktop GUI.
gretl_capabilities: lists installed Gretl commands, functions, and package help.
gretl_run_script: runs a Gretl/Hansl script and requires GUI opening by default.
gretl_run_commands: runs raw Gretl command lines and requires GUI opening by default.
gretl_run_script_file: runs an existing local .inp file and requires GUI opening by default.
gretl_package: runs native pkg actions such as install, query, run-sample, unload, remove, and index.
gretl_make_package: builds .gfn or .zip function packages with makepkg.
gretl_help: returns Gretl help for a command.
gretl_dataset_summary: opens a local dataset, returns summary statistics, and requires GUI opening by default.
gretl_ols: opens a local dataset, estimates an OLS model, and requires GUI opening by default.
gretl_run_script, gretl_run_commands, and gretl_run_script_file default to
safeMode: true, which blocks common shell-like commands and absolute file
reads/writes. This is a guardrail, not a complete sandbox. Use safeMode: false
only for trusted local work.
Dataset helper tools reject URLs and require paths to existing local files.
examples/homework-variance-ftest.inp: Gretl script for a homework-style
F test with critical-value and p-value calculations.
examples/forecasting-dashboard.inp: Macro forecasting dashboard with AR,
ARIMA, VAR, forecast plots, and an RMSE/MAE comparison table.
examples/specification-curve-analysis.inp: 32-model robustness sweep for an
education coefficient with curve, confidence bands, and histogram plots.
Econometrics teaching aid with visible Gretl GUI workflows.
Textbook replication and assignment automation.
Forecasting dashboards (AR/ARIMA/VAR) with artifact outputs.
Monte Carlo and stress-testing workflows for research.
Reproducible research pipelines via saved scripts and Gretl .inp files.
By default, the workflow tools open their generated Hansl script in the real
Gretl desktop app while also returning structured MCP output. More importantly,
they now treat GUI opening as required outside CI. If the Gretl window does not
open, the tool returns ok: false even when the CLI script itself succeeded.
Set displayInGretl: false and requireGui: false on a tool call, or set
GRETLMCP_OPEN_GUI=false together with GRETLMCP_REQUIRE_GUI=false, to allow
CLI-only automation.
For clients that should never bypass the desktop app, set
GRETLMCP_ENFORCE_GUI_ONLY=true or launch the server with --enforce-gui-only.
In that mode, the workflow tools reject displayInGretl: false and
requireGui: false instead of honoring them.
gretl_gui_launch can also be called directly. It starts the real Gretl desktop
application, opens a local dataset/script file, or writes a prompted Hansl script
and launches Gretl with --run.
This is not full click-by-click GUI control by itself. If you want the agent to observe screenshots, click menus, and make choices exactly like a human, the MCP client also needs desktop automation or computer-use capability. Gretl MCP now provides the Gretl-side launch surface for that workflow.
npm install
npm run typecheck
npm test
npm run build
npm run smoke
npm run stressnpm run stress drives the built MCP server through broader prompt-style
workflows: macro forecasting, structural breaks, Monte Carlo simulation,
textbook replication, diagnostic automation, NLS, mixed-frequency compaction,
panel models, GARCH graphs, IV simulation, and a reproducible project. The
foreign-language stress case is dependency-gated and requires a real Python,
Rscript, or Octave executable on PATH.
To surface stress outputs for docs or QA snapshots:
npm run stressThen inspect the reported workspace for generated graphs/tables.
Run the built server:
node dist/index.jsThis project is structured for GitHub, npm, and MCP Registry metadata:
GitHub hosts source code, issues, docs, releases, and CI.
npm will provide the easiest user install path after publication.
server.json is included for registry publish.
Before publishing to npm or the MCP Registry, review docs/publishing.md.
Issues and pull requests are welcome. See CONTRIBUTING.md for contribution
flow and expectations.
List Gretl commands, built-in functions, and package-management help from the installed Gretl version.
| Name | Required | Description | Default |
|---|---|---|---|
| gretlCliPath | No | ||
| gretlGuiPath | No | ||
| displayInGretl | No | Open the generated help script in Gretl GUI. Defaults to false for this reference tool. | |
| timeoutSeconds | No | ||
| includeFunctions | No | Include Gretl's built-in accessors and functions from help functions. | |
| includePackageHelp | No | Include help for pkg and makepkg. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'list... from the installed Gretl version' but does not mention whether this is a read-only operation, if it invokes a Gretl script, or what the output format is. Side effects and permission requirements are omitted.
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 sentence, very concise, but it sacrifices detail. It is appropriately front-loaded but does not earn its place by providing sufficient context for the 6 parameters and diverse sibling tools.
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 no annotations, no output schema, and a moderate schema coverage, the description is too brief. It does not explain the output, default behavior, or how it relates to siblings like 'gretl_help' or 'gretl_gui_launch'. Important usage context is missing.
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?
With 50% schema description coverage, some parameters already have descriptions in the schema. However, the tool description itself adds no additional meaning to any parameter—it does not explain how parameters affect the result or context. It fails to compensate for the missing schema descriptions.
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 clearly states the tool lists Gretl commands, built-in functions, and package management help. It is specific about what is listed, but does not distinguish from sibling tool 'gretl_help' which likely provides targeted help for specific items.
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?
The description implies the tool is used to retrieve a list of installed capabilities, but it provides no explicit guidance on when to use this tool vs. other siblings like 'gretl_help' or 'gretl_version'. No when-not-to or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a Gretl-supported dataset file, return summary statistics, and open the same workflow in Gretl GUI by default.
| Name | Required | Description | Default |
|---|---|---|---|
| safeMode | No | ||
| requireGui | No | Require the visible Gretl GUI to open for this workflow. Defaults to true outside CI. | |
| datasetPath | Yes | Path to a CSV, gdt, Excel, Stata, SPSS, or other Gretl-supported dataset. | |
| gretlCliPath | No | ||
| gretlGuiPath | No | ||
| displayInGretl | No | Open a visible Gretl GUI script window for this workflow. Defaults to true outside CI. | |
| guiNewInstance | No | ||
| timeoutSeconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions opening a GUI by default and returning summary stats, but omits important behavior: error handling (e.g., missing file), side effects (file modification?), required permissions, and the nature of the GUI interaction. The timeout parameter suggests blocking behavior but is not explained.
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 concise sentence, front-loading the core functionality. However, it compresses three actions (open file, return stats, open GUI) into one clause, which could be clearer if split. No wasted words, but structure is minimal.
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 no output schema, no annotations, and 8 parameters (only 1 required), the description is incomplete. It does not explain the nature of the summary statistics returned, error behavior, or the interplay between parameters like safeMode and requireGui. For a tool that likely returns complex data, this is insufficient.
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 only 38% (3 of 8 parameters have descriptions). The description adds no parameter-level information beyond the schema, missing opportunities to explain safeMode, guiNewInstance, or timeoutSeconds. The reference to 'open the same workflow in Gretl GUI by default' weakly relates to displayInGretl but is not explicit.
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 clearly states the tool opens a Gretl dataset file and returns summary statistics, with an optional GUI opening. This distinguishes it from sibling tools like gretl_ols (runs OLS) and gretl_run_script (runs scripts). However, it does not specify which summary statistics are returned, slightly reducing clarity.
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?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. Sibling tools are listed in context but not referenced. An agent cannot determine if this is appropriate for a given task without additional reasoning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch the visible Gretl desktop GUI, optionally opening a local dataset/script or running a provided script on startup.
| Name | Required | Description | Default |
|---|---|---|---|
| script | No | Optional Gretl/Hansl script to write and open with --run in the GUI. | |
| english | No | Force Gretl GUI to use English. | |
| filePath | No | Optional local dataset or script file to open in the Gretl GUI. | |
| safeMode | No | When script is provided, block shell-like commands and absolute file reads/writes. | |
| runScript | No | When filePath points to a script, launch Gretl with --run filePath. | |
| newInstance | No | Launch a new Gretl GUI instance instead of reusing an existing one. | |
| gretlGuiPath | No | Optional explicit path to gretl or gretl.exe. | |
| workspaceRoot | No | Optional directory where GUI script workspaces are created. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It lacks details on mutability, system requirements, blocking behavior, or side effects. Parameters like safeMode and newInstance hint at behaviors but are not explained in the description.
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 sentence (20 words) that front-loads the core purpose. There is no redundancy or unnecessary information.
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?
Despite 8 optional parameters and no output schema, the description only hints at file/script usage. It does not explain parameter interactions, prerequisites, or return values, leaving gaps for an agent to infer correct invocation.
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 coverage is 100%, so baseline is 3. The description adds minor context ('optionally opening... or running a provided script') that maps to script and filePath, but does not significantly enhance meaning beyond the schema.
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 clearly states the tool launches the Gretl GUI, with optional opening of a dataset/script or running a script on startup. This specific verb+resource distinguishes it from siblings like gretl_run_script (headless) and gretl_gui_version (version check).
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?
The description implies usage for launching the GUI, but does not explicitly compare to sibling tools like gretl_run_script or specify when not to use it. No alternatives are mentioned, so guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the installed Gretl GUI version by running gretl.exe --version.
| Name | Required | Description | Default |
|---|---|---|---|
| gretlGuiPath | No | Optional explicit path to gretl or gretl.exe. | |
| timeoutSeconds | No | Maximum time to wait for gretl.exe --version. Defaults to 10 seconds. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only mentions the command executed, omitting details such as output format, error handling, permission requirements, and side effects. The agent lacks critical information about the tool's behavior.
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, clear sentence that directly states the tool's primary action. It is concise and front-loaded with the essential information, wasting no words.
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 absence of an output schema and the simplicity of the tool, the description should at least hint at the return format and possible failure scenarios. It does not, leaving the agent with incomplete context about expected output and error states.
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?
The input schema already covers both parameters with descriptions, so the baseline is 3. The description adds no further parameter information, but it also does not contradict or mislead.
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 clearly states that the tool returns the installed Gretl GUI version by running a specific command. This verb+resource specification is precise and helps distinguish it from sibling tools like gretl_version.
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?
The description provides no guidance on when to use this tool versus its siblings or when not to use it. There are no explicit use cases, prerequisites, or exclusion criteria, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask Gretl for command help, for example ols, summary, open, arima, or gnuplot. By default this also requires opening the help workflow in the visible Gretl GUI.
| Name | Required | Description | Default |
|---|---|---|---|
| requireGui | No | Require the visible Gretl GUI to open for this workflow. Defaults to true outside CI. | |
| commandName | Yes | Gretl command name. | |
| gretlCliPath | No | ||
| gretlGuiPath | No | ||
| displayInGretl | No | Open a visible Gretl GUI script window for this help request. Defaults to true outside CI. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially discloses behavior: it states that by default it 'requires opening the help workflow in the visible Gretl GUI'. However, it does not mention return format, side effects (e.g., no data modification), or what happens if no GUI is available.
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 sentences, front-loaded with the core purpose and examples, and no extraneous words. It is appropriately sized for the tool's simplicity.
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 5 parameters, no output schema, and the tool's nature as a help command, the description covers the main purpose and default behavior. However, it lacks information about what the tool returns (text or GUI window) and the detailed interaction with the GUI parameters, leaving some context incomplete.
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 coverage is 60%, but the description does not add significant meaning for the 3 described parameters (commandName, requireGui, displayInGretl) beyond the schema. The two undocumented parameters (gretlCliPath, gretlGuiPath) are left unexplained, and the description fails to compensate for this gap.
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 clearly states the verb 'Ask' and the resource 'Gretl for command help', with specific examples like ols, summary. It distinguishes well from sibling tools such as gretl_ols (which runs OLS rather than showing help).
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?
The description provides context about the default GUI requirement but does not explicitly state when to use this tool versus alternatives like gretl_run_script or gretl_ols. No when-not or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a Gretl function package (.gfn or .zip) using the native makepkg command. By default this also requires opening the generated workflow in the visible Gretl GUI.
| Name | Required | Description | Default |
|---|---|---|---|
| index | No | Write the auxiliary package XML index file. | |
| quiet | No | Use makepkg --quiet. | |
| requireGui | No | Require the visible Gretl GUI to open for this workflow. Defaults to true outside CI. | |
| packagePath | Yes | Output path ending in .gfn or .zip. | |
| gretlCliPath | No | ||
| gretlGuiPath | No | ||
| translations | No | Write the auxiliary i18n C strings file. | |
| keepWorkspace | No | ||
| workspaceRoot | No | ||
| displayInGretl | No | Open the generated makepkg script in Gretl GUI. Defaults to true outside CI. | |
| guiNewInstance | No | ||
| timeoutSeconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only notes that by default the tool requires opening the generated workflow in the visible Gretl GUI. It fails to mention other important behaviors such as side effects on files, permission requirements, or error handling, which are critical for a 12-parameter mutation tool.
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 sentences, directly states the main action and a key default behavior. It is front-loaded and contains no superfluous information, making it highly concise and well-structured.
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 tool's complexity (12 parameters, no output schema, no annotations), the description is insufficient. It only covers the basic purpose and one behavioral aspect, leaving gaps about workflow, side effects, and parameter interactions.
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 50%, so the baseline is 3. The description adds no parameter-specific information beyond what is in the schema. The mention of 'by default requires GUI' loosely relates to parameters like requireGui and displayInGretl but does not explicitly clarify them.
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 clearly states the tool builds a Gretl function package using the native makepkg command, and specifies the output formats (.gfn or .zip). However, it does not differentiate from the sibling tool 'gretl_package', leaving potential ambiguity about which to use.
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?
The description provides no guidance on when to use this tool versus alternatives such as gretl_package or gretl_run_script. It does not mention prerequisites, typical scenarios, or conditions to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a dataset, estimate an OLS model, and open the same workflow in Gretl GUI by default.
| Name | Required | Description | Default |
|---|---|---|---|
| safeMode | No | ||
| requireGui | No | Require the visible Gretl GUI to open for this workflow. Defaults to true outside CI. | |
| datasetPath | Yes | Path to a Gretl-supported dataset. | |
| gretlCliPath | No | ||
| gretlGuiPath | No | ||
| displayInGretl | No | Open a visible Gretl GUI script window for this workflow. Defaults to true outside CI. | |
| guiNewInstance | No | ||
| timeoutSeconds | No | ||
| includeConstant | No | ||
| dependentVariable | Yes | Dependent variable name. | |
| independentVariables | Yes | Independent variable names. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions opening a GUI by default but does not address side effects (e.g., data modification, file creation), required permissions, or error handling. The safeMode parameter is not explained in the description.
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 sentence, efficiently conveying the core action. However, it is slightly under-specified, lacking details that would improve usefulness without expanding length.
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 11 parameters, no output schema, and no annotations, the description is too brief to provide complete context. Missing information includes parameter meaning, return values, error conditions, and behavioral specifics beyond 'opens GUI.'
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 coverage is 45% (below 50%), and the description adds no parameter-level information beyond what the schema provides. Critical details about parameters like safeMode, gretlCliPath, and timeoutSeconds are missing, requiring the agent to rely solely on the schema.
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 clearly states the tool's purpose: opening a dataset, estimating an OLS model, and opening the workflow in Gretl GUI. This specific verb+resource combination distinguishes it from sibling tools like gretl_run_script or gretl_dataset_summary.
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?
The description mentions 'by default' but does not provide explicit guidance on when to use this tool versus alternatives (e.g., gretl_run_commands). No exclusions or prerequisites are stated, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install, query, run samples for, unload, remove, or index Gretl function/data packages using the native pkg command. By default this also requires opening the generated workflow in the visible Gretl GUI.
| Name | Required | Description | Default |
|---|---|---|---|
| local | No | Use pkg --local for a local .gfn or .zip package file. | |
| quiet | No | Use pkg --quiet. | |
| action | Yes | Gretl pkg action to perform. | |
| staging | No | Use pkg --staging for package installs from Gretl staging. | |
| verbose | No | Use pkg --verbose. | |
| requireGui | No | Require the visible Gretl GUI to open for this workflow. Defaults to true outside CI. | |
| packageName | No | Package name, local package path, URL, or addons for index. Required except index defaults to addons. | |
| gretlCliPath | No | ||
| gretlGuiPath | No | ||
| keepWorkspace | No | ||
| workspaceRoot | No | ||
| displayInGretl | No | Open the generated package command script in Gretl GUI. Defaults to true outside CI. | |
| guiNewInstance | No | ||
| timeoutSeconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially covers behavior by noting the default GUI requirement. However, it omits details on side effects (e.g., file modifications), required permissions, or action-specific consequences for a complex tool with 14 parameters.
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 concise sentence that front- loads the actions. It avoids waste, but for a 14-parameter tool, more structure (e.g., bullet points) could improve scannability.
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?
For a tool with 14 parameters, no output schema, and moderate schema coverage, the description is too brief. It does not explain return values, prerequisites, or how to configure common parameters, leaving significant gaps.
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 57%, but the description adds no parameter details beyond listing actions. Flags like local, quiet, staging, verbose are not explained, missing an opportunity to add value over the schema.
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 clearly states it manages Gretl packages using the native pkg command and lists the supported actions: install, query, run samples, unload, remove, index. This specificity distinguishes it from sibling tools like gretl_make_package.
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 explicit guidance on when to use this tool versus siblings. There is no mention of alternatives or conditions for use; only a default GUI requirement is noted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one or more raw Gretl command lines. By default this also requires opening the same workflow in the visible Gretl GUI.
| Name | Required | Description | Default |
|---|---|---|---|
| commands | Yes | Gretl command lines to run in order. | |
| safeMode | No | When true, blocks shell-like commands and absolute file writes. | |
| requireGui | No | Require the visible Gretl GUI to open for this workflow. Defaults to true outside CI. | |
| gretlCliPath | No | Optional explicit path to gretlcli or gretlcli.exe. | |
| gretlGuiPath | No | Optional explicit path to gretl or gretl.exe. | |
| keepWorkspace | No | Keep the run workspace so generated artifacts remain available. | |
| workspaceRoot | No | Optional directory where run workspaces are created. | |
| displayInGretl | No | Open the generated command script in the visible Gretl GUI. Defaults to true outside CI. | |
| guiNewInstance | No | Open a new Gretl GUI instance for the visible script. | |
| timeoutSeconds | No | Maximum runtime in seconds. Defaults to 30, max 300. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the full burden. Only mentions the default GUI requirement. Lacks details on error handling, output, permissions, or side effects, which is insufficient for a complex tool with 10 parameters.
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?
Two sentences, front-loads purpose. Efficient, but could include more critical information without becoming verbose.
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 10 parameters, no output schema, and no annotations, the description is far from complete. Missing return value, error behavior, and detailed usage context.
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 covers all 10 parameters with descriptions, so baseline 3. The description adds no extra parameter-level meaning beyond the schema.
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?
Description clearly states the tool runs raw Gretl command lines, which is specific. However, it does not explicitly differentiate from siblings like gretl_run_script or gretl_run_script_file, though 'raw command lines' implies a distinction.
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 on when to use this tool versus alternatives. No mention of prerequisites, when to avoid, or when the GUI requirement matters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run any Gretl/Hansl script through gretlcli. By default this also requires opening the same workflow in the visible Gretl GUI.
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | Gretl/Hansl script to run. | |
| safeMode | No | When true, blocks shell-like commands and absolute file writes. | |
| requireGui | No | Require the visible Gretl GUI to open for this workflow. Defaults to true outside CI. | |
| gretlCliPath | No | Optional explicit path to gretlcli or gretlcli.exe. | |
| gretlGuiPath | No | Optional explicit path to gretl or gretl.exe. | |
| keepWorkspace | No | Keep the run workspace so generated artifacts remain available. | |
| workspaceRoot | No | Optional directory where run workspaces are created. | |
| displayInGretl | No | Open a visible Gretl GUI script window for this run. Defaults to true outside CI. | |
| guiNewInstance | No | Open a new Gretl GUI instance for the visible script. | |
| timeoutSeconds | No | Maximum runtime in seconds. Defaults to 30, max 300. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It mentions the GUI requirement and safeMode parameter blocks shell commands, but it fails to explain what happens on execution (e.g., return value, error handling, side effects) or the implications of the many optional parameters.
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 extremely concise with two sentences and no redundant information. It front-loads the core action, but could be improved by including essential behavioral details without sacrificing conciseness.
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 tool's complexity (10 parameters, no output schema, script execution with GUI dependencies), the description is too sparse. It omits critical context about expected outputs, error states, and the interplay between parameters like safeMode and requireGui.
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 coverage is 100% with descriptions for all 10 parameters, so the schema already documents parameter meanings. The description adds only the context of running via gretlcli and the default GUI requirement, which provides marginal extra value beyond the schema.
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 clearly states the action ('Run any Gretl/Hansl script') and resource ('through gretlcli'), which is specific and actionable. However, it does not differentiate from sibling tools like gretl_run_commands or gretl_run_script_file, which also involve running scripts or commands.
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?
The description mentions a default behavior (requiring the GUI) but provides no explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an existing local Gretl .inp script file with gretlcli. By default this also requires opening the same workflow in the visible Gretl GUI.
| Name | Required | Description | Default |
|---|---|---|---|
| safeMode | No | When true, validates the script before running it. | |
| scriptOpt | No | Optional numeric value passed to Gretl as --scriptopt. | |
| requireGui | No | Require the visible Gretl GUI to open for this workflow. Defaults to true outside CI. | |
| scriptPath | Yes | Path to an existing local Gretl .inp script. | |
| gretlCliPath | No | ||
| gretlGuiPath | No | ||
| displayInGretl | No | Open the script file in the visible Gretl GUI after running. Defaults to true outside CI. | |
| guiNewInstance | No | ||
| timeoutSeconds | No | ||
| workingDirectory | No | Working directory for the script. Defaults to the script file directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It mentions GUI dependency but fails to explain effects of many parameters (e.g., safeMode, timeoutSeconds, displayInGretl) or the 'same workflow' concept. Missing details on output and error behavior.
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?
A single sentence, which is concise but lacks structure. Could better organize information (e.g., separating key behavior from optional details).
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 10 parameters, no output schema, and limited description, the tool is poorly documented. Missing details on parameter interactions, defaults, and return behavior, making it difficult for an agent to use confidently.
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 60%, leaving 40% of parameters undocumented. The tool description adds no parameter-specific information beyond the schema, so it does not compensate for the coverage gap.
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?
Clearly specifies the action (run), resource (local Gretl .inp script file), and key constraint (requires opening same workflow in visible GUI). Distinguishes from siblings by focusing on file execution.
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?
Implies usage context by mentioning GUI requirement, but does not explicitly state when to use this tool vs alternatives like gretl_run_script or gretl_run_commands. No guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the installed Gretl version by running gretlcli.
| Name | Required | Description | Default |
|---|---|---|---|
| gretlCliPath | No | Optional explicit path to gretlcli or gretlcli.exe. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions running gretlcli but fails to disclose potential side effects, error handling (e.g., if gretlcli not found), output format, or whether it modifies anything. Minimal disclosure.
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, front-loaded sentence with zero wasted words. It efficiently conveys the core action and method.
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?
For a simple version-checking tool with one optional parameter, the description is minimally adequate. However, it lacks details on return format, error behavior, and when to use it. Given the sibling tools and no output schema, more context would help.
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 coverage is 100% (one parameter with a clear description). The tool's description adds no new semantics beyond implying the path is used to locate gretlcli. Baseline 3 is appropriate.
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 clearly states the tool returns the installed Gretl version by running gretlcli. It uses a specific verb and resource, distinguishing it from sibling tools like gretl_gui_version which likely returns the GUI version.
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 on when to use this tool vs alternatives (e.g., gretl_gui_version) or prerequisites (e.g., gretlcli must be installed). The description provides no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.1gretl_capabilitiesgretl_dataset_summarygretl_gui_launchgretl_gui_versiongretl_helpgretl_make_packagegretl_olsgretl_packagegretl_run_commandsgretl_run_scriptgretl_run_script_filegretl_versionScored across 12 tools
Tools are mostly distinct: version, launch, script/command execution, package management, help, data summary, and OLS. The three 'run' tools (script, commands, script_file) could cause confusion, but descriptions clarify their different inputs.
All tools share the 'gretl_' prefix, but naming patterns vary: some use verb+noun (gretl_run_script), others use noun-only (gretl_version, gretl_capabilities). While readable, there is no strict verb_noun pattern throughout.
With 12 tools, the server covers essential Gretl operations (version, GUI, script execution, packages, help, data summary, OLS) without being excessive. The count feels well-scoped for the econometrics domain.
The surface includes core tasks: version checking, GUI launching, script execution, package management, help, data summary, and OLS. While missing some advanced models or data manipulation tools, the ability to run arbitrary scripts/commands fills many gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
SEO & marketing toolkit for AI agents: GA4, Search Console, AdSense, GTM, PageSpeed, Trends.
List datasets, schemas, run APL queries, and use prompts for exploration, anomalies, and monitoring.
Give your AI agents the tools to build, manage, and run automation workflows.
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/OndrejLapes/GretlMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
