Skip to main content
Glama

Create a job

job_create

Create a job: named standing work in a workspace (founder-posts, inbox-triage), with a one-line purpose, a description its agents read, the agents who do it (each with an optional role; internal members' agents, a guest's is refused), and optionally its task definitions: each names the task types it covers, how to create one, and its steps with their role, cadence, instructions and approval. A job grants nothing: approvals stay per task. Jobs are internal (a guest never sees one). Your own jobs come first in workspace_load's jobs; name a job with job on task_create, task_update, task_report, task_propose (a new proposal) and task_start (by tags, with your step). A name already used in the workspace, an archived job's included, refuses JOB_NAME_TAKEN.

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": {
      "workspaceId": "<workspaceId>",
      "name": "<name>"
    },
    "name": "job_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
whyNoRequired for workspace items: one sentence on what the person is trying to accomplish, in their terms, not a description of this edit. Every workspace write takes one; sessions and summaries record themselves from it. At most 300 characters.
nameYesThe job's name, unique in the workspace (founder-posts, inbox-triage): lowercase letters, digits, - and _, starting with a letter or a digit, at most 64 characters.
agentsNoThe agents who do the job, at most 20, each once: { agent, role? }. A job grants nothing: approvals stay per task.
purposeNoOne line on what the job is for, at most 280 characters ("The founder's notes become posts on X and LinkedIn"): shown under its name wherever jobs are listed, so a reader can tell which job does what. Empty is none.
definitionsNoThe job's task definitions, at most 5, in order: each says what a task of the job is (its types), how to create one (instructions) and the steps it goes through: { name, types, instructions?, steps }. The job's purpose, description and definitions take at most 30000 bytes as JSON.
descriptionNoWhat the job is and how it is done, in markdown, at most 8000 characters: the standing brief its agents read. The job's purpose, description and definitions share 30000 bytes as JSON.
workspaceIdYesThe workspace (its id or its slug).

Output Schema

NameRequiredDescriptionDefault
jobYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover only the generic mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description goes well beyond that: a guest's agent is refused, a guest never sees a job, approvals remain per-task rather than granted by the job, duplicate names (including archived jobs') fail with JOB_NAME_TAKEN, and a 30000-byte cap applies across purpose/description/definitions.

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?

The core identity and creation semantics are front-loaded in the first sentence, and every clause carries information (examples, constraints, error code, sibling linkage) without redundancy against the schema. It is dense and parenthetical to the point that some clauses need a second read, which keeps it off a 5.

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

Completeness5/5

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

For a 7-parameter nested create with annotations and an output schema, the description covers the resource model, the nested structure, invariants, refusal conditions and downstream usage. Return values are handled by the output schema, so nothing essential for correct invocation is missing.

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; the description adds real meaning on top by summarizing the nested shape it expects — definitions naming their task types, how to create one, and steps carrying role, cadence, instructions and approval. It also clarifies the relationship of the `name` param to `job` on sibling task tools, which is not expressible in this schema.

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 opens with a specific verb+resource ('Create a job') and immediately defines what a job is — 'named standing work in a workspace' with examples (founder-posts, inbox-triage) — and enumerates its parts (purpose, description, agents, definitions). An agent can distinguish this from job_update or job_get purely from the text without opening a 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 clear operational context: jobs are internal, a guest never sees one, a job grants no approvals, and the created name is then consumed by task_create, task_update, task_report, task_propose and task_start. What's absent is an explicit statement of when to prefer this over job_update (editing an existing job) or an explicit 'do not use for one-off work' exclusion.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.