Skip to main content
Glama

devtune_save_agent_picks_job

DestructiveIdempotent

Save a custom Agent Picks job as confirmed, with the setup that tests it. A project can have several custom jobs. Without setup, this updates the custom job with the same job line (ignoring case and surrounding spaces), or adds a setup for a new job; a job without a source category never matches a copy by its line. With setup, it updates that setup. A job with a source_category_id is the project's copy of that category: without setup the save updates that copy whatever the job line, or adds one, so a project holds one copy per category; with setup, a source another setup's copy holds is refused as category_in_use, and changing or clearing the source of the setup's own job as category_fixed. A copy may hold its copied tools plus seven and keep the name it was copied with; a job without a source holds seven tools and a line of at least 8 characters. The body: job (the line), source_category_id (the public category it started from, or null), requests {add, recommend, hosted or null}, building_blocks and tools (tool_key, display_name, brand_domain, signals and draft_id from devtune_draft_agent_picks_tool), own_tool_key, competitor_tool_keys (among tools), environment_ids and agent_models. devtune_get_agent_picks_catalogue lists the valid source_category_id, environment_ids and agent_models. building_blocks and signals use the shapes devtune_draft_agent_picks_job, devtune_draft_agent_picks_tool and the summary's job return. A tool's signals.yieldsTo lists the job's other tools that run inside it, or stand in for part of it: when a run uses both, it counts as the listed tool (GitHub Actions yieldsTo Depot, so a workflow on a Depot runner counts as Depot). Without it such a run is ambiguous. A yieldsTo loop of any length is refused. signals.dismissedYieldsTo lists suggestions of this tool yielding that were dismissed or removed, kept so they aren't suggested again until either tool is redrafted; it never affects classification. Starts no test. Refusals carry a reason: invalid_job, agent_not_in_plan and forbidden. Requires actions.write and Agent Picks. The OAuth member, or the member who created the API key, needs project management rights.

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": {
      "job": "<job>",
      "requests": "<requests>",
      "building_blocks": "<building_blocks>",
      "tools": "<tools>",
      "own_tool_key": "<own_tool_key>",
      "environment_ids": "<environment_ids>",
      "agent_models": "<agent_models>"
    },
    "name": "devtune_save_agent_picks_job"
  }
}

Input Schema

NameRequiredDescriptionDefault
jobYes
setupNoThe Agent Picks setup to use: its id or its category slug. Optional while the project has one setup. With several, omitting it is refused as agent_picks_setup_required, and a setup the project does not have as agent_picks_setup_not_found; both list the project setups in details.setups (id, category_slug, category_name). The response echoes the setup used as setup {id, category_slug}.
toolsYes
requestsYes
agent_modelsYes
own_tool_keyYes
building_blocksYes
environment_idsYes
source_category_idNo
competitor_tool_keysNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / building_blocks / propertyNames
      Added value: +{
      +  "type": "string"
      +}
    • addedInput schema / properties / environment_ids / items / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
    • changedInput schema / properties / source_category_id / anyOf
      Previous value: -[
      -  {
      -    "format": "uuid",
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "format": "uuid",
      +    "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$",
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / tools / items / properties / draft_id / anyOf
      Previous value: -[
      -  {
      -    "format": "uuid",
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "format": "uuid",
      +    "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$",
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / tools / items / properties / signals / propertyNames
      Added value: +{
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / agent_models / items / properties / agent / enum
      Previous value: -[
      -  "claude_code",
      -  "codex",
      -  "opencode",
      -  "pi"
      -]New value: +[
      +  "claude_code",
      +  "codex",
      +  "opencode",
      +  "pi",
      +  "muse_code"
      +]
  3. Changed2 schema fields changed
    • changedInput schema / properties / job / minLength
      Previous value: -8New value: +1
    • changedInput schema / properties / tools / maxItems
      Previous value: -7New value: +35
  4. Changed1 schema field changed
    • addedInput schema / properties / setup
      Added value: +{
      +  "description": "The Agent Picks setup to use: its id or its category slug. Optional while the project has one setup. With several, omitting it is refused as agent_picks_setup_required, and a setup the project does not have as agent_picks_setup_not_found; both list the project setups in details.setups (id, category_slug, category_name). The response echoes the setup used as setup {id, category_slug}.",
      +  "maxLength": 200,
      +  "minLength": 1,
      +  "type": "string"
      +}
  5. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description goes well beyond them: case- and whitespace-insensitive job-line matching, the one-copy-per-category rule, the category_in_use and category_fixed refusals, tool-count limits (seven for a job without a source; copied tools plus seven for a copy), and the auth requirement (actions.write, Agent Picks, project management rights of the OAuth member or API key creator). The main gap is that it never states whether an update replaces the existing tools/requests wholesale and what happens to entries omitted from the new body, which is the key destructive detail for a save operation.

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 content is information-dense but delivered as one long, multi-clause block: the matching rules, copy rules, limits, body fields, yieldsTo semantics and auth requirements run together without headers or bullets. The yieldsTo explanation alone spans several sentences of narrow-case detail. Most sentences earn their place given the tool's complexity, but the structure is not front-loaded beyond the first sentence and the reader must parse a wall of text to extract call-relevant rules.

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 10-parameter, nested-object, destructive write with no output schema and near-zero schema descriptions, the definition covers the pieces an agent needs: auth requirements, error reasons (invalid_job, agent_not_in_plan, forbidden, category_in_use, category_fixed), which sibling tools supply valid ids and value shapes, and the fact that no test is started. The remaining gap is response/return behavior and the replace-versus-merge semantics of an update, which matter for a destructive save but are not addressed.

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 description coverage is only 10% across 10 parameters, so the description has to carry the load and partly does: it enumerates the body fields (job, source_category_id, requests {add, recommend, hosted}, building_blocks, tools with tool_key/display_name/brand_domain/signals/draft_id, own_tool_key, competitor_tool_keys, environment_ids, agent_models) and adds constraints such as an 8-character minimum line and the seven-tool limit. However, several parameters remain semantically opaque: the meaning of requests.add versus recommend versus hosted, what own_tool_key designates, and what 'competitor_tool_keys (among tools)' actually constrains are not explained. Useful but incomplete compensation for the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening states a specific verb and resource: 'Save a custom Agent Picks job as confirmed, with the setup that tests it,' which separates it from the draft tools it cites (devtune_draft_agent_picks_job, devtune_draft_agent_picks_tool) and from the setup tools. The later clause 'A project can have several custom jobs' plus the copy/update matching rules make the create-or-update nature explicit. It is not as crisp as a one-line purpose statement, but an agent can tell what the tool does and which sibling definitions feed it.

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?

The description gives concrete when-to-use routing: use devtune_get_agent_picks_catalogue to obtain valid source_category_id, environment_ids and agent_models, and use the draft tools for the shapes of building_blocks and signals. It also states an explicit exclusion, 'Starts no test,' which routes test execution elsewhere among the siblings. It stops short of saying when to draft first versus save directly, but the context is otherwise clear.

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.

Resources