Skip to main content
Glama
Sign In
Cachly — AI Cognitive Brain

Cachly — AI Cognitive Brain

by cachly-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

brain_confirm_ci

Confirm whether a CI job passed or failed and which topics it covered. The Brain adjusts lesson confidence automatically for smarter predictions.

Instructions

Close the CI feedback loop: tell the Brain whether a CI job passed or failed and which topics it covered. The Brain adjusts lesson confidence automatically — confirmed failures get +15%, false positives (brain predicted failure but CI passed) get −10%. Called automatically by cachly-action at the end of every pipeline. Also use manually after a deploy to confirm or refute the brain's last prediction.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "instance_id": "<instance_id>",
      "job_status": "<job_status>",
      "topics": "<topics>"
    },
    "name": "brain_confirm_ci"
  }
}

Input Schema

NameRequiredDescriptionDefault
sourceNoOptional: "github_actions", "gitlab_ci", etc.
topicsYesTopics touched by this CI run (e.g. ["auth:jwt", "deploy:k8s"])
job_statusYesOutcome of the CI job
instance_idYesBrain instance ID
scan_topicsNoTopics the brain predicted would fail (from the scan response). Used to detect false positives.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.47

TDQS

A4.4/5.0
Behavior4/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 discloses the behavioral impact: 'The Brain adjusts lesson confidence automatically — confirmed failures get +15%, false positives get −10%.' It also notes it's called automatically. However, it does not describe behavior for 'cancelled' status, error handling, or what happens if required parameters are missing—only the main numeric effects.

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 four sentences with no filler. It front-loads the primary purpose, then immediately lists key effects and usage context. Every sentence provides essential information—nothing extraneous.

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

Completeness4/5

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

For a tool with 5 parameters and no output schema, the description explains the core action, confidence adjustments, and both automatic/manual triggers. However, it does not describe the return value or response format, which leaves agents uncertain about what to expect after invocation. It also doesn't cover edge cases like empty topics or cancelled status.

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

Parameters4/5

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

Schema coverage is 100% (all parameters have descriptions), so baseline is 3. The description adds value by explaining 'scan_topics' is 'Used to detect false positives' and connects 'job_status' to the confidence adjustments. This goes beyond the schema's bare descriptions, enriching semantic understanding for correct invocation.

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: 'Close the CI feedback loop: tell the Brain whether a CI job passed or failed and which topics it covered.' It uses a specific verb ('confirm') and resource ('CI'), and distinguishes itself from siblings like 'brain_predict' (which predicts failures) and 'fedbrain_confirm' (federated equivalent) by focusing on closing the loop after CI execution.

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?

The description gives clear context: 'Called automatically by cachly-action at the end of every pipeline. Also use manually after a deploy to confirm or refute the brain's last prediction.' This covers both automatic and manual use cases. However, it does not explicitly state when NOT to use this tool versus alternatives like 'brain_from_ci' or 'brain_predict_failures', which could help the agent choose correctly.

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