Skip to main content
Glama
okareo-ai

Okareo MCP Server

Official
by okareo-ai

Get REPS Baseline Material

get_reps_baseline
Read-onlyIdempotent

Discover and fetch REPS agent-evaluation baseline material—scenario banks, drivers, checks, and eval configs—for assessing AI agents across reasoning, execution, performance, and security.

Instructions

Serve REPS agent-evaluation baseline material (scenario banks, drivers, checks, eval configs).

    REPS is Okareo's agent-evaluation workbench: per-pillar baseline
    material for evaluating AI agents across R-reasoning, E-execution,
    P-performance, and S-security, plus shared explore/ probes and a
    profile/ example. The material is published as tagged releases of
    the okareo-tools repo; this tool serves the latest release so reps
    skills need no local copy of the tree.

    Two modes:
    - Discovery (omit `path`): list what files exist in the served
      release — the full tree, or one area via `pillar`. File lists
      change between releases, so always discover before fetching.
    - Fetch (provide `path`): return one file's exact content as
      published in the release. Use paths verbatim from discovery,
      e.g. 'S-security/scenarios/verification-gate.jsonl'.

    Every response carries the release tag it was served from (e.g.
    'v0.5.1') — record it in evaluation reports as baseline
    provenance. `stale: true` means the last release check failed and
    the content may lag the newest release.

    Args:
        pillar: Optional discovery filter. One of: R-reasoning,
            E-execution, P-performance, S-security, explore, profile.
            Omit to list the entire baseline tree (which also includes
            shared material outside these areas).
        path: Optional file path (relative to the baseline tree, as
            returned by discovery). Provide to fetch that file's
            content; omit for discovery.
        version: Optional release tag. Currently only the served tag
            is available; any other value returns an error naming what
            IS available. Omit to accept the served release.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNo
pillarNo
versionNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds context about release provenance, staleness (`stale: true`), and the served-release-only version constraint, which are not inferable from annotations. It does not contradict annotations.

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 comprehensive but efficiently structured: overview, two modes, args, and response metadata. Each sentence adds distinct value, and the formatting makes it easy to parse. There is no redundancy or filler.

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

Completeness5/5

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

Given the tool's dual-mode complexity, the description fully covers discovery and fetch behavior, parameter semantics, release provenance, and staleness warnings. The presence of an output schema means return-value details are not required in the description, and the description still notes key response fields.

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

Parameters5/5

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

The input schema has 0% parameter descriptions, so the description fully compensates. It thoroughly explains `pillar` (discovery filter with enumerated values), `path` (fetch mode, use verbatim from discovery), and `version` (served release only, error otherwise), including an example path.

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 opens with a specific verb+resource: 'Serve REPS agent-evaluation baseline material' and defines REPS, clearly distinguishing it from sibling tools that manage individual scenarios or checks. It precisely states that the tool serves baseline files from tagged releases.

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

Usage Guidelines5/5

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

It explicitly explains two modes (discovery vs fetch), provides a rule to always discover before fetching, and describes when to use the `pillar` filter and `version` parameter. It also notes that any version other than the served tag returns an error naming available versions, giving clear expected behavior.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/okareo-ai/okareo-mcp'

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