Skip to main content
Glama

load_example

Copies a worked example’s files to a working folder and loads them so you can follow its tutorial and continue the analysis node by node.

Instructions

N0 for a worked example: copy its files to a working folder (dest, default ~/sima-examples/; files already there are kept) and load them. An example from univariate models loads them as load_pre does, and goes on with run_gate. An example from RAW DATA (the vector first, as Tiao and Box or Lutkepohl and Poskitt) loads the table as load_data does, and goes on with characterize. From there the analysis is the usual one, node by node, the analyst deciding at every pause.

Before going on, READ its tutorial, sima://example/<name>: at each step it says what to look at and what the original analysis found, which you add after each report ("In the paper: ..."). The tools do not change in a tutorial; the explanation of the method is the manual it names.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "load_example"
  }
}

Input Schema

NameRequiredDescriptionDefault
destNo
nameNojenkins_alavi
sessionNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose useful traits: a default destination path and that 'files already there are kept' (so it does not silently overwrite). It leaves out what 'load them' does to session state, what happens if `name` is unknown, whether the directory is created, and any failure behavior.

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

Conciseness2/5

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

The action is front-loaded in the first sentence, but the rest is a rambling, jargon-heavy narrative with parentheticals and a garbled lead-in ('N0 for...'), forcing the agent to parse workflow prose to extract the operation. Relevance is fair, but the structure is loose and the phrasing partly ungrammatical.

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?

An output schema exists, so return values need not be described, and the workflow context around the tool is unusually rich. However, for a 3-parameter tool at 0% schema coverage, the undocumented `session` parameter and the absence of error/validation behavior leave the definition short of complete.

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 0%, so the description must compensate. It explains `dest` well (default ~/sima-examples/<name>, existing files preserved) and implies `name` is the example identifier via 'sima://example/<name>', but `session` is never mentioned and the default example name is not noted — partial compensation only.

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 core action is stated concretely: 'copy its files to a working folder (dest, default ~/sima-examples/<name>; files already there are kept) and load them', which is a specific verb+resource. It also distinguishes two flavors of example (univariate models vs raw-data) and what each leads to, which differentiates it from load_data/load_pre. The garbled opening ('N0 for a worked example') blunts the front-load but the substance is clear.

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

Usage Guidelines4/5

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

It gives real routing: after loading, a univariate example goes on with run_gate, a raw-data example goes on with characterize, and it instructs the agent to READ `sima://example/<name>` before proceeding. It does not explicitly contrast when to call load_example versus load_data or examples, so exclusion guidance is missing.

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