Gretl MCP

by OndrejLapes

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.1
Disambiguation4/5
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.
Naming Consistency3/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.1/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
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. 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![GretlMCP MCP server](https://glama.ai/mcp/servers/OndrejLapes/GretlMCP/badges/card.svg)](https://glama.ai/mcp/servers/OndrejLapes/GretlMCP)

Score Badge

Copy to your README.md:

[![GretlMCP MCP server](https://glama.ai/mcp/servers/OndrejLapes/GretlMCP/badges/score.svg)](https://glama.ai/mcp/servers/OndrejLapes/GretlMCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/OndrejLapes/GretlMCP'

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