Skip to main content
Glama
Sign In

Arbituro

by com.arbituro
OverviewDiscussionsAdmin

Propose a change to a job

propose_job_update

Propose a change to a job's title or description, or done-when clauses to add to it. Changes nothing: it raises a proposal on the job owner's queue, and they accept, edit or dismiss it. Use this rather than asking a person to make an edit for you — the proposal carries your wording, and one press applies it.

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": {
      "project": "<project>",
      "job": "<job>"
    },
    "name": "propose_job_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
jobYesThe job's key, e.g. FLAIR-12.
titleNoThe title you propose. Omit to leave the title alone.
projectYesThe project's key, e.g. FLAIR.
doneWhenNoDone-when clauses to add, at most five, each with the exact name of the CI check that decides it when one does (e.g. test). Accepting adds them beside the job's own; none is changed or removed.
rationaleNoWhy you are proposing this. Shown to the person deciding, so say what you found rather than what you changed.
descriptionNoThe description you propose, as markdown. Omit to leave the description alone.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, but the description goes further by explaining the actual effect: nothing changes, a proposal lands on the job owner's queue, and they accept, edit, or dismiss it. That human-in-the-loop lifecycle is genuinely additive beyond the annotations. It does not address whether repeated proposals stack or how the caller learns of the outcome, so it isn't exhaustive.

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?

Three tight sentences with the scope front-loaded, then the behavioral caveat, then the usage steer. The colon construction "Changes nothing:" is efficient and no sentence is padding.

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 mutation-adjacent tool with no output schema, the description covers the important unknowns: nothing is mutated, a human decides, and clause additions are additive. What a successful call returns (e.g., a proposal reference) is left unspecified, a minor gap given the otherwise strong coverage.

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%, so the baseline is 3, and the description clears that bar by adding semantics the schema lacks: accepting done-when clauses adds them beside the job's existing clauses and none is changed or removed. It also frames the proposal as carrying "your wording," reinforcing that field values are the proposed content.

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?

Names a specific verb (propose) plus the exact resources it touches: title, description, and done-when clauses. An agent can immediately tell this apart from create_job or get_job because the description makes clear it only raises a proposal rather than mutating the job.

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?

Explicitly says to use this "rather than asking a person to make an edit for you," which gives a clear condition for choosing it. It stops short of naming a sibling tool or stating when not to use it, so it lands just below the top band.

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

All Arbituro toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources