Skip to main content
Glama
Sign In
Metrx MCP Server

Metrx MCP Server

by metrxbots
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Draft Job Contract

metrx_draft_job_contract
Read-onlyIdempotent

Draft an AI agent job contract from a template with objective, unit of work, acceptance criteria, budget, and human ROI baseline; get the draft plus validation errors and warnings.

Instructions

Draft a job contract for an AI agent from a template (support_triage, sdr_qualification, internal_assistant, coding_patch): objective, unit of work, acceptance criteria, budget, and the human baseline for ROI. Returns the draft to publish plus validation errors and warnings. A pure function over your input: reads nothing, stores nothing, needs no key. Publishing the draft is a separate step (set_job_contract, '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": {
      "template": "<template>",
      "owner": "<owner>"
    },
    "name": "metrx_draft_job_contract"
  }
}

Input Schema

NameRequiredDescriptionDefault
notesNo
ownerYesThe person accountable for this agent (name or email).
templateYesWhich job template to start from.
workloadNoDefaults to agent_key, else the template key.
agent_keyNoThe agent the contract will be published for (informational in the draft).
objectiveNo
budget_usdNo
unit_of_workNoWhat one unit is, e.g. 'resolved ticket'.
budget_periodNo
human_baselineNoWhat the same unit costs when a person does it; the ROI comparison needs it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: it is a pure function over input, needs no API key, reads and stores nothing, and returns validation errors and warnings alongside the draft. It stops short of describing what the validation errors look like, but that is a minor gap given the annotation coverage.

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?

Four tight sentences, front-loaded with the action and templates before the return behavior and the publish hand-off. Parenthetical template list is dense but earns its place; nothing is redundant with the schema.

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?

There is no output schema, so the description correctly states what comes back (a draft plus validation errors and warnings). For a 10-parameter tool with a nested human_baseline object, the only real omission is detail on parameter interactions and error semantics, which is acceptable at this level.

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?

With 60% schema description coverage, the schema already documents template, owner, workload, agent_key, unit_of_work, and human_baseline. The description adds framing by tying the draft fields together (objective, acceptance criteria, budget, human baseline for ROI) and listing the template enum values, but it says nothing about required vs optional distinction, the owner/agent_key relationship, or the workload default behavior.

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 and resource ('Draft a job contract') and immediately enumerates the output artifact's contents plus the four templates. It cleanly separates itself from metrx_set_job_contract by calling publishing a distinct step, so an agent can pick the right tool without opening the 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?

Explicitly frames this as the drafting step and names metrx_set_job_contract as the follow-on for publishing, including that it requires 'admin' scope. It doesn't spell out when a draft is unnecessary (e.g. contract already exists and should be read via metrx_get_job_contract), but the draft-then-publish routing is unambiguous.

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