Skip to main content
Glama
logly

mureo

by logly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

mureo_batch_end

Close the current batch and receive its exact membership: the collected action_log indices and platforms. Finalizes the set, preventing later entries from altering the accurate membership record.

Instructions

Close the open batch and return its exact membership: the action_log indices it collected and the platforms they span. Keep that list — it is the record that removes the need to reconstruct a change set from memory later. Closing is FINAL: no later entry can join, so the member count stays true. Refused if no batch is open.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoOptional path to STATE.json. Defaults to STATE.json in the MCP server's current working directory. Paths outside it are refused.
reasonNoWhy this change is being made: one or two sentences naming the evidence and the expected effect. Stored in the journal and on the action_log entry this call produces, for the operator and the next session.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.20.0
    • addedInput schema / properties / reason
      Added value: +{
+  "description": "Why this change is being made: one or two sentences naming the evidence and the expected effect. Stored in the journal and on the action_log entry this call produces, for the operator and the next session.",
+  "maxLength": 500,
+  "type": "string"
+}
  2. Addedv0.10.44

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries full burden of behavioral disclosure, and it does so well: it warns that closing is FINAL and irreversible, that no later entry can join, and that it is refused when no batch is open. This is exactly the kind of safety-relevant context an agent needs for a closing operation. No annotation contradiction (no annotations provided).

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?

Every sentence earns its place: action+return value, a usage hint about the record, a finality warning, and a failure condition. It is front-loaded with the action and has zero filler.

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?

No output schema exists, but the description explains the return value (action_log indices and platforms). Combined with a fully documented schema and a clear failure mode, an agent has everything needed to call this correctly. Minor gap: it doesn't describe the exact response shape or whether the list is returned in the body, but that is a small omission for a low-complexity operation.

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 both parameters (path, reason) are already fully documented in the input schema. The description adds nothing about parameter meaning or formats, which is acceptable at high coverage — 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?

States a specific verb+resource ('Close the open batch') and precisely what it returns (action_log indices and platforms). It clearly differentiates from siblings like mureo_batch_begin (starts a batch) and mureo_batch_status (reads state), so an agent can distinguish them without opening schemas.

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 — call it when you are finished collecting a batch — and gives a precondition ('Refused if no batch is open') plus post-call guidance ('Keep that list'). However, it never explicitly names alternatives (mureo_batch_begin, mureo_batch_status) or states when not to use it, leaving routing to inference.

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