Skip to main content
Glama
juyterman1000

entroly-context-engine

by juyterman1000
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

record_ci_result

Record a CI pass/fail outcome for an optimization request after the pipeline runs, appending the result to event history and verified task memory.

Instructions

Record an externally produced CI pass/fail result for an optimization request.

Use this only after CI actually ran. It appends a strong RAVS outcome event and may promote the request-bound result into verified task memory. It does not run CI, fetch url, inspect the repository, or prove that the supplied pipeline name or URL is genuine. Repeated calls append repeated events; callers should submit one result per request.

Use record_test_result for a test-suite result and record_command_exit for one subprocess exit code. The returned JSON reports recorded, skipped (event log unavailable), or error.

Args: request_id: Exact trace ID from the relevant optimize_context call. passed: Whether every required CI check passed. pipeline: Optional CI provider or pipeline identifier. url: Optional provenance link; it is stored but never fetched.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoOptional CI run URL stored as provenance; Entroly does not fetch or trust this URL.
passedYesTrue only when every required CI check passed; false when a required check failed.
pipelineNoShort CI provider or pipeline name, such as github_actions, gitlab_ci, or buildkite.
request_idYesExact request_id returned by optimize_context for the work being checked.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.0.64
    • addedInput schema / properties / passed / description
      Added value: +"True only when every required CI check passed; false when a required check failed."
    • addedInput schema / properties / pipeline / description
      Added value: +"Short CI provider or pipeline name, such as github_actions, gitlab_ci, or buildkite."
    • addedInput schema / properties / request_id / description
      Added value: +"Exact request_id returned by optimize_context for the work being checked."
    • addedInput schema / properties / url / description
      Added value: +"Optional CI run URL stored as provenance; Entroly does not fetch or trust this URL."
  2. Addedv1.0.54
  3. Removedv1.0.54
  4. First observedv1.0.42

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses what the tool does not do ('does not run CI, fetch url, inspect repository...'), side effects ('may promote the request-bound result into verified task memory'), idempotency behavior ('Repeated calls append repeated events'), and return statuses ('recorded', 'skipped', 'error').

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

Conciseness4/5

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

The description is well organized: primary action, usage condition, sibling routing, behavioral caveats, and a compact Args section. It is slightly long but every sentence adds meaningful operational guidance; no 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?

The tool has an output schema and 100% parameter coverage, and the description still adds crucial contextual guidance: preconditions, negative capabilities, idempotency, and return semantics. An agent has everything needed to call it correctly without opening other tools' definitions.

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 the baseline is 3. The description adds minor semantic reinforcement for request_id ('Exact trace ID') and url ('stored but never fetched'), but these largely mirror the schema descriptions, so it doesn't significantly raise the value above 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 opens with a specific verb and resource: 'Record an externally produced CI pass/fail result for an optimization request.' It clearly distinguishes its scope by naming sibling tools it is not: 'Use record_test_result for a test-suite result and record_command_exit for one subprocess exit code.'

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?

Explicitly states when to use the tool: 'Use this only after CI actually ran.' It names the exact alternatives for different scenarios and even warns against repeated calls: 'callers should submit one result per request.'

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

Deploy Server

Other Tools