Skip to main content
Glama
Sign In
Metrx MCP Server

Metrx MCP Server

by metrxbots
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Set Job Contract

metrx_set_job_contract

Publishes a new version of an agent's job contract, superseding the prior active version for the same workload, with objective, acceptance criteria, KPI target, budget, and owner.

Instructions

Publish a NEW VERSION of an agent's job contract (append-only: the previous active version for the same workload is superseded in the same transaction). Required: workload, objective, unit_of_work, acceptance_criteria (1-20), kpi_target, budget (dollars per daily|weekly|monthly period, stored as micro-dollars), owner. Workload-policy terms are inherited from the current version unless supplied in policy_terms. For an agent with no version yet, set policy_defaults: 'inherit_workload_policy' copies the org's workload-level policy (a snapshot), 'observe_only' gets terms that grant no authority (needs task_verb and domain in policy_terms); otherwise every term must be in policy_terms. The contract is RECORDED, not enforced at runtime: nothing blocks spend or traffic on it. Needs an API key with the 'admin' scope — an org owner or admin mints one in Settings → Security → API Keys; any other key is refused with 403. Do NOT use to read a contract — use get_job_contract. Requires an API key with the 'admin' scope.

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": {
      "agent_key": "<agent_key>",
      "workload": "<workload>",
      "objective": "<objective>",
      "unit_of_work": "<unit_of_work>",
      "acceptance_criteria": "<acceptance_criteria>",
      "kpi_target": "<kpi_target>",
      "budget_dollars": "<budget_dollars>",
      "budget_period": "<budget_period>",
      "owner": "<owner>"
    },
    "name": "metrx_set_job_contract"
  }
}

Input Schema

NameRequiredDescriptionDefault
notesNoOptional note recorded on this version
ownerYesUser id or email accountable for this agent
workloadYesWorkload label the contract governs (e.g. 'extraction')
agent_keyYesThe agent_key (the X-Agent-ID string), not the UUID
objectiveYesWhat this agent is for, in your words
kpi_targetYesThe number the agent is held to over a rolling window
policy_termsNoOptional workload-policy terms (unit, eligible_traffic, primary_quality, critical_guardrails, signal, non_inferiority, cost_definition, permitted_actions, exposure_budget, rollback_fast, rollback_slow, evidence_expiry, task_verb, domain). Omit to inherit from the current version.
unit_of_workYesThe countable output (e.g. 'one DDQ reviewed')
budget_periodYesBudget period
budget_dollarsYesDeclared spend limit in dollars per period (recorded, not enforced)
policy_defaultsNoFirst version only: where engine terms come from. 'inherit_workload_policy' copies the org's active workload-level policy (refused when none exists); 'observe_only' grants no authority (every action class shadow). Ignored when the agent already has a version.
acceptance_criteriaYesWhat "done well" means: 1-20 {metric, op, threshold, window}

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (which only say it is a non-read-only, non-destructive, non-idempotent mutation), the description discloses that writes are append-only with in-transaction supersession, that the contract is recorded but NOT enforced at runtime, and that an 'admin' scope key is mandatory with a 403 refusal otherwise. These are exactly the facts an agent cannot infer from structured fields.

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

Conciseness3/5

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

The scoping and append-only facts are front-loaded, but the definition is dense and ends by repeating 'Requires an API key with the admin scope' verbatim after already stating it mid-paragraph. That duplication is pure waste in an otherwise information-rich description.

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 12-parameter mutation with nested objects and no output schema, the description covers required fields, first-version policy sourcing, auth requirements, and the read alternative. It omits what the call returns (e.g. the new version identifier) and any conflict/duplicate-publish behavior, which are the main remaining unknowns.

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 already 100%, so the baseline is 3, but the description adds real meaning: budget is dollars per daily/weekly/monthly period stored as micro-dollars, acceptance_criteria is bounded to 1-20, policy_terms are inherited unless supplied, and policy_defaults only applies to a first version. The remaining gap is that it does not restate the agent_key vs UUID distinction or the kpi_target window format.

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 first sentence states a specific verb and resource — 'Publish a NEW VERSION of an agent's job contract' — and immediately qualifies it as append-only with the prior version superseded. This distinguishes it cleanly from the read path (get_job_contract) and from a draft tool without needing to open any schema.

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?

It gives an explicit exclusion ('Do NOT use to read a contract — use get_job_contract') and spells out the first-version branch where policy_defaults applies versus when it is ignored. It does not discuss when to use a draft-then-publish flow, but the when/when-not guidance for this tool itself is clear.

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